Sender Policy Framework

The World of E-mail Authentication

There are other e-mail authentication protocols besides SPF. They differ in which addresses (identities) they authenticate and how they do it. In order to understand how the various protocols relate to each other, you need to understand the various parts of which e-mail messages are made. As the figure shows, a message has an envelope (representing the SMTP transaction, see RFC 5321), a header (see RFC 5322), and a body (which contains the actual text of the message and any attachments).

Sender Authentication Protocols

Sender authentication protocols are designed to protect against forgery of e-mail sender identities, either in the envelope or in the header.

In the envelope, first there is the "HELO" identity, which names the mail server (MTA) that is sending the message. The "MAIL FROM" identity is the e-mail address that is responsible for sending the message and where delivery errors (bounces) will eventually be reported. And the "RCPT TO" identity is the message's recipient address. The envelope identities are used during the transport of the message and are, in general, discarded upon delivery (however the MAIL FROM is usually retained in the message header as Return-Path and can be displayed in mail clients by selecting the "Show all headers" option). The typical symptom of forged envelope sender identities are misdirected bounces.

The header contains another set of identities (besides other meta information about the message, such as the subject and the sending date). The "From" identity denotes the address of the message's author. The "Sender" identity is listed explicitly only if the author is not the actual sender of the message. The "To" identity is again the recipient address. (Other, less important identities may occur in the header, see RFC 2822.) The header identities are irrelevant for message delivery and are solely meant for the use by the message's recipient – they are what is displayed by mail clients. When the header sender address is forged, the recipient's mail client will display a misleading sender address and the recipient will thus be deceived about the message's real origin.

Sender Policy Framework (SPF)

SPF authenticates the envelope HELO and MAIL FROM identities by comparing the sending mail server's IP address to the list of authorized sending IP addresses published by the sender domain's owner in a "v=spf1" DNS record. SPF has succeeded several older envelope sender authentication protocols. Currently SPF is the only widely deployed envelope authentication protocol. For more info about this see the Statistics and Research pages.

Envelope sender authentication protocols like SPF are typically used early during the SMTP transaction, before the bulk of the message (its header and body) is transmitted. All of the following protocols require that an entire message be received before it can be rejected, due to the rules of the SMTP protocol. As a result, SPF continues to be an essential front-line defense against sender address forgery when deploying protection for the header fields and body. By rejecting envelope forgeries early, not only network traffic can be saved but also computing power for further protection measures, thus making the entire process more efficient.

One of the anticipated features of a future version of SPF is a way for domains to publish that they — or even just specific e-mail addresses of theirs — always use some content authentication protocol (see below) like DKIM, S/MIME, or PGP. This will allow receivers to automatically discard unsigned messages from such domains or addresses.

Sender ID

Sender ID (RFC 4406) is a Microsoft protocol derived from SPF that authenticates one of the header addresses. Which one it authenticates is selected according to an algorithm called PRA (Purported Responsible Address, see RFC 4407). The algorithm aims to select the header field with the e-mail address "responsible" for the message.

Although Sender ID uses DNS records with a nearly identical syntax to SPF, and even uses the letters "SPF" in its version string ("spf2.0/pra"), it is not the same protocol because it authenticates the PRA header identity, whereas SPF authenticates the envelope MAIL FROM identity. Sender ID is compatible with SPF as long as there is no confusion as to which DNS records refer to which protocol. Unfortunately, RFC 4406 recommends using SPF's v=spf1 records for PRA checks as well as MAIL FROM checks. See SPF vs Sender ID for a detailed explanation on the confusion over SPF and Sender ID.

Today it is little used. Even Microsoft has migrated away from using Sender ID.

Author Domain Signing Practices (ADSP)

ADSP was a protocol created by the IETF DKIM WG, see below. Roughly it allows to state that all mails with a given domain in an author address, i.e. the RFC 2822 From, are signed using DKIM, and additionally that other mails are discardable. The signing practices of say domain example.com are published in a DNS TXT record for _adsp._domainkey.example.com.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC is an attempt to address the shortfalls of ADSP and develop a higher level policy protocol that would be more broadly deployable.

In addition to leveraging DKIM results, it uses SPF results to help determine if a mail is from an authorized source. It combines the SPF/DKIM results with an identity alignement test (which requires the Mail From domain for SPF and the signing domain for DKIM to be the same as the body From domain) to impose restrictions related to the From domain. If either SPF or DKIM pass/verify and are aligned, a message is DMARC authorized.

DMARC also adds both aggregated and per message feedback reporting to enable senders to assess the effectiveness of their ongoing email authentication operations.

For more related solutions see the E-mail authentication category on Wikipedia.

Content Authentication Protocols

Content (or payload) authentication protocols do not care about who is the sender of a message but only about who is its author. They authenticate the author of the message content (body) through asymmetric cryptographic methods. The cryptographic processing is CPU intensive, and, like sender authentication protocols that work on header identities, requires the entire message to be received before its validity can be decided and action can be taken.

DomainKeys Identified Mail (DKIM)

DKIM (see RFC 4871) provides a cryptographic signature of multiple RFC 2822 header fields and the body of a message. A domain protected by DKIM publishes in a DNS record the public key ("domain key") corresponding to its self-generated private signing key. Receivers can then use that key to verify the authenticity of the message header and body with regard to the header sender identity. However some have found the message body signing method of the current DKIM draft too unstable for practical use, so it remains to be seen whether future revisions of DKIM resolve that deficiency.

The concept of DKIM is a hybrid of sender authentication and content authentication as it strictly ties the authenticity of the message content to the message's alleged sender identity. I.e. in order for a message to be regarded as valid, it is not enough that its signature can be successfully verified but the sender domain in the message header must also match that of the signing key. Additionally, DKIM will have ADSP, see above. In these regards, DKIM differs from the following other protocols.

Secure MIME (S/MIME)

S/MIME signs and optionally encrypts the message body. (A message header can be signed/encrypted only if it is part of a MIME body part; the outer header cannot be protected.) It is supported by most mainstream mail clients and relies on public key certificates to identify the sender, using the same X.509 public key infrastructure (PKI) that SSL (Secure Socket Layer) uses (e.g. in HTTPS). End users obtain a certificate from a certificate authority (CA). E-mail certificates from commercial CAs are much cheaper than server certificates — typically around 10 USD per year. The cryptographic signature assures the receiver that only someone possessing the private signing certificate could have authored the message content.

The significance of that assurance is dependent on the policy of the Certificate Authority that provided the certificate. These vary widely.

Pretty Good Privacy (PGP) / OpenPGP

PGP is a standard for signing/encrypting text or arbitrary blocks of data. In its original, plain form PGP has been used for a long time (and to a degree is still being used) on the message text in single-part (non-MIME) messages. It can be used even with mail clients that do not support signing/encryption themselves. PGP has been standardized by the IETF under the name OpenPGP as RFC 4880.

PGP/MIME (RFC 3156) is a modern adaptation of OpenPGP to multi-part MIME messages similar to S/MIME. The main difference between PGP/MIME and S/MIME is PGP's anarchical public key web of trust, which does not rely on central root CAs as the X.509 PKI used by S/MIME does. Thus senders do not have to pay CAs to get certified, but this also means that receivers cannot verify a sender's real identity just by looking at the public key – they have to explicitly trust the key. (That kind of trust between senders and recipients is usually established through meeting in person and verifying the public key's identity.)

Summary (edit)

In an article for the Jericho Forum Outlook published by Network World (2008-01-15) Pauls Simmonds asks ten questions about E-mail and its security discontents: