PD4E9p1p1: Update for Message Transfer section (pp.
646-648)
Next, we look at SMTP – the protocol used to transfer messages from one host to another. SMTP is best understood by a simple example. The following is an exchange between sending host cs.princeton.edu and receiving host cisco.com.
... continue with last paragraph on p. 647, example, and p.648, with the following corrections:
· The colors in the example didn't print. Instead print C: at start of client lines, and S: at start of server lines.
· Mail gateway in second to last paragraph should be mail relay. "Gateway" has a special meaning in email as a relay at the boundary between two dissimilar (non-SMTP) networks [Kle08], [Cro08].
Modern mail handling systems are much more complex than just two hosts. A typical system has a network of SMTP Relays[1], each performing a specialized function, temporarily storing the message, then passing it on using SMTP. You can tell how many Relays handled a message by looking at the Received lines in the header. There should be one for each Relay.
Attempts to model real systems at the Relay level result in diagrams of unmanageable complexity [Fal04]. We can construct a simpler model if we focus on Actors (Users and Agents) [Cro08]. Figure 9.1 shows a typical system with the Relays grouped into functional blocks. In this diagram, we have named the blocks by the role they play in processing a message. Each Actor can have multiple blocks, each block can have multiple hosts, and each host can have multiple Relays running as independent daemon processes. A Transmitter might have a dozen Relays, operating in parallel to handle a large mailflow. An MDA might have a process dedicated to managing a large mailstore, another running a POP/IMAP server, and another providing a webmail interface.
Figure
9.1 Actors (Users and Agents) and
their roles in a typical email system.
To understand a mail handling system, including its security vulnerabilities, we need to understand the roles and responsibilities of each Actor and the relationships between them. Figure 9.1 is a simplified model of just one system. There are many other possibilities. We might add a Forwarder between the Receiver and the MDA, or an Open Relay floating in the cloud. We might have more than one role played by each Actor. We might add another layer of organization, showing a group of Actors organized as an MRN (Mail Receiving Network) [Moo05], or an ADMD (Administrative Management Domain) [Cro08]. A diagram like Figure 9.1 could get quite complex. A shorthand notation [Mac08] will allow us to show the relevant networks, actors, roles, and relationships. Here is a basic system with four Actors (two Users and two Agents), organized as two networks:
|---
Sender's Network
---| |--
Recipient's Network -|
/
Author ==> MSA/Transmitter
--> / --> Receiver/MDA ==> Recipient
/
Border
The double arrow shows a direct relationship between Actors (e.g. a contract between the Author and his ISP). The single arrow shows only the direction of mail flow. There is no relationship between Agents across the Border to the open Internet. The / shows multiple roles being played by one Actor. Using these diagrams, we can model almost any system, and include a lot of detail on relationships, but not lose the simplicity of Figure 9.1. The elements of the model (Actor's roles) are the fundamental building blocks.
Here is an extension of the basic system, adding a Forwarder role, played by the same Actor as the Receiver. Both the Receiver/Forwarder and the MDA have a direct relationship with the Recipient, so they have an indirect relationship with each other. These details are important in discussions of authentication protocols.
|-------- Recipient's Network ---------|
/
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border
If we wonder why email continues to be such an insecure system, we can study this last example. Authentication protocols which try to correlate the Transmitter's domain name to the connecting IP address can fail when a Forwarder is involved. We cannot just dismiss Forwarding as an "edge case", however. It is important for a user who changes jobs or ESPs (Email Service Providers), and would like to continue receiving mail at his old address.
Let's follow a message from start to finish. The scenario begins with an Author composing a message using his mail client. There are countless mail clients available, just like there are many web browsers to choose from. In fact, most web browsers now include a mail client, or at least a mechanism to invoke the user's preferred client when he clicks a mailto: link in a webpage.
When the Author clicks SEND, his mail client connects to an MSA at his ESP, and the message is transferred using SMTP. A key responsibility of the MSA is to authenticate the Author. This can be done with a password, by assigning the client a static IP address, or by having the client on the MSA's local network, not directly connected to the Internet.
Most large ESPs operate their own transmitter Relays, but many smaller ISPs and organizations with a lot of bulk mail, subcontract this specialized role to another Agent. The Transmitter's responsibilities include prevention of outgoing spam, and providing some means to prove their identity to unrelated Receivers. It isn't enough to say "HELO, this is trustme.com". Any spammer can do that. The Transmitter must provide some "out-of-band" data using a service like DNS that is more trusted than email. Both parties must use the same authentication method. There is no standard authentication method, and that is a problem with SMTP. A fundamental goal of email is reliable communication with no prior relationship between sender and receiver.
Email authentication methods fall into two categories. Methods like SPF, SenderID, and CSV rely on the fact that certain IP addresses are firmly under the control of a sender (an individual or organization identified by its domain name). Methods like DKIM rely on a digital signature applied to the entire message and most of its headers. Both depend on the security of DNS. Only the domain owner has access to the DNS records under his name. With IP-based methods, the sender publishes in DNS the IP addresses authorized to use his domain name. With signature-based methods, the sender publishes a public key. IP methods can be very efficient, rejecting an entire session without transferring any messages. End-to-end signature methods can be very secure, even with an un-trusted Forwarder in the middle.
The Receiver's responsibilities include a number of functions we might call "Border defense" – blocking a DoS attack, authenticating the sender, and various spam-blocking strategies, including whitelisting, blacklisting, statistical analysis of message content, and use of heuristic rulesets that have proven effective in separating spam from legitimate mail. Border defense should be done at the Border. Loss of mail due to violations of this principle is common. A forwarded message can look like a forgery, and then the MDA has a tough choice – drop the message with no notice to the alleged sender, or send the notice and risk being reported for "bounce spam".
The problems with mis-configured mailsystems can be avoided if all Actors understand how the system works. When a Recipient sets up forwarding from his old Receiver/Forwarder to his new MDA, he should make sure that the Forwarder is whitelisted by the MDA. Forwarders should make sure that Recipients (unsophisticated users) understand this. MDAs should understand that forwarding is a common need, and make it easy for Recipients to whitelist at the domain level. Simple models will help reduce the confusion.
References:
[Kle08] J.
Klensin, ed, "Simple Mail Transfer Protocol", RFC-5321, 2008, http://tools.ietf.org/html/rfc5321.
[Fal04] P. Faltstrom, mail-flows-0.4, Jan 6, 2004, http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf
[Cro08] D. Crocker, "Internet Mail Architecture", 2008, http://tools.ietf.org/html/draft-crocker-email-arch-10.
[Moo05] K.
[Mac08] D.
MacQuigg, "Models for Mail Handling Systems", 2008, http://open-mail.org/MHSmodels.html