What do e-mail headers have to do with security, or more pointedly, why a column about e-mail headers? The short answer is, “because some of you asked for it.” (I mean that in a nice way.) For example, one subscriber wrote, “What are the different e-mail headers? About 50% of my logs are stripped headers. Some are obvious, but others are not (like ETRN).” A longer answer is, “the Firebox SMTP Proxy allows us to make security decisions based on headers, envelope information, and SMTP commands, and we should understand that which we can control.” I recently looked at the SMTP proxy with you. We’ll now look more closely at e-mail headers and SMTP commands.
Just as postal mail has an envelope and, inside the envelope, a letter, so does e-mail. The envelope will have address information on it, such as the sender, a list of recipients, and who should get errors if something goes wrong (or right, such as your Firebox rejecting an attempt to relay e-mail for a “spammer”).
Headers are “inside” the envelope, and considered part of the message. Just like the letter in the envelope of postal mail, e-mail messages often have headers with originator (sender) and destination (recipient) information, and a date. There are headers that contain what RFC822 and 2822 call “trace fields,” and headers that have identification information as well as headers labeled “informational” (the Subject: header, for example).
Let’s look at some examples. Here’s an e-mail message that contains some common headers, and a couple of not-so-common ones.
Return-Path:
<fred@avolio.com>
…
Received:
from [168.191.22.140] (helo=hub.avolio.com)
by dfw-mmp1.email.verio.net with esmtp
id 15a5m1-0003z3-00
for fma@al.org; Fri, 24 Aug 2001 01:28:38
+0000
Received:
from system1.avolio.com (system1.avolio.com [10.1.0.2])
by hub.avolio.com with ESMTP id
f7O1Sci13128
for <fma@al.org>; Thu, 23 Aug 2001
21:28:39 -0400
Errors-to:
<error@avolio.com>
Message-Id:
<4.3.2.7.2.20010823212648.00b38850@hub1.avolio.com>
X-Sender:
avolio@mail.veriomail.com
X-Mailer:
QUALCOMM Windows Eudora Version 4.3.2
Date:
Thu, 23 Aug 2001 21:27:04 -0400
To:
fma@al.org
From:
Frederick M Avolio <fred@avolio.com>
Sender:
<admin@avolio.com>
In-Reply-To:
<4.3.2.7.2.20010415150149.00b08080@mail.example.com>
Subject: test
We’re all familiar with the To:, From:, Date, and Subject: headers. Note, that this message is “from” me, but was sent by my administrative assistant, “admin.” Errors should get sent to the mailbox “errors.”
As discussed last month, some of these headers give out too much information. Received: lines, which contain trace fields (as does the Return-Path: header), are useful to system administrators for tracing e-mail and debugging problems. They also may be used in intelligence gathering by would-be attackers.
The Error-to: line indicates where error messages should be sent. In the absence of this line, they go to the Sender:, and absent that, the From: address.
No standard header field will ever begin with the characters “X-“, so application developers are free to use them for their own purposes. While, common nowadays, X-Sender: and X-Mailer: are not part of the standard. In fact, any header not expressly defined in the RFC, is allowed and ignored by most e-mail systems. So, we could have an e-mail message that head headers such as:
…
X-Sender:
avolio@mail.veriomail.com
X-Mailer:
QUALCOMM Windows Eudora Version 4.3.2
Date:
Thu, 23 Aug 2001 21:27:04 -0400
To:
fma@al.org
From:
Frederick M Avolio <fred@avolio.com>
Sender:
<admin@avolio.com>
In-Reply-To:
<4.3.2.7.2.20010415150149.00b08080@mail.example.com>
Favorite-Color:
Red
Cocktail:
Martini, up, olive
Favorite-Chapter-of-the-Bible:
Ephesians 1
Subject:
test
Recall, last month I recommended removing extraneous headers that might leak information, such as the mail client being used revealed in the above example.
There also are many MIME headers (RFCs 2045-2048, and a bunch of others), such as in these examples:
HELO — a start of conversation, identifying the connecting client machine.
EHLO — same as HELO, but indicates the client wants to use extensions to SMTP (ESMTP), if supported.
RCPT — There can be many of these related to the transfer of a single message. This line specifies the recipients, and this also is envelope information.
DATA — indicates I am ready to send the message, header lines, body, attachments, and all.
RSET — abort the current e-mail transaction (reset), but stay connected for more to come.
NOOP — a “no op,” as in “no operation.” Do nothing, but return an “OK” response.
QUIT — terminate the connection.
So far, there is nothing here we would want to worry about, from a firewall viewpoint. But, remember from last month, there are more. In the original RFC two other commands were defined:
Firebox does not respond with useful (again, useful to an attacker) information to either, which is correct from a security standpoint.
With ESMTP, there are other commands that have been added, some dangerous, most benign:
8BITMIME — Originally, SMTP only supported the transmission of ASCII data. This is useful for anyone wanting to use non-ASCII characters in e-mail message bodies.
ATRN — This is used to force an SMTP delivery of queued up mail, with the client triggering the delivery. (Also see ETRN.) This is useful for small offices with dial-up connections that need to force domain-wide delivery. It should only be used in conjunction with authentication.
AUTH — Many ISPs now use this to authenticate a client connection before allowing the relay of e-mail (as a means of spam control). AUTH may be used before setting up an encrypted tunnel for e-mail exchange.
BINARYMIME — With the MIME extensions to the Internet messaging, previously unsupported data types (non-ASCII) are now supported by Internet mail. One result of this is that the Internet is carrying larger messages (for example, word processing documents, images of all types, etc.). SMTP, created to support ASCII messages, requires e-mail to be sent, using some kind of ASCII-armoring (base64 encoding, for example), that creates overhead. This provides a way for systems to negotiate sending binary data (and will use the BDAT command, in place of the DATA command). BINARYMIME uses the CHUNKING command as well.
CHECKPOINT — if an e-mail connection is unreliable, lots of resources may be consumed with starting to transfer a large message, transferring most of it when a connection drops, and starting over from the start in trying to transmit the same large message again. This mechanism allows for the transfer to set checkpoints allowing a broken connection to pick up in mid-message when the connection is reestablished.
CHUNKING — used with BINARYMIME, above.
DSN — RFC821 requires that an SMTP server provide notification of delivery failures. Such notification usually is in the form of an ordinary Internet mail message sent to the envelope sender address. The DSN mechanism is a proposed standard to expand the utility and options for e-mail notifications. The proposed standard uses two optional parameters added to the RCPT command (NOTIFY and ORCPT) and an additional parameter for the MAIL command (RET).
ENHANCEDSTATUSCODES — Just as the name implies, but perhaps broken from a security standpoint. Quoting from RFC 2034, “It is conceivable that additional information of this sort may be of assistance in circumventing server security. The advantages of provides (sic) additional information must always be weighed against the security implications of doing so.”
ETRN — similar to ATRN, but for hosts with static IP addresses.
PIPELINING — an extension for the server to indicate its ability to accept multiple SMTP commands in a single TCP send operation.
RELAY — see ATRN.
SIZE — used on the MAIL line to indicate the size of the message the client wants to send to make sure it is not too big to be accepted.
STARTTLS — a mechanism for using TLS (a standardization and extension of SSL) for e-mail transmission between a client and a server to add confidentiality and authentication to the service.
So, as I said, the Firebox also makes security decisions based on SMTP and ESMTP. You’ll see many ESMTP commands discarded. Some are discarded because an attacker might use them, including ENHANCEDSTATUSCODES, EXPN, and VRFY. Some are discarded because they are not standard (ONEX and VERB) or not in common enough use to support (AUTH, STARTTLS, and many others).
As I said starting out, this is mostly for your education. I told you how to set-up the SMTP proxy last month. This explains the details of what some of these headers and commands mean when you see them in messages, and especially when you see them in the Firebox logs. As you know from last month, the SMTP Proxy allows you to control most all of these headers and commands, and can be set to log its actions on all of them. “And,” as Paul Harvey says, “now you know the rest of the story.”
All the RFCs mentioned are available at http://www.rfc-editor.org/
The self-proclaimed (isn’t the Internet wonderful) “MIME Information Page” is at http://hunnysoft.com/mime/.
Fred is co-author of Sendmail: Theory and Practice, published by Butterworth-Heinemann, ISBN: 1555581277.