The below questions are not my own, you can reach the author at
-Ian! D. Allen - idallen@idallen.ca - http://www.idallen.com/
A common misconception: the place/protocol you use to fetch your email
is the same place/protocol that you use to send your email:
- sending email uses SMTP
- reading email uses POP3 or IMAP
- they can be completely separate machines
http://wiki.mutt.org/?MailConcept
Q: T/F, unlike POP3, SMTP can be used to both send and receive email.
Q: T/F, unlike SMTP, POP3 can be used to both receive and send email.
- may be completely different servers
- though note POP-before-SMTP (SMTP-after-POP) requires coupling:
http://tools.ietf.org/html/rfc2476 (section 3.3)
"Requiring a POP [POP3] authentication (from the same IP address)
within some amount of time (for example, 20 minutes) prior to the
start of a message submission session has also been used, but this
does impose restrictions on clients as well as servers which may
cause difficulties. Specifically, the client must do a POP
authentication before an SMTP submission session, and not all clients
are capable and configured for this. Also, the MSA must coordinate
with the POP server, which may be difficult. There is also a window
during which an unauthorized user can submit messages and appear to
be a prior authorized user."
Q: Describe briefly how POP-before-SMTP works to authenticate an SMTP session.
MUA - Mail User Agent (email client)
- the user's interface to the protocols - "presentation layer"
- usually gives access to functionality of both MTA and MRA/MAA
- but may not itself implement any protocols (may read/write file system)
http://en.wikipedia.org/wiki/Mail_user_agent
"An e-mail client, also called a Mail User Agent (MUA), is a computer
program that is used to read and send e-mail.
Originally, the MUA was intended to be a simple program to read the user's
mail messages, which the mail delivery agent (MDA) in conjunction with
the mail transfer agent (MTA) would transfer into a local mailbox.
The most important mailbox formats are mbox and Maildir. These rather
simple protocols for locally storing e-mails make import, export and
backup of mailfolders quite easy.
E-mails to be sent would be handed over to the MTA, perhaps via
a mail submission agent [MSA], therefore an MUA would not have to
provide any transport-related functions.
*Since the various Microsoft Windows versions intended for home use never
*provided an MTA, most modern MUAs have to support protocols like POP3
*and Internet Message Access Protocol (IMAP) to communicate with a remote
*MTA located at the e-mail providers machine."
- user agents (MUAs) are user-visible email clients of all descriptions
- e.g. mutt, "mail", "Mail", "mailx", pine, elm
- e.g. KMail, Eudora, MS Outlook
- e.g. web-browser email (Netscape Messenger,Mozilla,Thunderbird)
- e.g. webmail, Horde, SqurrelMail
http://en.wikipedia.org/wiki/List_of_mail_servers#POP.2FIMAP
Q: Briefly describe the function of a mail system MUA.
MSA - Mail Submission Agent
http://tools.ietf.org/html/rfc2476
"acts as a submission server to accept messages from MUAs, and either
delivers them or acts as an SMTP client to relay them to an MTA."
- enforce policy (no open relay)
- enforce standards (no forged headers, etc.)
- enforce filtering (SpamAssassin, etc.)
- may modify messages (section 8 of RFC)
http://en.wikipedia.org/wiki/List_of_mail_servers#Mail_filtering
Q: Briefly describe the function of a mail system MSA.
MTA - Mail Transfer Agent (mail server, mail exchange server)
"A process which conforms to [SMTP-MTA], which acts as an SMTP server to
accept messages from an MSA or another MTA, and either delivers them or
acts as an SMTP client to relay them to another MTA."
http://en.wikipedia.org/wiki/Mail_transfer_agent
"It receives messages from another MTA (relaying), a mail
submission agent (MSA) that itself got the mail from a mail user
agent (MUA), or directly from an MUA, thus acting as an MSA
itself. The MTA works behind the scenes, while the user usually
interacts with the MUA. The delivery of e-mail to a user's
mailbox typically takes place via a mail delivery agent (MDA);
many MTAs have basic MDA functionality built in, but a dedicated
MDA like procmail can provide more sophistication."
- transfers email between machines (other MTAs) via SMTP
- Internet-facing, open ports: security issues
- sendmail, postfix, qmail, exim
- may have MDA ability to transfer email to user's mailbox
http://en.wikipedia.org/wiki/List_of_mail_servers#SMTP
Q: Briefly describe the function of a mail system MTA.
MDA - Mail Delivery Agent
http://en.wikipedia.org/wiki/Mail_delivery_agent
"A Mail Delivery Agent (MDA) is software that accepts incoming e-mail
messages and distributes them to recipients' individual mailboxes
(if the destination account is on the local machine), or forwards
back to an SMTP server (if the destination is on a remote server).
A mail delivery agent is not necessarily a mail transfer agent (MTA),
although on many systems the two functions are implemented by the
same program."
- Unix/Linux: /bin/mail, procmail
Q: Briefly describe the function of a mail system MDA.
MRA/MAA - Mail Retrieval Agent / Mail Access Agent
http://tools.ietf.org/html/rfc1939 - POP3 port 110
http://tools.ietf.org/html/rfc3501 - IMAP-V4-R1 port 143
- often built-in to mail clients (MUAs)
- can be stand-alone
- e.g. fetchmail gets the mail; MUA reads mail from file system
Q: Briefly describe the function of a mail system MRA/MAA.
Mail server comparison
----------------------
http://en.wikipedia.org/wiki/List_of_mail_servers
- see comparison near bottom
- PUSH protocols - sending email: MTA - SMTP
- PULL protocols - reading email: MRA/MAA - POP3, IMAP
MDAs write local mailboxes; they may not implement Internet protocols
(unless they have to forward off-machine without benfit of an MTA).
Single-user PCs often don't run separate MTA or MRA/MAA programs.
Your chose of mail reader (e.g. Pine, Elm, Outlook) itself PULLs your
incoming email from a remote server (acting as an MRA/MAA) and then
PUSHes your outgoing email to the remote server (acting as an MTA).
Q: What is the difference between a PUSH protocol and a PULL protocol?
Q: T/F, SMTP is a PUSH protocol.
Q: T/F, POP3 is a PUSH protocol.
Q: T/F, HTTP is a PUSH protocol.
A History of MTAs
-----------------
I. Incoming - delivering your incoming email via SMTP:
* Sending email into Unix/Linux machines:
Unix/Linux was traditionally multi-user and ran its own MTA
(e.g. sendmail) that accepted incoming SMTP connections. Remote systems
could use SMTP to drop off your email with your local MTA (sendmail),
and the MTA would hand the email to an MDA (/bin/mail, procmail)
to put it in your mailbox in the local file system. Your MUA
(e.g. /usr/ucb/Mail) would read the mail from your inbox (no need
for POP3 or IMAP in any MUA). There are a few different conventions
for inbox formats so that many different MUAs can read your email,
all without knowing POP or IMAP.
- sendmail (running as root!) has had many security patches
- the first Morris Internet worm (Nov 1988) used sendmail security holes
- http://en.wikipedia.org/wiki/Morris_worm
Q: Why don't many Unix MUAs need to know how to run POP or IMAP?
Current single-user Unix/Linux PCs often have a local-only MTA
that handles the sending and delivery of local on-machine email but
doesn't accept SMTP from off-site. (Best to keep ports closed on
Internet-facing machines!)
On recent single-user Unix/Linux workstations, the MUAs mimic their
Windows counterparts and include MRA/MAA features. Your chosen MUA
(e.g. Elm, Pine, Mutt) is responsible for fetching your email via POP3
or IMAP (this is an MRA/MAA function); or, you use an intermediate
MRA/MAA program such as "fetchmail" and your MUA reads the mail out
of the local file system after the MRA/MAA has put it there.
- no Internet-facing MTA means fewer open ports and fewer attacks
- don't run an Internet-facing MTA if you don't need it
* Sending email into MS Windows machines (or not):
Windows had (has?) no MTA - you can't send an email to a Windows PC
using SMTP. Your personal Windows MUA has to fetch the email itself
via POP3 or IMAP and keep a copy in the local file system.
- no open ports for incoming email; no open mail port security issues
* Note that MUAs that implement POP/IMAP typically store the email in
the local file system in a format that only that MUA can handle.
(Thunderbird can't use an Outlook mail folder, and vice-versa.)
The concept of a common inbox format usable by different MUAs was lost.
Q: T/F, the standards for inbox formats developed under Unix were adopted
by MUAs on PCs, so that different MUAs can read the same inbox.
II. Outgoing - sending your outgoing email via SMTP:
* Unix/Linux machines have traditionally each had their own MTA (sendmail)
that could directly deliver email on the Internet using MX record lookup.
Every local Unix MUA would put email into a directory where the MTA
(sendmail) would eventually pick it up and transfer it, retrying as
necessary. No MUA needed to know how to do SMTP; only the MTA did that.
You could optionally tell your machine's MTA not to send mail directly
to its destination via SMTP over the Internet, but to use a remote
"smart" MTA that could accept your outgoing email and figure out
how to deliver it. (You have to use such a "smart" host here at
Algonquin; since, you cannot connect to any off-campus SMTP servers.)
The MTA on your machine would use SMTP to drop off the queued mail at
the smart host, and the smart host would do the MX record lookup and
final SMTP delivery.
Since the local Unix MTAs were separately scheduled programs, you could
queue email from a MUA into the file system even when your machine was
not connected to the Internet. The MUA or local MTA would queue up
your email in the file system until your MTA was finally able to make
a connection to deliver it off-machine. (In the days of modems, the
Internet connection was often made late at night when rates were lower.)
Q: Why don't most Unix MUAs need to know SMTP?
Current single-user Unix/Linux PCs now have MUAs that mimic their
Windows counterparts - the MUAs ignore the file system and the local
MTA and expect you to give the name of a remote "smart" MTA to which
all email will be sent via SMTP for actual delivery.
The Algonquin Linux lab has both types of mail systems: Command-line
email (e.g. the "mail" command) queues up mail for the local
MTA (sendmail) to send. (This is currently broken.) GUI MTAs
(e.g. Thunderbird, Mozilla) ignore the local file system and the local
MTA and use a "smart" remote MTA (e.g. outmail.algonquincollege.com)
to deliver the mail. (This supposedly still works.)
* MS Windows has no local MTA - no program exists whose job it is just
to deliver queued email. Each MUA has to know how to do its own
SMTP connection and each MUA has to be configured (separately!) with
the address of a smart MTA to which it connects. MUAs on Windows
machines all contain networking code to drop off email at some "smart"
MTA that does the actual delivery. There is no local MTA queue and
much duplication of SMTP code in all the MUAs.
On Windows, it is up to each MUA to deal with what happens if the
message being composed can't be dropped off right away at the remote
smart MTA. Better MUAs will queue the email for later transmission.
Poor MUAs will tell you that your mail can't be sent.
Q: Why do MUAs on Windows all need to know how to talk SMTP?
Q: Unix/Linux mail user agents didn't need to know how to talk to SMTP
servers - you never had to configure your "outgoing mail" preferences.
All the Windows MUAs need to be configured with a mail server. Why?
