MUAs, MTAs and other terms are used by email professionals to help
specify with precision what they are talking about.
Here are a few notes on what that means.
Mail handling is divided into three or more parts, depending on what
level of detail you want to go into. There's the client - a mail user
agent (MUA), the server that sends and queues mail - the mail transport
agent (MTA), retrieval from remote mailboxes (MRA), local delivery and
rewriting of messages - the mail delivery agent (MDA), and the remote
submission of messages (MSA).
The terms more precisely describe functions than describe software as
such. Sometimes a single program such as Mozilla Thunderbird or
Microsoft Outlook can combine multiple functions, in this case client,
retrieval, and processing rules. Sometimes they're separated out into
They are terms of convenience despite their confusing appearance. Exact
meanings can change with the context in which they are used.
For example, 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 which also has the
roles of MDA and MSA . The roles may be combined and are often not split
Mail User Agent is a 'mail client program', the part you see
and use to send and receive mail.
Mail Transfer Agent is anything between MUAs. MTAs generally
do the routing and transferring of mail between hosts, ISPs, and
so on, depending on how detailed one wants to be.
Mail Delivery Agent. 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.
On an ISP with lots of users that use MUAs on machines that
don't have their own MTA, it is not enough to simply let all those
users submit their messages to the MTA systems without any
authentication. Otherwise spammers will exploit this and abuse
the system. Accepting emails from users for sending elsewhere
becomes a specialized task, and an MTA that does that is called
A Mail Retrieval Agent makes connections to a
remote mailbox and fetches mail for local use. Fetchmail as a
standalone program is a common example.
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
The MUA is the front-end for the end user to manage and read stored
email into 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 mutt beyond default
Other popular MUAs include Thunderbird, Kmail, evolution, Sylpheed,
mulberry, pegasus, pine, and 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, queuing and retrying, sending if the next MTA
doesn't accept email immediately, or sending a notification back to the
original sender if the next MTA cannot handle the message. Reasons might
include such things as the receiving mailbox does not exist, is full or
unavailable, or that it doesn't trust the sending MTA not to send spam.
On the internet, MTAs between themselves communicate via SMTP, the
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 targeted to perform a few
specific functions, without the overhead of the resources to run a
full-blown 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 queuing, routing, or modifying
anything. See SendmailAgents for favorites.
An important reason for these difference is that SMTP requires MTAs to
take responsibility for handling the message when it accepts it. After
receiving all the data it reports successful acceptance of the message,
Acceptance includes taking responsibility for not subsequently losing
the message. If after trying several times it cannot deliver the message
it will normally report this back to the sender via a bounce message.
"SMTP servers" have to support queuing; "SMTP clients" do not, as this
has to be handled in a more complex and reliable 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 queuing 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 as well"). 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
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
"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:
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 file
system, 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 transferred 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:
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.