Email Overview
Architecture: The mail system is comprised of client end points and mail servers. The servers both relay mail and deliver mail to end users. The mail servers are called MTA's, Mail Transfer Agents and MDA, Mail Delivery Agents. The first TLA refers to the server's role in routing and relaying, the second TLA refers to the server's role in mail drop delivery. The clients are called MUA, Mail User Agents.
Unix email originally used Sendmail, written by Eric Allman, as the standard MTA and MDA, combined. "mail" was the original MUA. These all typically ran on the same machine, with sendmail receiving and sending mail to other machines using the SMTP protocol, and depositing mail for user agent pickup in a file using the quasi-standard mbox format. Sendmail is complicated to configure, and has had some famous security flaws. One such flaw (the -d option) was exploited by the Morris worm, which succeeded in crashing the entire Internet on November 2, 1988. Replacements for Sendmail include Postfix, by Wietse Venema, and Qmail, by Dan Bernstein. All three are outstanding programs by outstanding computer scientists.
Procmail is an example of an alternative MDA. It allows mail to be routed to an arbitrary program, and allows for filtering, vacation responses, automated handling of mail requests. Mail list software such as Mailman are also examples of alternative MDA's. The terms MTA, MUA and MDA have become standard. None of them appear in the original RFC, RFC 821. MTA and MUA appear in RFC 2821, and MDA appears in a FAQ linked directly off the Procmail home page.
Other MUA's replaced mail, even for command line unix. The two most popular command line replacements are pine and elm. Both of these are incrementally more user friendly than mail by using cursor based terminal interfaces, such as up and down arrows, and selections from a menu of options. They still only require a command line interface. This is good for system admins who need to log in remotely, or through shell scripts.
The original architecture, with centralized time share computing, found the MUA on the same machine as an MTA. Currently, MUA's more commonly run on the consumer's machine, separate from the mail server, which is located in a data center. It became desirable to route all mail through a central machine for several reasons:
Mail relays: Generally, the domain name of the recipient's email address is not tied to a specific machine, since machine names can correspond to specific machines, and machines come and go. The mapping from the domain name of the recipient's email address to the name of a particular machine handling mail for that address is provided by the MX record in the DNS system. Typically several MX records can be supplied, with a preference number of each record, providing backup machines if one machine is down. MTA's are first required to query for a list of MX records and to pick the most preferred address among those that are currently available.
CNAME's might also need be handled, but best-practices say that domain administrators should not mix CNAME's and MX records. (I think? See RFC 974 for a fuller discussion.)
Some MTA's will accept mail for any email recipient. If the MTA did not really handle mail for the recipient, it could not deliver it to an MDA, rather it would relay the mail to another MTA. This creates a problem with control of spam, as the relaying machine "gets blamed for" the spam, rather than the source of the spam. Now either MTA's will simply not relay mail, or require authentication if a relay is required. A MUA using an MTA to send mail, is asking the MTA to relay. Therefore the SMTP protocol needed to be expanded to allow username and password authentication, and then, consequently, expanded to secure variants of SMTP so the password is not sent clear. Another way was "POP before SMTP", where the SMTP protocol was not changed, but a POP session was established first. The POP server communicated the IP address of the authenticated user to the SMTP server, and the SMTP would then make that IP address eligible for relay services.
Protocols: The SMTP is described in RFC 821 and updated in RFC 2821. POP and IMAP allow for communication between the mail drop the the MUA. POP is just a way to read an mbox, and to perhaps delete items from the mbox. It has limited ability for multiple access to the mbox (the mbox is locked throughout a POP session). IMAP also allows "folders", which are in fact multiple mbox's, not folders at all but files, and to created such files, rename them, move mail between them, and can handle simultaneous multiple accesses to the data files. Part of their virtues is that they follow the unix standard of text-compatible wire protocols, which allow diagnosis, documentation and testing; and that they maintain compatibility with mbox formats, allowing all previous tools to continue to run.
SMTP servers listen at well-known TCP port 25; POP3 at well-known TCP port 110; POP2 at port 109; and IMAP at port 143. Since POP and IMAP require passwords, there are security concerns with using these protocols in the clear, so secure variants are available, where the protocols are unchanged, but the connections are secured by SSL. To avoid confusion, secure POP and secure IMAP are at different ports, port 995 and port 993, respectively.
Mail content: The proper format for the text of email is defined by RFC 822. Email has a header and a body, separated by a blank line, the first blank line in the email text. The header is a sequence of name value pairs, many are mandatory, many have standard meanings. The text format is very restrictive. The MIME standard allows more complicated documents to be sent within the 822 standard. In particular, multipart mail allows the same mail to be sent in various formats, plain text and html, for instance, so that mail can be read universally, but on sufficiently luxurious platforms, will have sophisticated formating, including pictures, hyperlinks, and so forth. Multipart and MIME also accommodates attachments, including compressed and archived files.
Each capability introduces new security problems. Some users of email will only use command line tools for reading mail, which skip MIME and attachments. This is, in my opinion, recommended practice when running as administrator.
MX Records
Mail is sent to a user at a domain. For instance, burt@cs.miami.edu has burt as the user and cs.miami.edu as the domain. The syntax of the username is related to what can and can't be done on the target machine. To the right of the at-sign, however, the syntax belongs to the specfications of the DNS system. The dot-seprated labels describe a path of delegation of authority, in this case, from the DNS root servers to the edu DNS server, to the miami.edu DNS server, to the cs.miami.edu DNS server.
What is requested is the MX record stored at the DNS server. Failing that, an A record is accepted. (Forget about CNAME records for the moment. They confuse me.) There can be multiple MX records for the domain, order by preference. The mail should be sent to one of these. Since the MX record returns a name, DNS is then used to retrieve the A record for this name, that is, the IP address, and then port 25 at this address is contacted.
burt@lambe% dig cs.miami.edu MX ; <<>> DiG 9.3.5-P1 <<>> cs.miami.edu MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13012 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2 ;; QUESTION SECTION: ;cs.miami.edu. IN MX ;; ANSWER SECTION: cs.miami.edu. 300 IN MX 10 phantom.math.miami.edu. ;; AUTHORITY SECTION: cs.miami.edu. 300 IN NS phantom.math.miami.edu. cs.miami.edu. 300 IN NS ns1.cs.miami.edu. cs.miami.edu. 300 IN NS umigw.miami.edu. cs.miami.edu. 300 IN NS miavax.ir.miami.edu. ;; ADDITIONAL SECTION: phantom.math.miami.edu. 3159 IN A 129.171.34.4 ns1.cs.miami.edu. 300 IN A 192.31.89.15 ;; Query time: 123 msec ;; SERVER: 209.68.1.135#53(209.68.1.135) ;; WHEN: Fri Mar 13 01:34:15 2009 ;; MSG SIZE rcvd: 167
SMTP Protocol and RFC 822 Headers
The SMTP protocol is simple and uses simple ASCII messages. Generally, the protocol begins with the client connecting and receiving back a banner from the SMTP server. Then a HELO or EHLO is sent from the client; next a MAIL FROM, next one or more RCPT TO, followed by DATA. After the DATA command is accepted, we enter the world of RFC 822 headers, and finally the body of the message. The 822 headers can further punt and claim the message body with be in MIME, which allows complicated multi-media content can be sent inside the message body.
The RCPT TO command can be repeated, so that a single DATA body is sent to multiple recipients. Relaying of mail can either by forwarding or remailing, depending on whether that envelope addresses are different between the receiving and sending of the mail for relay. Remailing will update the MAIL FROM, so that bounced or replies will go back to the remailer, not the original email source. A "plain message forward" will keep the original MAIL FROM, so that the relay is transparent.
Here is a sample session using telnet to connect to the server. Often port 25 is blocked. There are reasons why the network wants to restrict what machines play the role of an SMTP client.
burt@lambe% telnet phantom.math.miami.edu 25 Trying 129.171.34.4... Connected to phantom.math.miami.edu. Escape character is '^]'. 220 phantom.math.miami.edu ESMTP Sendmail 8.14.3/8.14.3; Fri, 13 Mar 2009 01:34:38 -0400 (EDT) EHLO jone.doe.com 250-phantom.math.miami.edu Hello lambe.pair.com [209.68.1.135], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 52428800 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN 250-DELIVERBY 250 HELP MAIL FROM:<john@doe.com> 250 2.1.0 <john@doe.com>... Sender ok RCPT TO:<burt@cs.miami.edu> 250 2.1.5 <burt@cs.miami.edu>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself hello . 250 2.0.0 n2D5Ycxh095201 Message accepted for delivery QUIT 221 2.0.0 phantom.math.miami.edu closing connection Connection closed by foreign host. burt@lambe%
This it the mail delivered. I relay my mail around a bit. It ends up on google. This is Show Original, which is great for looking at what really is in the mail. Headers are first, then a blank line, then the mail body.
The 822 headers are of interest. The To, From, Date and Subject that the user sees are all in the 822 headers. The headers also include delivery information, often a trace of various relays, or spam filters, through which the mail traveled. The headers can be updated after the mail has been delivered, to mark the mail as read, or to attach unique identifiers to the mail.
Each header is one or more lines. If more than one line, the additional lines being with at least one white space character. Else header lines must not being with any white space. A header lines has a name and a body. The name is a sequence of printable characters, digits, and the dash, followed by a colon and a space. The rest of the field is the body, and needn't have any specific format. The header section comes to a close with a blank line.
Delivered-To: burt.rosenberg@gmail.com
Received: by 10.142.158.20 with SMTP id g20cs6058wfe;
Thu, 12 Mar 2009 22:35:45 -0700 (PDT)
Received: by 10.151.156.1 with SMTP id i1mr1244687ybo.6.1236922544649;
Thu, 12 Mar 2009 22:35:44 -0700 (PDT)
Return-Path: <burt@phantom.math.miami.edu>
Received: from mcclellan.cs.miami.edu (mcclellan.cs.miami.edu [192.31.89.6])
by mx.google.com with ESMTP id 25si4098057gxk.94.2009.03.12.22.35.44;
Thu, 12 Mar 2009 22:35:44 -0700 (PDT)
Received-SPF: pass (google.com: domain of burt@phantom.math.miami.edu designates 192.31.89.6 as permitted sender) client-ip=192.31.89.6;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of burt@phantom.math.miami.edu designates 192.31.89.6 as permitted sender) smtp.mail=burt@phantom.math.miami.edu
Received: by mcclellan.cs.miami.edu (Postfix)
id EAB6A11F829; Fri, 13 Mar 2009 01:35:43 -0400 (EDT)
Delivered-To: burt@mcclellan.cs.miami.edu
Received: from phantom.math.miami.edu (phantom.math.miami.edu [129.171.34.4])
by mcclellan.cs.miami.edu (Postfix) with ESMTP id CBDB811F827
for <burt@mcclellan.cs.miami.edu>; Fri, 13 Mar 2009 01:35:43 -0400 (EDT)
Received: from phantom.math.miami.edu (localhost [127.0.0.1])
by phantom.math.miami.edu (8.14.3/8.14.3) with ESMTP id n2D5ZfVI095231
for <burt@mcclellan.cs.miami.edu>; Fri, 13 Mar 2009 01:35:41 -0400 (EDT)
(envelope-from burt@phantom.math.miami.edu)
Received: (from burt@localhost)
by phantom.math.miami.edu (8.14.3/8.14.2/Submit) id n2D5ZfHT095230
for burt@mcclellan.cs.miami.edu; Fri, 13 Mar 2009 01:35:41 -0400 (EDT)
(envelope-from burt)
Received: from jone.doe.com (lambe.pair.com [209.68.1.135])
by phantom.math.miami.edu (8.14.3/8.14.3) with ESMTP id n2D5Ycxh095201
for <burt@cs.miami.edu>; Fri, 13 Mar 2009 01:35:26 -0400 (EDT)
(envelope-from john@doe.com)
Date: Fri, 13 Mar 2009 01:34:38 -0400 (EDT)
From: john@doe.com
Message-Id: <200903130535.n2D5Ycxh095201@phantom.math.miami.edu>
To: undisclosed-recipients:;
X-Math-Scanned: Phantom Zone Evaluation
hello
This time we do 822 headers. They occur first and then a blank line, then the message. We also show a line with just a dot (it will be dot dot, because a single dot terminates the line), and we show what happens if we try to relay mail.
burt@lambe% telnet phantom.math.miami.edu 25 Trying 129.171.34.4... Connected to phantom.math.miami.edu. Escape character is '^]'. 220 phantom.math.miami.edu ESMTP Sendmail 8.14.3/8.14.3; Fri, 13 Mar 2009 01:42:35 -0400 (EDT) EHLO john.doe.com 250-phantom.math.miami.edu Hello lambe.pair.com [209.68.1.135], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 52428800 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN 250-DELIVERBY 250 HELP MAIL FROM:<john@doe.com> 250 2.1.0 <john@doe.com>... Sender ok RCPT TO:<burt@gmail.com> 550 5.7.1 <burt@gmail.com>... Relaying denied. Proper authentication required. RCPT TO:<burt@cs.miami.edu> 250 2.1.5 <burt@cs.miami.edu>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: jimmycarter@whitehouse.gov To: mylittlepony@excuseme.ru X-huh: I really cant talk about it Hi. .. . 250 2.0.0 n2D5gZrI095349 Message accepted for delivery QUIT 221 2.0.0 phantom.math.miami.edu closing connection Connection closed by foreign host. burt@lambe%
Here is the mail as received. Note how To and From are handled, distinct from the MAIL FROM and RCPT TO envelopes.
Delivered-To: burt.rosenberg@gmail.com
Received: by 10.142.158.20 with SMTP id g20cs6359wfe;
Thu, 12 Mar 2009 22:44:48 -0700 (PDT)
Received: by 10.150.134.21 with SMTP id h21mr1489847ybd.221.1236923088002;
Thu, 12 Mar 2009 22:44:48 -0700 (PDT)
Return-Path: <burt@phantom.math.miami.edu>
Received: from mcclellan.cs.miami.edu (mcclellan.cs.miami.edu [192.31.89.6])
by mx.google.com with ESMTP id 9si1204687gxk.17.2009.03.12.22.44.47;
Thu, 12 Mar 2009 22:44:47 -0700 (PDT)
Received-SPF: pass (google.com: domain of burt@phantom.math.miami.edu designates 192.31.89.6 as permitted sender) client-ip=192.31.89.6;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of burt@phantom.math.miami.edu designates 192.31.89.6 as permitted sender) smtp.mail=burt@phantom.math.miami.edu
Received: by mcclellan.cs.miami.edu (Postfix)
id 74A6511F82A; Fri, 13 Mar 2009 01:44:47 -0400 (EDT)
Delivered-To: burt@mcclellan.cs.miami.edu
Received: from phantom.math.miami.edu (phantom.math.miami.edu [129.171.34.4])
by mcclellan.cs.miami.edu (Postfix) with ESMTP id 557D411F827
for <burt@mcclellan.cs.miami.edu>; Fri, 13 Mar 2009 01:44:47 -0400 (EDT)
Received: from phantom.math.miami.edu (localhost [127.0.0.1])
by phantom.math.miami.edu (8.14.3/8.14.3) with ESMTP id n2D5iiLR095401
for <burt@mcclellan.cs.miami.edu>; Fri, 13 Mar 2009 01:44:44 -0400 (EDT)
(envelope-from burt@phantom.math.miami.edu)
Received: (from burt@localhost)
by phantom.math.miami.edu (8.14.3/8.14.2/Submit) id n2D5iid5095400
for burt@mcclellan.cs.miami.edu; Fri, 13 Mar 2009 01:44:44 -0400 (EDT)
(envelope-from burt)
Received: from john.doe.com (lambe.pair.com [209.68.1.135])
by phantom.math.miami.edu (8.14.3/8.14.3) with ESMTP id n2D5gZrI095349
for <burt@cs.miami.edu>; Fri, 13 Mar 2009 01:43:43 -0400 (EDT)
(envelope-from john@doe.com)
Date: Fri, 13 Mar 2009 01:42:35 -0400 (EDT)
Message-Id: <200903130543.n2D5gZrI095349@phantom.math.miami.edu>
From: jimmycarter@whitehouse.gov
To: mylittlepony@excuseme.ru
X-huh: I really cant talk about it
X-Math-Scanned: Phantom Zone Evaluation
Hi.
.
Mbox and MIME
A mail server can relay received mail, or, if the mail is at the end of its journey, the server will accept it. Accepting mail means to invoke the mail drop. For unix, this means writing the mail to the mbox file for the user. This was typically the file /var/mail/user-name. A user reading the mail locally would move the mail the their home directory in a file named mbox, ~user-name/mbox. The format of the mail drop file associated with the early mail deamons became a de factor standard called mbox format.
Mail is stored in a single mbox file. Messages are separate by inserting a blank line followed by the From line. Here is the top of my mbox file:
From ronmac@media-lab.media.mit.edu Wed Jan 24 16:49:35 1990
Return-Path: ronmac@media-lab.media.mit.edu
Received: from Princeton.EDU by notecnirp.Princeton.EDU (5.51/1.98)
id AA19316; Wed, 24 Jan 90 16:53:46 EST
Received: from media-lab.media.mit.edu by Princeton.EDU (5.58+++/2.29/mailrelay)
id AA13227; Wed, 24 Jan 90 16:48:22 EST
Received: by media-lab (5.57/4.8) id AA02895; Wed, 24 Jan 90 16:49:36 EST
Message-Id: <9001242149.AA02895@media-lab>
To: burt@Princeton.EDU (Burton Rosenberg)
Cc: ronmac@media-lab.media.mit.edu, ronmac@media-lab.media.mit.edu
In-Reply-To: Your message of Wed, 24 Jan 90 09:51:14 -0500.
<9001241451.AA25059@notecnirp.Princeton.EDU>
Date: Wed, 24 Jan 90 16:49:35 EST
From: ronmac@media-lab.media.mit.edu
Status: OR
real interesting here.....
later,
ronmac.
From katz@ux.acs.umn.edu Tue May 7 16:34:37 1991
Return-Path: katz@ux.acs.umn.edu
Received: from Princeton.EDU (Princeton.EDU.) by fs.Princeton.EDU (4.0/1.105)
id AA12729; Tue, 7 May 91 17:35:59 EDT
Received: from ux.acs.umn.edu by Princeton.EDU (5.61++/2.74/princeton)
id AA23910; Tue, 7 May 91 17:35:57 -0400
Message-Id: <9105072135.AA23910@Princeton.EDU>
To: burt@Princeton.EDU, nmk@math.Princeton.edu
Subject: Re: roots of 1
Date: Tue, 7 May 91 16:34:37 CDT
From: katz@ux.acs.umn.edu
Status: OR
n'th roots of i generate a field of degree EulerPhi(n) over Q, so lie in
a vector sp. of that dim over Q. Is this what you are talking about? nick
The From line marks new messages, so a normal line beginning with From has to be escaped. There are several methods to do this, some are buggy. Qmail man pages document this, christening mboxo, mboxrd, mboxc1 and mboxc2 as the "discovered" species of mbox in the wild. Mboxrd adds a > in front of a line begining with From(space). If a line in the message actually begins with >From, it will need another >, and so on. Here is an example in my mbox:
Alberto, Sorry I couldn't make the A&S system administration meeting on October 5. >From what I understand, you confirmed what you told me on the phone, which is that we can use Dell to recycle hardware that is useless
MIME: yes I should talk about MIME.
POP
Originally, mail was read from the mbox. The mail server deposited the mail into a per-user system mail box, and the user moved messages into a "read mail" mbox in their home directories. The style of remote shells is less attractive now, as the graphics are produced locally, and even a network friendly architecture, such as X, is inefficient for this regime. POP and IMAP are pull technologies to bring mail (in it's text form) to the client.
[Update 2011] As the pendulum now swings in the other direction, remote MUA's are very popular. The advancement of Javascript, the browser DOM and AJAX has made web-mail very attractive. I am proud to say UM had one of the first running web-mail servers in the world, see Wikipedia Webmail. Also, Window's RDP (Remote Desktop Protocol), and the platform neutral VNC (Virtual Network Computer) push forward the style of remoting the desktop of a centralized server, further advanced by having the remoted desktop running in a virtual machine on the remote server. Although X11 can do this, and represents a middle solution of application running on the server but graphics rendering done on the client desktop (in X11 terms, the client is the "server", since it is serving up its graphics capabilities, its keyboard mouse, and audio interface), use of X11 this way seems less popular than VNC.
POP is the simpler of the two protocols. By POP, everyone means POP version 3. It is described in RFC 1939. It runs on well-known TCP port 110, unless it uses a secure sockets connection, then SSL is used to port 995. Security is important since POP sends your password in the clear. POP is a simple protocol which attaches to the POP server, pulls down all new mail, and logs out. It does this every few minutes. Hence the password is on the wire several times an hour. For this reason, many POP providers will only offer POP through SSL.
The protocol, like SMTP, uses plain text, so that you can experiment or debug using a telnet session to the pop port. Telnet works for port 25. For SSL use openssl. Note that the pop server responds to each client request with a line beginning either +OK or -ERR, followed by a space, then optionally followed by commentary or other information. Responses that require more than one line, such as the download of an email, end with the termination sequence CR LF . CR LF. If a line in the response is supposed to be a single dot with no white space before or after it on the line, it has to be escaped. The POP standard is to prepend a dot to every line that begins with a dot. This is called byte stuffing. The dot is discarded on reception.
POP is limited. It basically only downloads mail or deletes mail. Typical uses for pop automatically deletes mail from the server once the mail is downloaded (although any pop server I know of can be configured to keep the mail). It does not do folders. It also does not do simultaneous connections. The POP RFC says that POP will lock the mbox while the POP connection is in progress.
hohokus:~ burt$ openssl s_client -connect pop.gmail.com:995
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc./CN=pop.gmail.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc./CN=pop.gmail.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc./CN=pop.gmail.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc./CN=pop.gmail.com
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIC3TCCAkagAwIBAgIDCDijMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDcxMDI1MTc1MzE2WhcNMDkxMjI0MTg1MzE2
WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN
TW91bnRhaW4gVmlldzEUMBIGA1UEChMLR29vZ2xlIEluYy4xFjAUBgNVBAMTDXBv
cC5nbWFpbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAO03QxerFKZV
8yeomuL4zSl8Pr7hMWnKMMgp/CwhwadeBmL0LQHHbjL/6z/Z59ZQvrztqkwhchA2
APKzUwRVTyn7Shx6vBqk6oFmTqoOLmY6hbq6l8uVdUv0AfbHwio8CnLpK2+nbuFl
flPwx1DH0E3grD8+CrH5SmScfTWbDkcXAgMBAAGjga4wgaswDgYDVR0PAQH/BAQD
AgTwMB0GA1UdDgQWBBTJRG/OFpZt+BV43JM3NshHMjpwazA6BgNVHR8EMzAxMC+g
LaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAf
BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADgYEAOKr3mhxtwFCS3J6lbeaf
3KrHKi935BZkI75sRbON+hog0t2ovcM2i7fxs3xneH8USLsHgfxNBj9tkMogMK/K
sO/NUVZ/IfyqcNNkp2619qTQXthKRH42JKpAKgNhT1bdno3pxn+eDEpqmU3CE7IP
HDCjWOK1fGkZ/yFAuTxuxAc=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=pop.gmail.com
issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 883 bytes and written 300 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 6B6B60516BF0158E0F2687321590CB184C6CBFDE696C9F60D7C78F2219031DBC
Session-ID-ctx:
Master-Key: DC73A61AF33419910E868FD9AB180327EAA23EED19B02579E7C0EB70529A7311C3E7D871F0C855111161D17AC718BD9E
Key-Arg : None
Start Time: 1236915508
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
+OK Gpop ready for requests from 98.64.13.178 34pf2184752yxl.44
user myusername
+OK send PASS
pass mypassword
+OK Welcome.
list
+OK 6 messages (26326 bytes)
1 3513
2 817
3 9063
4 2013
5 3357
6 7563
.
quit
+OK Farewell.
read:errno=0
hohokus:~ burt$
IMAP Protocol
IMAP is a alternative to POP. It supports a wide range of functions on the remote mail box, including manageing mail in folders, and simultaneous connections. Typical users of IMAP will keep there mail on the IMAP server, which tends to share a file system with the SMTP server that accepted the mail, but this is not necessary.
SPAM
I don't have a document to prove this, but probably the largest cost in running an email service is SPAM filtering. Spam is named after a food called Spam, which Monty Python satirized as being both ubiquitous and universally disliked. The proper name for Spam is either UBE, Unsolicited Bulk Email, or UCE, Unsolicited Commercial Email. In the US, Spam is regulated by the CAN-SPAM Act of 2003, however there is a viewpoint that this legislation was actually helpful to spammers.
One method to control spam is Black Lists. Public and internet-accessible lists are maintained of servers that have been classed as sending spam. If a server is set up to reference a Black List, it will accept no mail from a server if it is on the list.
A second method is Grey Listing. When an SMTP server is contacted by a client for the first time, the server gives a temporary rejection. By RFC, SMTP server must retry mail delivery for up to 3 days. On retry, the SMTP server accepts the mail. There are economic arguments why spamming clients won't retry. Essentially, the expected pay-off (averaged over the number of emails delivered) is so small that even from the spammer's point of view it is better to move to the next target than to maintain deferred mail queues.
Sender Policy Framework (SPF) has the domain name publish as TXT records who is allowed to send mail with their domain name.
Domain Keys Identified Mail (DKIM) uses public key cryptographyto sign outgoing messages. An 822 header in the mail directs any verifier to a DNS name. A TXT record is retrieved from the DNS system at that name, and it contains a public key. The signature on the mail is then verified. It should be, then, that the owner of this domain takes responsibility for the contents of the message.
References