1. A short introduction to the notorious MxA bunch
    2. MUA: Mail User Agent (eMail client)
    3. MTA: Mail Transport Agent (SMTP server)
      1. mutt and SMTP
    4. MDA: Mail Delivery Agent
    5. MRA: Mail Retrieval Agent (POP/IMAP client)
    6. Note

A short introduction to the notorious MxA bunch

To help specify more precisely just what they are talking about, email professionals talk about MUAs, MTAs, and so on. A few notes on what it all means.

Mail handling is divided into three (or four, or five... depending on who's talking) parts. There's the client (MUA), the server that sends and queues mail (MTA), retrieval from remote mailboxes (MRA), local delivery and rewriting of messages (MDA), and remote submission of messages (MSA).

The terms more describe functions than they describe software. Sometimes a single program such as Mozilla Thunderbird or Microsoft Outlook can combine several parts, in this case client, retrieval, and processing rule functions. Sometimes they're seperated out into individual tools.

Also, despite their confusing appearance, they are terms of convenience. This means that their meaning can change somewhat with the context. For example, if I run a unix machine that has its own hostname and MX records, so that it can send and receive mail, there are only two different pieces of software needed: Mutt as MUA, and sendmail as MTA (combining the roles of MDA and MSA as well). If it is not needed, the roles are usually not split out.

MUA
MUA stands for Mail User Agent and means 'mail client program', the part you see and use to send and receive mail.
MTA
The term Mail Transfer Agent used to mean basically anything between MUAs. Now, MTAs generally mean the parts that do the routing and actual transfering of mail between hosts, ISPs, and so on, depending on how strict you want to be.
MDA
An email arrives and does not need to go further. The MTA gives it to the Mail Delivery Agent, and the MDA puts it in an incoming mailbox. It might call other tools like procmail that then become part of its function.
MSA
If you are an ISP with lots of users that use MUAs on machines that don't have their own MTA (still with us?), it doesn't do to simply let all those users submit their messages to your MTA systems without any authentication. Otherwise, say, spammers might notice and abuse your systems. So, accepting emails from users for sending elsewhere becomes a specialized task, and an MTA that does that may be called MSA to indicate the difference.
MRA
A Mail Retrieval Agent makes a connection to a remote mailbox and fetch mail for local use. For example: Fetchmail as a standalone program.

Mutt is an email client, and thus a MUA. Its POP&IMAP support means it has MRA functionality as well.

A typical generic path of your eMail through the Internet and on your computer system might look as shown in these charts. Your setup may vary in detail.

MailConcept/Flow MailConcept/Layout

MUA: Mail User Agent (eMail client)

The MUA is the frontend to the end user to manage and read stored eMail in the user's mailbox(es) and compose new eMail to be sent out via an MSA. This includes things like decoding MIME-encoded and encrypted messages. MuttTools can help enhance functionality that mutt has not built in.

Other popular MUAs include thunderbird, kmail, evolution, sylpheed, mulberry, pegasus, pine, elm (mutt's predecessor), ...

MTA: Mail Transport Agent (SMTP server)

The MTA queues, receives from, and sends mail to other MTAs. This includes routing mail, queueing and retrying sending if the next MTA doesn't accept email right now for whatever reason, or sending a notification back to the original sender if the next MTA refuses to handle the message for some reason. Reasons include concluding the receiving mailbox does not exist or is full or otherwise unavailable, or nowadays that it doesn't trust the sending MTA not to send spam.

On the internet, MTAs between themselves speak SMTP, for Simple Mail Transfer Protocol. Some popular MTAs include:

In addition there are small MTAs ("SMTP clients" as opposed to fully fledged "SMTP servers", above) that are targetted at doing only some specific thing, without the need to spend the resources to run a SMTP server. Such a program might not listen for incoming messages and only run when there is something to send; typically it can only pass messages to other MTAs without queueing, routing, or modifying anything. See LightSMTPagents for favourites.

An important reason the difference is made is that SMTP requires MTAs to take responsibility for handling the message the moment it accepts it. That is, if after receiving all the data it reports successful acceptance of the message, that acceptance includes taking responsibility for not subsequently losing the message. If after trying really hard it cannot deliver the message it is supposed to report this back to the sender using a bounce message. This is why "SMTP servers" have to support queueing; "SMTP clients" do not, so this has to be handled in some different way. In the case of a MUA implementing "SMTP client" functionality, it usually can provide an outbox of sorts to make up for the lack of queueing support.

mutt and SMTP

mutt can't speak SMTP ... wait, it can ...
... or why mutt should not but slowly becomes an "all-in-1" program.

mutt was developed with the concept of "one task per tool", enabling performance through combination with other high quality modular programs. This is an aspect of the "unix philosophy".

Putting too much into an application wastes unused resources --either in storage (HDD/RAM) or in run-time performance-- when in many cases people don't even use this extra functionality, or it is covered by some other specialist tool. (With a commercial program you'd even have to pay for the unused code, would you do that if you had the choice?)

That's why --so far-- things have been kept separate (or out of mutt).

For quite some time basic MRA functionality has been included in mutt, which some consider a breach of the concept and therefore demand inclusion of SMTP support as well (and because "all the other MUAs have SMTP aswell"). The original reasons for the MRA part are not recorded (ed: anyone who knows shall fill in), but it makes sense to have MRA in mutt and not MTA:

  • MUA+MRA access&store msgs within your control-reach (pull),
  • MTA passes msgs beyond your control boundary (push).

On this abstract level, MUA+MRA combined cover 1 area so they can both go into one application like mutt, while MTA covers another. IMAP already works with a folder system, so it's a simple step to include that into mutt, and with the URL-syntax POP can be treated like a remote folder, too.

"This entire concept is rubbish and the mutt developers are just plain lazy [to add all the good stuff]."

Well, it seems the force of the masses is hard to withstand though ... recently experimental minimal SMTP support has been added to mutt as an option. If you fail to use a separate local MTA with mutt, try this failsafe. But still the preferred way is the MTA way. Choose your own optimal way for (multi-account) maintenance.

MDA: Mail Delivery Agent

The MDA accepts a piece of mail from an MTA and performs the actual delivery (including processing aka "filtering") to the user's mail folders (see FolderFormat). Most MTAs come with a simple MDA (e.g. sendmail's mail.local). Some popular MDAs include:

