Sender ID

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Sender ID is an anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but additional parts in RFC 4405, RFC 4407 and RFC 4408.

Contents

[edit] Principles of operation

Sender ID is heavily based on SPF, with only a few additions. This article will mostly discuss just these differences.

  • They both are TXT records published by the DNS servers of a domain name.
  • They both give rules that the owner of this domain name intends to respect in all headers of his genuinely sent emails.
  • They differ on what rules they apply to what fields contained in the message header.
  • They both want to be used by some mail clients and web mail servers (and some MTA servers) to distinguish good mail from junk by helping to authenticate the sender.

Syntactically, SPF and Sender ID 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 Sender ID policy, and vice versa. The evaluation of SPF and Sender ID policies follows the same general rules. The core Sender ID 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: Sender ID offers the feature of positional modifiers not supported in SPF. In practice, so far no positional modifier has been specified— let alone supported—in any Sender ID 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, Sender ID 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 Sender ID 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 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.

[edit] 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 technical problem — in fact only four characters ,pra in the core Sender ID specification — was the base 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.

[edit] Intellectual Property

The Sender ID proposal was the subject of controversy regarding intellectual property licensing issues: Microsoft holds patents[citation needed] 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.

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Sender_ID"
Personal tools