Sender ID

Principles of operation

Sender ID is heavily based on SPF, with only a few additions. These differences are discussed here.

Sender ID tries to improve on a principal deficiency in SPF: that SPF does not verify the header addresses that indicates the sending party. Such header addresses are typically displayed to the user and are used to reply to emails. Indeed, such header addresses can be different from the address that SPF tries to verify; that is, SPF verifies only the "MAIL FROM" address, also called the envelope sender.

However, there are many similar email header fields that all contain sending party information; therefore Sender ID defines in RFC 4407 a Purported Responsible Address (PRA) as well as a set of heuristic rules to establish this address from the many typical headers in an email.

Syntactically, Sender ID is almost identical to SPF except that v=spf1 is replaced with one of:

The only other syntactical difference is that Sender ID offers the feature of positional modifiers not supported in SPF. In practice, so far no positional modifier has been specified in any Sender ID implementation.

In practice, the pra scheme usually only offers protection when the email is legitimate, while offering no real protection in the case of spam or phishing. The pra for most legitimate email will be either the familiar From: header field, or, in the case of mailing lists, the Sender: header field. In the case of phishing or spam, however, the pra may be based on Resent-* header fields that are often not displayed to the user. To be an effective anti-phishing tool, the MUA (Mail User Agent or Mail Client) will need to be modified to display either the pra for Sender ID, or the Return-Path: header field for SPF.

The pra tries to counter the problem of phishing, while SPF or mfrom tries to counter the problem of spam bounces and other auto-replies to forged Return-Paths. Two different problems with two different proposed solutions.

Standardization issues

The pra has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. insert a Sender or Resent-Sender. The latter violates RFC 2822 and can be incompatible with RFC 822.

With SPF, mailing lists continue to work as is. Forwarders wishing to support SPF only need to modify SMTP MAIL FROM and RCPT TO, not the mail. That's no new concept; with the original RFC 821 SMTP forwarders always added their host name to the reverse path in the MAIL FROM.

The most problematic point in the core Sender ID specification is its recommendation to interpret v=spf1 policies like spf2.0/mfrom,pra instead of spf2.0/mfrom. This was never intended by all published SPF drafts since 2003, and for an unknown large number of v=spf1 policies an evaluation for pra could cause bogus results for many cases where pra and mfrom are different. This problem was the basis of an appeal to the Internet Architecture Board (IAB). In response to another prior appeal the IESG already noted that Sender ID cannot advance on the IETF standards track without addressing the incompatibility with a MUST in RFC 2822.

Intellectual property

The Sender ID proposal was the subject of controversy regarding intellectual property licensing issues: Microsoft holds patents on key parts of Sender ID and used to license those patents under terms that were not compatible with the GNU General Public License and which were considered problematic for free software implementations in general. On October 23, 2006, Microsoft placed those patents under the Open Specification Promise, which is compatible with free and open source licenses, but not with the most recent version of the GPL license, version 3.x.