Some typical uses for filtering include:

  • sorting into multiple incoming folders.
  • pre/post-processing to "fix" or improve display/ management (like attachments).
  • automatic replies (but be careful not to respond to spammers)
  • Spam-defense: static black-/white-list, dynamic like spam-assassin (URL?), and other examples (URLs?).
  • Virus-checking: but that should be better done already at MTA level.
  • ...

MRA: Mail Retrieval Agent (POP/IMAP client)

If you're lucky, then you might be already logged into the mail-server with a cmd-shell to read your mail with mutt. If you're less lucky, then you might be allowed to login remotely via ssh and start mutt on a mail-server cmd-shell. In both cases you would not need any MRA, because you could access your inbox directly off the mail-server's local filesystem, but both cases are rare. Typically your mail is stored on a mail-server which is different from the machine where you want to read your mail, then you have to get your mail transfered somehow.

In organizations this sometimes is provided via NFS, which means the remote mail-server filesystem appears on your local machine as if it were local, too (keyword "mount"). As end-user normally you don't notice a difference, and likewise there is no need for you to configure anything with your MUA.

As regular private user (or even in organized environments) you typically have to download (and can even store back) your mail via IMAP or POP by means of an MRA to store & access it locally. For simple/ casual use, MRA functionality has been implemented into mutt (like most MUAs do), but only in so far as to allow to speak POP + IMAP. Mutt treats POP-/IMAP-access like local folders when you use the URL-syntax (see MuttGuide/Folders?). However, mutt does not process any messages through an MDA! Only real MRA do this.

For frequent/ regular use or when MDA functionality on the mail-server is limited, it's recommended to employ a dedicated MRA to manage the transfer automatically and to allow for post-processing and local delivery. Examples are:

Note

Those are by far not the only possible schemes, many variations exist.

For example the POP/ IMAP retrieval program may directly drop emails in the user mailbox (acting as an MDA) or may transmit the incoming mails directly to a dedicated mail delivery program, skipping the local mail server at all (a good idea in a system without a local server).

The local server could directly append the incoming messages to the user mailbox, skipping completely a dedicated mail processing agent, acting as a delivering agent.

Finally the MUA could directly connect itself to the local or remote server (as most MUAs do) acting as an SMTP client and it may fetch the mails directly from a remote POP/ IMAP server (as mutt can actually do) skipping entirely the whole retrieval program, local mail server, mail processing/delivery program chain.

see also: