Email agent (infrastructure)

An email agent is a program that is part of the email infrastructure, from composition by sender, to transfer across the network, to viewing by recipient. The best-known are mail user agents (MUAs, aka, email clients) and mail transfer agents (MTAs, programs that transfer email between clients), but finer divisions exist.

Schema of e-mail delivery

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 email 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.

Email servers are built from one or more software packages, each of which carries out the functions of one or more MxA.[1][2]

Classification

The finest and most expansive classification in current use is into five functions in addition to the mail exchanger (MX):[3]

The traditional division is into client-side (MUA) and server-side (MTA, notably sendmail), with the flow given as:[17]

MUA → MTA → … → MTA → MUA,

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 , and may be summarized as

MUA → MSA → MTA → … → MTA → MDA →→ MRA →→ MUA,

with the arrow styles changing to distinguish between push steps (→) and pull steps (→→).

Another source gives the flow as:[18]

MUA → (MSA) → MTA → … → MX → MDA →→ MRA/MUA,

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".

See also

References
  1. Schroder 2004, p. 362: "There are several ways to build a Linux mail server. Most admins take the modular approach and build it from a collection of specialized programs... Another approach is to use the Courier package, because it is a complete package that contains an MTA, POP3, IMAP, and a mailing list manager. Or purchase a distribution that puts it all together for you, like SuSE OpenExchange."
  2. McBee 2009, p. 22: "Each e-mail system can use a wide variety of solutions to implement these functions. Some applications, such as Exchange, incorporate all of these functions into a single end-to-end offering, whereas others provide just one piece of the puzzle, relying on other applications to provide the missing functionality. Even when using a complete solution, however, you can always mix and match pieces to provide functionality (such as using a third-party client for MUA functionality, or an edge mail appliance as an MTA to other mail systems). To ensure that these implementations work together, a series of standards have been developed over time."
  3. Faircloth 2013, p. 51: "SMTP is comprised of a mail submission agent (MSA), a mail user agent (MUA), a mail retrieval agent (MRA), a mail exchanger (MX), a mail delivery agent (MDA), and potentially multiple servers in between known as mail transfer agents (MTAs)."
  4. McBee 2009, p. 21: "The mail user agent (MUA) is the component that the user directly interacts with. If I were to use a postal metaphor, the MUA is roughly the equivalent of your local mailbox at the end of the driveway. Traditionally, the MUA has been a stand-alone client application such as Outlook; however, a web-based client such as Outlook Web Access also offers MUA functionality, even though it is technically a server-side application."
  5. Schroder 2004, p. 361: "MUA: Mail user agent, also called 'mail client.' Mutt, Pine, Kmail, Evolution, and Balsa are MUAs. This is the user's program for composing, sending, and receiving email. MUAs can fetch mail from a local folder, or from a remote server via POP and IMAP."
  6. Vakali 2006, p. 221: "Mail User Agent (MUA): It is responsible for helping the user to read and write e-mail messages. The MUA is usually implemented in software commonly referred to as an e-mail client. Two popular e-mail clients are Microsoft Outlook and Mozilla Thunderbird. These programs transform a text message into the appropriate Internet format in order for the message to reach its destination."
  7. McBee 2009, p. 22: "Just as the MRA is a variant role often performed by the MUA, the mail submission agent (MSA) is a specialized form of the MTA. It's adapted to accept mail submissions from the MUA, introduce them into the mail flow, and handle any specialized processing that may be required. In Exchange 2007, this function is handled both in the Mailbox role as well as the Client Receive Connector on the Hub Transport role."
  8. Bauer 2003, p. 458: "[A] little background on IMAP's role in the e-mail food chain. IMAP, the Internet Message Access Protocol (specified in RFC 3501), is a protocol for mail delivery agents (MDAs). Whereas mail transport agents (MTAs), such as Postfix and Sendmail, move mail between networks, MDAs move mail from MTAs to destination mailboxes. To use a simile from my book Building Secure Servers With Linux, if an MTA is like a mail truck that moves mail between post offices, an MDA is like a letter carrier who delivers mail from the local post office to your house.
    An IMAP-based MDA system has two parts: an IMAP server, which houses user mailboxes and receives mail from some MTA, and a group of users running IMAP client software. The three most popular open-source IMAP servers are University of Washington IMAP (UW IMAP), Cyrus IMAP from Carnegie Mellon University and Courier IMAP from Inter7 Internet Technologies. Popular IMAP client applications include Netscape/Mozilla Communicator, Ximian Evolution, Microsoft Outlook Express, KMail, mutt, pine and Apple Mac OS X Mail."
  9. McBee 2009, pp. 21-22: "If the MUA is the local mailbox, the mail transport agent (MTA) is the Post Office infrastructure connecting different towns and cities with each other. The MTA is responsible for accepting messages from other systems such as MUAs and MTAs, routing them, and ensuring their delivery on to their recipients. Messages typically travel through two MTAs - the sender's and the recipient's (unless, of course, they share an MTA). In an Exchange 2007 system, the Hub Transport and Edge Transport roles fill the MTA role."
  10. Schroder 2004, p. 361: "MTA: Mail transfer agent. This moves email between servers. Sendmail, Exim, qmail, and Postfix are MTAs. An MTA must support SMTP."
  11. Vakali 2006, p. 221: "Mail Transfer Agent (MTA): It accepts a message passed to it by either an MUA or another MTA, and then decides on the appropriate delivery method and the route that the mail should follow. It uses SMTP to send the message to another MTA or a mail delivery agent (MDA)."
  12. McBee 2009, p. 22: "What's missing from this picture? In this case, it's the equivalent of the local Post Office (or, if you prefer, the mail room in the big corporation) - the mail delivery agent (MDA) or local delivery agent (LDA). Once the incoming message has been delivered to the proper collection of systems, the MDA/LDA is responsible for ensuring it's been put into the correct mailbox."
  13. Schroder 2004, p. 361: "Mail delivery agent. This is an intermediary between an MTA and a MUA. Procmail and Fetchmail are two popular MDAs. An MDA is not required; it is used for extra functionality, such as filtering, sorting, and autoresponding."
  14. Vakali 2006, p. 221: "Mail Delivery Agent: It receives messages from MTAs and delivers them to the user's mail box in the user's mail server."
  15. McBee 2009, p. 21: "The mail retrieval agent, closely related to the MUA, is the component that handles retrieving messages from the main mail store. Depending on which protocols you are using, such as the Post Office Protocol (POP) or Internet Mail Access Protocol (IMAP), you can't just rely on new messages to be pushed to your MUA; something needs to pull them down for you. Typically, the MRA is not a separate component in modern systems, but a set of additional routines in the MUA that support message retrieval."
  16. Vakali 2006, p. 221: "Mail Retrieval Agent (MRA): It fetches mail from the user's mail server to the user's local in-box. MRAs are often embedded in e-mail clients."
  17. See Figure 1. Life cycle of an e-mail in Vakali 2006, p. 221
  18. Faircloth 2013, p. 51: "The process flow for sending an email goes as follows:
    1. The MUA (client) sends the properly formatted mail to the MSA or directly to an MTA
    2. The MSA sends the mail to its MTA
    3. Additional MTAs may be routed through until the email is on a 'boundary MTA'
    4. The boundary MTA performs a query using DNS to identify the MX for the domain the email is intended for
    5. The MTA connects to the MX and transfers the email
    6. The MX transfers the email to the MDA
    7. At this point, the email is transferred to the appropriate internal mail server and stored until the MUA or MRA connects to it and retrieves the email on behalf of the user (usually using the POP or IMAP protocols)"

Bibliography
  • Bauer, Mick (2003). "Paranoid penguin: secure mail with LDAP and IMAP, Part I". Linux Journal. 2003 (115, November 2003): 12 – via ACM.CS1 maint: ref=harv (link)
  • Crocker, Dave (July 2009). "RFC 5598: Internet Mail Architecture". IETF. Retrieved 2018-11-02.CS1 maint: ref=harv (link)
  • Faircloth, Jeremy (11 Dec 2013). Enterprise Applications Administration: The Definitive Guide to Implementation and Operations. Morgan Kaufmann. ISBN 9780124077737.CS1 maint: ref=harv (link)
  • McBee, Jim (26 Jan 2009). Mastering Microsoft Exchange Server 2007 SP1. John Wiley & Sons. ISBN 9780470478141.CS1 maint: ref=harv (link)
  • Schroder, Carla (29 Nov 2004). Linux Cookbook: Practical Advice for Linux System Administrators. O'Reilly Media. ISBN 9780596517502.CS1 maint: ref=harv (link)
  • Vakali, Athena (30 Sep 2006). Web Data Management Practices: Emerging Techniques and Technologies. Idea Group Inc (IGI). ISBN 9781599042305.CS1 maint: ref=harv (link)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.