|
m Date maintenance tags and general fixes
|
m attempt to clarify push/pull by using double arrow for pull
|
||
| Line 18: | Line 18: | ||
A detailed flow of a message through these various agents is given at [http://wiki.mutt.org/?MailConcept/Flow MuttWiki: MailConcept/Flow], and may be summarized as |
A detailed flow of a message through these various agents is given at [http://wiki.mutt.org/?MailConcept/Flow MuttWiki: MailConcept/Flow], and may be summarized as |
||
:MUA → MSA → MTA → … → MTA → MDA |
:MUA → MSA → MTA → … → MTA → MDA →→ MRA →→ MUA, |
||
with the arrows changing direction to distinguish between ''push'' steps and ''pull'' steps ( |
with the arrows changing direction to distinguish between ''push'' steps (→) and ''pull'' steps (→→). |
||
Programs such as [[fetchmail]] which retrieve email from a server but do not provide a human interface for viewing or other client tasks are referred to as MRAs – they provide ''retrieval'' but no other client functions. Traditionally and in internet standards (such as the recent RFC 5598) these are referred to as a type of MUA, because they are client-side and hence outside the scope of internet standards, and indeed many MUAs perform MRA functions. However, traditional Unix email readers such as elm, Pine, or mutt would often not include MRA functions (or only optionally), reading email that had already been delivered to a mailbox file (formally, ''delivered'' by an MDA). |
Programs such as [[fetchmail]] which retrieve email from a server but do not provide a human interface for viewing or other client tasks are referred to as MRAs – they provide ''retrieval'' but no other client functions. Traditionally and in internet standards (such as the recent RFC 5598) these are referred to as a type of MUA, because they are client-side and hence outside the scope of internet standards, and indeed many MUAs perform MRA functions. However, traditional Unix email readers such as elm, Pine, or mutt would often not include MRA functions (or only optionally), reading email that had already been delivered to a mailbox file (formally, ''delivered'' by an MDA). |
||
 |
This article possibly contains original research. Please improve itbyverifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (September 2009) (Learn how and when to remove this message)
|
Ane-mail agent is a program that is part of the e-mail infrastructure, from composition by sender, to transfer across the network, to viewing by recipient. The best-known are mail user agents (MUAs, aka, e-mail clients) and mail transfer agents (MTAs, programs that transfer e-mail between clients), but finer divisions exist.
More precisely, this is a technical way of referring to functions performed by various programs, considering them as software agents: a given program may perform several functions, but while it is performing a given function (such as mail transfer), it is referred to as a mail transfer agent. These terms are most often used within internet standards, and technical discussions of e-mail infrastructure, not by end-users.
While the individual terms are widely used in internet standards and RFCs, there is no widely used umbrella term for these programs, though such a program may informally be referred to generically as an MxA, 'x' being a wildcard, as the programs are referred to by acronyms of this form, such as MUA and MTA, with 'x' depending on role.
The finest and most expansive classification in current use is into five functions:
The traditional division is into client-side (MUA) and server-side (MTA, notably sendmail), with the flow given as:
Other divisions have been made to draw distinctions that some have found useful, which are detailed as follows.
A detailed flow of a message through these various agents is given at MuttWiki: MailConcept/Flow, and may be summarized as
with the arrows changing direction to distinguish between push steps (→) and pull steps (→→).
Programs such as fetchmail which retrieve email from a server but do not provide a human interface for viewing or other client tasks are referred to as MRAs – they provide retrieval but no other client functions. Traditionally and in internet standards (such as the recent RFC 5598) these are referred to as a type of MUA, because they are client-side and hence outside the scope of internet standards, and indeed many MUAs perform MRA functions. However, traditional Unix email readers such as elm, Pine, or mutt would often not include MRA functions (or only optionally), reading email that had already been delivered to a mailbox file (formally, delivered by an MDA).
Broadly and traditionally, any program that transfers mail between the ends (all server-side functions) is an MTA. More finely and more recently, the endpoints of the chain have been distinguished, with the initial client-server step referred to as submission, and the final server-client step referred to as delivery. The motivation for distinguishing the MSA role has largely been security, with MUA-MSA interactions (initial submission) receiving greater scrutiny than MTA-MTA (server-server) transfers. The delivery (MDA) stage is where such tasks as filtering (of undesired emails) and filing (into separate folders) occur, and are the start of the user agent; traditionally this was done via procmail, while today it may be done via server-side programs, often using spam filters such as SpamAssassin. The MDA can be said to work "before the message hits the user's mailbox".
