The Magic of Email Headers

Email amazes me. It’s an open, decentralized, and evolving means of communication that allows you to message someone on the other end of the world–-and it’s been around for fourty years. One of the amazing things about email is the depth of the specification. Email has many intricate and little-known parts, many of which are hidden in message headers.

Message headers are essential to any email communication–they describe the message, who sent it, and who it’s going to. To, From, Date, and Subject, are all headers most people are familiar with, then there’s the commonly discussed DKIM and SPF, however there are many more email headers that do much more.

Due to the nature of email, there are a number of standardized and non-standardized headers for messages that can do a ton. This post explores a few of them.

Implemented Headers

In addition to the standard headers, there are some lesser known exciting ones that can be put to great use:

• Content-Location – Defined in RFC 2110, Content-Location provides a URL where the content of the email may be found online.
• List-Unsubscribe – Defined in RFC 2369, this allows senders to specify a means to unsubscribe from their distribution list. We’ve previously written a little about what it does on our blog.

Proposed Headers

There are, however, many more proposed or inconsistently adopted headers which are particularly interesting.

• Require-Recipient-Valid-Since – Defined in IETF Draft, this header specifies the last known date the email was held by the intended recipient. This can counteract email recycling and other practices. It’s currently used by Yahoo! in ita email recycling program. For more, turn to our article on implementing the header yourself.
• Read-Receipt-To, X-Confirm-reading-to, Disposition-Notification-To – These headers were implemented by various mail clients and specs all in order to have clients send optional read receipts to emails. These receipts are delivered in the form of emails back to the sender. Most notably, Microsoft Outlook implements these headers.
• Importance, X-Priority, X-MSMail-Priority – These headers all implemented or proposed at different times aim to indicate the importance of the message to the receiver. Many email clients choose to display this with exclamation points, stars, or flags, most notably Microsoft Outlook. To find out how to implement, look toward this article.
• Sensitivity – This header proposed in RFC 2156 aims to allow the sender to describe how private the message is, by defining if it is personal, private, or company confidential.
• Supersedes, Obsoletes, Replaces – These headers all implemented or discussed at various points, provide a mechanism for emails to replace a prior message.
• X-Hashcash – This header is a proof of work algorithm to prevent spam. It operates on the premise that spammers need to send a lot of email to turn a profit and therefore cannot afford to take up to a second per email, which this algorithm forces. It is notable as this basic algorithm is used in mining Bitcoins. It’s been implemented in Apache’s Spam Assasin.

These are just a few of the many headers for email. To investigate more, take a look at this memo. It’s worth noting further that simply because headers are proposed does not mean they are useful, they can only become useful through adoption, which is driven both by senders and receivers.

SendGrid uses X- custom headers for the SMTP API. Elmer shows how to use custom fields in SMTP headers in his post about SendGrid-specific magic.