Sender ID

From Wikipedia, the free encyclopedia

Sender ID was an anti-spam proposal from the former MARID IETF working group that joined Sender Policy Framework (SPF) and Caller ID.

The Sender ID proposal had become 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 supposed to be compatible with free and open source licenses.

Contents

[edit] Principles of Operation

SenderID is heavily based on SPF, with only a few additions. This article will mostly discuss just these differences, and assume you already understand SPF.

Syntactically SPF and SenderID are almost identical: Replacing the string v=spf1 in a valid SPF policy by one of...

  1. spf2.0/mfrom
  2. spf2.0/mfrom,pra
  3. spf2.0/pra,mfrom
  4. spf2.0/pra

...yields a syntactically valid SenderID policy, and vice versa. The evaluation of SPF and SenderID policies follows the same general rules. The core SenderID specification has a normative reference to the SPF specification and thereby inherits exactly the same error handling, the same processing limits, and the same syntax details as SPF.

Semantically there are only two differences: SenderID offers the feature of positional modifiers not supported in SPF. In practice so far no positional modifier was specified, let alone supported in any SenderID implementation.

Except for this detail spf2.0/mfrom is semantically the same as SPF, mfrom stands for MAIL FROM, the checked identity in SPF. Because SPF is more widely deployed than the later proposed spf2.0/mfrom publishers of sender policies wishing to protect their address in MAIL FROM Return-Paths generally prefer the classic v=spf1 format.

Both spf2.0/mfrom,pra and spf2.0/pra,mfrom have the same meaning, they introduce a policy that can be used to check the mfrom as well as the pra identity.

Last but not least spf2.0/pra introduces policies checked only with the pra identity. At this time it is not specified how SPF's %{h} macro for the HELO identity should be handled in pra checks, SenderID implementations could handle it as syntax error.

The Purported Responsible Address or pra is determined by a tricky evaluation of the four mail header fields...

  • From
  • Sender
  • Resent-From
  • Resent-Sender

...finally resulting either in one address, the pra, or an error for illegal combinations as explained in RFC 2822. Simplified the rules are Sender beats From and Resent-* beats Sender. Note that it's illegal to have more than one From-address without a single Sender-address.

This pra scheme has the theoretical advantage of dealing with addresses in header fields that are often displayed by MUAs (Mail User Agents), unlike SPF's Return-Path header field or mfrom in SenderID terminology.

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 will need to be modified to display either the pra for SenderID, 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.

[edit] Standardization issues

Unfortunately pra has the severe 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, and forwarders wishing to support SPF only need to modify the SMTP MAIL FROM in addition to the 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 SenderID 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 technical problem — in fact only four characters ,pra in the core SenderID specification — was the base of an appeal to the Internet Architecture Board (IAB). In response to another prior appeal the IESG already noted that SenderID cannot advance on the IETF standards track without addressing the incompatibility with a MUST in RFC 2822.

[edit] See also

[edit] External links

In other languages