Some Notes on Headers
Headers are name-value pairs, separated by a colon (:). Header names are case insensitive, but some of their values are case sensitive. Within email addresses particularly, the local part of the email address must generally preserve case. An exception to this is the special address of “Postmaster,” which must be legal in any combination of case. See Chapter 9 for more information on the Postmaster address.
Note
Be aware that there is no agreed definition of how a horizontal tab character should work. Some systems treat a tab as a number of spaces, others as a special character, etc. For this reason, tabs should never be used in mail headers. Similarly, since one cannot tell in advance how tabs will appear in mail-reading software, they should be used with caution elsewhere in mail messages.
Long headers
Headers are normally represented as a header name (e.g., To), followed by a colon (:), followed by the value, or body. In some cases, such as for the Comments Received headers that might be very long, the header values can be “folded” onto multiple lines.
A long header value can be sent by an MUA (or by speaking SMTP directly to an MTA) in one of two ways: a single long line of ASCII characters can be sent, or the line can be folded. If a Single long line is sent, it should probably not exceed 256 characters. If the long line is folded, the number of characters per line should probably not exceed 72.
A long line is folded by breaking the line into smaller lines, each of which is separated by a carriage return-linefeed (CRLF) combination followed by some amount of whitespace. Note that just a CRLF will not work, since the mail system interprets that as the beginning of a new header.
Most modern mail system elements (MUAs, MTAs, and MDAs) allow headers that are either folded or unfolded to pass through unchanged. In some older programs, however, long lines are folded in order to be properly processed. Long lines may be defined as greater than 65 characters (for very old terminal-based mail readers) or 72 characters for older MTAs. More modern MTAs have longer line limits, such as 256 bytes. In any case, the mail system element that receives a message can fold long lines in order to effect a proper delivery.
An example of a folded header looks like this:
Comment: This is an example of a really really really long
comment that is wrapped or folded by the addition of
CRLF whitespace combinations.Whitespace can consist of either ASCII space or tab characters.
When folding long lines, be careful to fold them only on existing whitespace. In other words, any particular bit of whitespace may be replaced with a CRLF and whitespace. This is another way of saying that you can’t split words. Never split an email address when folding headers, since you are guaranteed to confuse some parser somewhere.
For example, the following long line should be split around the location of the string AAAAAAAAAA,[4] so that:
Subject: Key words for this message are: long, longer, AAAAAAAAAA really long, and longest.
would become:
Subject: Key words for this message are: long, longer, AAAAAAAAAA
really long, and longest.If you are splitting a long header value with email addresses in it, split the lines after a given address and its trailing comma, like this:
CC: [email protected], [email protected], [email protected]
Order of headers
RFC 822 does not specify an order for headers to appear. The only absolute requirement is that the headers must appear before the message body and be separated by a blank line, which is defined as two carriage return-linefeed combinations (CRLFCRLF).
However, there is a recommendation that, if present, headers appear in the following order:
Return-Path
Received
Date
From
Subject
Sender
To
CC
Others
The first three in this list (and maybe others) are created by an MTA. If you are creating a message programmatically or by speaking SMTP directly, you are not responsible for these headers (see the section “Dynamic Headers,” later in this chapter). MTAs will insert these headers at the top of the message where they belong.
When you create headers, it is safer to keep them in the order shown in the preceding list, although it’s not strictly required. As with any standard, specific implementations will be different. Anything that you can do to help pass your message through the mail system is worthwhile.
Limitations on originator headers
The From, Sender, Reply-To, Resent-From, Resent-Sender, and Resent-Reply-To headers are limited in the way that they can be combined. This is done intentionally in the standard to ensure that if the headers are properly formed, the original author of the message can be determined.
This assumes programmers comply with the standard. There is no way within the Internet mail system to prohibit programmers lured by the Dark Side from creating bad MUAs or even MTAs. In fact, this is the method used by spammers to obscure their real addresses. Newer MTAs often include a means of authenticating senders from the local domain and denying the forwarding of mail in an attempt to deny resources to spammers without their own software. See Chapter 18, Anti-Spamming Techniques, for other means of reducing spam.
The From header and the Resent-From header (if present) should contain the email address of the person or program that wished the message to be sent. Note the word “wished.”
The Sender header and the Resent-Sender header (if present) should only be present if the author of the message is different from the person or program that actually sent the message. If it is present, it should reflect the person (or program) who actually sent the message on behalf of the author.
If the Sender header is used, it is the responsibility of the MUA to authenticate the author of the message. In most systems, once a user logs on, the MUA assumes the identity of the sender. This is normally adequate. When creating your own mail programs, however, remember that it is your responsibility to evaluate the user’s identity and provide it to the system.
If the sender wishes responses to the message to go to an address different from the address listed in the Sender or From headers, the Reply-To header can be used. This is often used by mailing list management software to ensure that replies to messages posted to a mailing list go back to the list instead of to the author. For example:
From: [email protected] To: [email protected] Reply-To: [email protected]
Mailing list management software should check messages carefully if this method is used to ensure that bounced messages do not recursively spam the mailing list! This check is often done by having posts to the list include only normal From and To headers and allowing the mailing list program to rewrite the headers as shown previously. Then the mailing list software mails the message to another address (such as [email protected]) to actually reach the list subscribers. This method allows for programmatic checking for bounces before a message actually gets to the list. If problems are discovered, the message can be diverted to a list administrator.
Another use for the Reply-To header is when a single individual has multiple mailboxes:
From: [email protected] To: [email protected] Reply-To: [email protected]
Consider an example in which we wanted to create a central help desk for a company. Email from multiple addresses will be sent to the help desk software and acted on by the next available person. In help desk software, the important thing is to log and track who has done what and what is left to do.
Any help desk attendant can act on a given piece of mail. Email sent by the attendant goes out under the attendant’s name (for accountability). The Reply-To header is used to ensure that any replies go back into the help desk system, instead of being sent to the attendant’s private mailbox where they could not be logged or tracked effectively.
Programs that receive email should parse messages with these rules in mind:
In order to reply to the sender, use the Reply-To header if it exists and the From header if it does not.
Never use the Sender header in an automatically generated response from a recipient.
The Sender header should be used by MTAs or MDAs to notify the author of a problem occurring in message transport or delivery. If it does not exist, the From header should be used instead.
[4] Note that this line is wrapped by the page layout, but that the reader should consider it to be unbroken when reading the example.