The below questions are not my own, you can reach the author at -Ian! D. Allen - firstname.lastname@example.org - 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?