Sender ID

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.

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 SPFpolicy by one of...
# spf2.0/mfrom
# spf2.0/mfrom,pra
# spf2.0/pra,mfrom
# spf2.0/pra...yields a syntactically valid Sender ID policy, andvice versa. The evaluation of SPF and Sender ID policiesfollows the same general rules. The core Sender IDspecification has a normative reference to the SPFspecification and thereby inherits exactly the same errorhandling, the same processing limits, and the same syntaxdetails as SPF.

Semantically, there are only two differences: Sender ID offersthe 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 semanticallythe same as SPF: "mfrom" stands for MAIL FROM, the checkedidentity in SPF. Because SPF is more widely deployed than the laterproposed spf2.0/mfrom, publishers of sender policieswishing to protect their address in MAIL FROM Return-Pathsgenerally prefer the classic v=spf1 format.

Both spf2.0/mfrom,pra and spf2.0/pra,mfromhave the same meaning, they introduce a policy that can beused to check the "mfrom" as well as the "pra" identity.

Last but not least, spf2.0/pra introduces policieschecked only with the "pra" identity. At this time it isnot specified how SPF's %{h} macrofor 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 determinedby a tricky evaluation of the four mail header fields...
* From
* Sender
* Resent-From
* Resent-Sender...finally resulting either in one address—the "pra"—oran error for illegal combinations as explained in RFC 2822.Simplified, the rules are: Sender beats Fromand Resent-* beats Sender. Note that it'sillegal to have more than one From-address without asingle Sender-address.

This "pra" scheme has the theoretical advantage of dealing with addressesin 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 spambounces and other auto-replies to forged Return-Paths. Twodifferent problems with two different proposed solutions.

tandardization issues

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

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

The most problematic point in the core Sender ID specificationis its recommendation to interpret v=spf1 policies likespf2.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 anevaluation for "pra" could cause bogus results for many caseswhere "pra" and "mfrom" are different.

This technical problem — in fact only four characters ,prain the core Sender ID specification — was the base of an appeal tothe Internet Architecture Board (IAB).In response to another prior appeal the IESG already noted thatSender ID cannot advance on the IETF standards track withoutaddressing 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 Fact|date=April 2008 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.

ee also

*
* E-mail authentication overview
* MARID (IETF WG in 2004)
* DomainKeys

External links

* [http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx "Sender ID Framework"] Microsoft Corporation
* http://www.microsoft.com/senderid " SIDF resources and tools including SPF wizard.
* [http://www.apache.org/foundation/docs/sender-id-position.html "ASF Position Regarding Sender ID"] statement from the Apache Software Foundation
* [http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html IAB appeal] about Sender ID's reuse of v=spf1 for PRA from the [http://new.openspf.org/ SPF project] (2006).
* [http://www.debian.org/News/2004/20040904 "Debian project unable to deploy Sender ID"] statement by the Debian project
* [http://slashdot.org/article.pl?sid=04/09/13/1317238 "IETF Decides on SPF / Sender-ID issue"] coverage and discussion on slashdot
* [http://www.groklaw.net/article.php?story=20040908180737547 "Is Sender ID Dead in the Water? - No MARID Working Group Consensus"] coverage and discussion on groklaw
* [http://www.moongroup.com/index.php?option=content&task=view&id=26&Itemid=2 MARID Co-Chairs Clarify Consensus Statement]
* [http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html "MARID to close"] mailing list thread.
* [http://www.circleid.com/posts/sender_id_a_tale_of_open_standards_and_corporate_greed_part_i/ Sender ID: A Tale of Open Standards and Corporate Greed?]
* [http://www.silicon.com/research/specialreports/thespamreport/0,39025001,39131378,00.htm "Use Sender ID or we'll junk you, says Microsoft"] Hotmail and MSN to 'Junk' mail without Sender ID