Understanding SMTP Transport

Much of the material in this chapter relies upon an understanding of some key aspects of SMTP mail delivery. In particular, it's important to understand the distinction between the envelope headers, the message headers, and the message data. Envelope headers are From and To addresses that the sending computer provides when it makes an SMTP connection. The To envelope header, in particular, is extremely important, because that's what the receiving system uses to determine to whom the message should be delivered.

The message headers, by contrast, are provided as part of the message data, which also includes the text to be delivered to the recipient. Message headers tend to be fairly extensive on most real e- mails . They include From: and To: headers, but these are of limited value compared to the envelope From and To headers, because they're easily forged or altered . Message headers also include Received: headers, which indicate the route that the message has taken, a Subject: header that's displayed in most e-mail readers, and various others.

NOTE

Message header names are always followed by colons in the e-mail text stream, and I use that convention in this chapter. Envelope header names are usually not followed by colons, although that convention isn't universal. SMTP servers that use the maildir format don't store envelope headers under the From and To names in the message, although they're still used in SMTP transactions. Some servers can be configured to store the From and To addresses in message Received: headers, which can be a useful tool in tracking down problems.

To understand something of how SMTP works, it may help to follow an SMTP transaction. Listing 19.1 shows such an exchange, entered manually via a Telnet connection. (Most SMTP transactions, of course, don't involve a manual Telnet connection.)

Listing 19.1 A sample SMTP session

 $  telnet louiswu.rodsbooks.com 25  Trying 192.168.1.5... Connected to louiswu.rodsbooks.com. Escape character is '^]'. 220 louiswu ESMTP Exim 3.12 #1 Wed, 30 Oct 2002 12:01:29 -0500  HELO nessus.rodsbooks.com  250 louiswu Hello nessus.rodsbooks.com [192.168.1.3]  MAIL FROM:<[e-mail]>  250 <[e-mail]> is syntactically correct  RCPT TO:<[e-mail]>  250 <[e-mail]> is syntactically correct  DATA  354 Enter message, ending with "." on a line by itself  From: <[e-mail]>   To: <[e-mail]>   Subject: A Sample SMTP Session   This is the text of the message.   .  250 OK id=15z87H-0000CX-00  QUIT  221 louiswu closing connection Connection closed by foreign host. 

Most SMTP exchanges begin with the client system (which is usually a mail reader program or another MTA, or in the case of Listing 19.1 a human using telnet ) identifying itself with a HELO or EHLO command. This out of the way, the client uses the MAIL FROM: and RCPT TO: commands to provide the envelope From and To headers, respectively. After each of these commands, the server MTA replies with a numeric code to indicate whether it can accept the given command. The text following those codes is generated for human consumption, should a human need to debug or oversee the process. The DATA command signals that the sender is ready to begin entering the body of the message. Thereafter, the sender enters the message headers and the text of the message. (The message headers are actually optional; they could be omitted from Listing 19.1 and the message would still be delivered.) A single blank line separates the message headers from the rest of the message body. A lone period ( . ) on a line signals the end of the message, at which point the recipient MTA delivers it.

There are several features of an SMTP transaction, and of the message sent during the exchange, that are important for certain configuration options. These include:

• Sender identification ” The sending system identifies itself in several different ways. These include the HELO command, the MAIL FROM command, and the From: header. If the sender is in fact relaying mail from another site, the MAIL FROM and From: headers may legitimately differ from the sender's address. The HELO command may or may not provide accurate information in practice, although in theory it should be accurate. Another detail you should note is that the recipient system can identify the IP address of the sender. In Listing 19.1, the recipient echoes this information back to the sender ”the acknowledgment of the HELO command includes the sender's IP address.

• Envelope and message headers ” In Listing 19.1, the envelope and message headers match each other, but this need not always be the case. If you've ever received a message that doesn't appear to be addressed to you, this is how it happened ”the envelope To header was to you, but the message To: header wasn't. Because the envelope To header determines delivery, the message reached you. If your mail reader lets you examine full headers, you may be able to spot the envelope To header information.

• Options for aborting a message ” The recipient SMTP server can refuse delivery at any point along the way, from responding to the initial connection attempt to delivering the message after the sender has finished entering the data. Most message delivery and relay controls operate after the sender has issued a RCPT TO: command, but some may work before that point. Some senders re-try the delivery if a recipient aborts the transfer before the RCPT TO: command, which can cause wasted network bandwidth on the repeated attempts. Aborting after the DATA command can waste bandwidth if the sender's message is unusually long.

• Information delivery by the server ” The exchange shown in Listing 19.1 reveals some information about the server, but not other information. For instance, the server in this example clearly identifies itself as Exim 3.12. Although it's difficult to hide the MTA package in use, some programs let you hide the version number, which can be a useful security precaution in case a security bug is found in the server ”you don't want to advertise your vulnerability unnecessarily. The Exim configuration in Listing 19.1 responds to the MAIL FROM: and RCPT TO: commands with a 250 code and a fairly unrevealing is syntactically correct message. Some servers can be configured to reject mail after RCPT TO: if the specified user doesn't exist. This can provide information that could be useful to crackers ”by trying many names with this or other mail server commands, crackers can locate account names. Exim in this example doesn't give out this information. On the other hand, this can cause problems because the mail server must process and then bounce messages addressed to users who don't exist.