 | This articlerelies excessively onreferences toprimary sources. Please improve this article by addingsecondary or tertiary sources. Find sources: "Sender ID" – news ·newspapers ·books ·scholar ·JSTOR(May 2024) (Learn how and when to remove this message) |
Sender ID is an historic[1] anti-spoofing proposal from the formerMARIDIETF working group that tried to joinSender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406,[2] but there are additional parts in RFC 4405,[3] RFC 4407[4] and RFC 4408.[5]
Sender ID is heavily based onSPF, with only a few additions.
Sender ID tries to improve on SPF: SPF does not verify theheader addresses (of which there can be more than one) that indicate the claimed sending party. One of these header addresses is typically displayed to the user and may be used to reply to emails. These 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[4] 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 thatv=spf1 is replaced with one of:
spf2.0/mfrom – meaning to verify the envelope sender address just like SPF.spf2.0/mfrom,pra orspf2.0/pra,mfrom – meaning to verify both the envelope sender and the PRA.spf2.0/pra – meaning to verify only the PRA.The only other syntactical difference is that Sender ID offers the feature ofpositional modifiers not supported in SPF. In practice, so far nopositional modifier has been specified in any Sender ID implementation.
In practice, thepra scheme usually only offers protection when the email is legitimate, while offering no real protection in the case of spam or phishing. Thepra 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, thepra 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 thepra for Sender ID, or the Return-Path: header field for SPF.
Thepra tries to counter the problem ofphishing, while SPF ormfrom tries to counter the problem of spam bounces and other auto-replies to forged Return-Paths. Two different problems with two different proposed solutions. However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.[6]
Thepra has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. by inserting aSender orResent-Sender. The latter violates RFC 2822[7] and can be incompatible with RFC 822.[8]
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. This concept is not new: with the original RFC 821[9] SMTP forwarders always added their host name to the reverse path in the MAIL FROM.
The most problematic point[according to whom?] in the core Sender ID specification is its recommendation to interpretv=spf1 policies likespf2.0/mfrom,pra instead ofspf2.0/mfrom. This was never intended by all published SPF drafts since 2003, and for an unknown large number ofv=spf1 policies an evaluation forpra could cause bogus results for many cases wherepra andmfrom are different. This problem was the basis of an appeal to theInternet Architecture Board (IAB). In response to another prior appeal theIESG already noted that Sender ID cannot advance on theIETF standards track without addressing the incompatibility with a MUST in RFC 2822.[7]
Various surveys performed in 2012, when SPF turned from experimental to proposed standard, showed that fewer than 3% of mail domains published specific requests for using thepra, compared to some 40~50% of mail domains using SPF.[6]
The Sender ID proposal was the subject of controversy regardinglicensing issues:Microsoft holdspatents[10][11] on key parts of Sender ID and used to license those patents under terms that were not compatible with theGNU General Public License and which were considered problematic forfree softwareimplementations in general. On October 23, 2006, Microsoft placed those patents under theOpen Specification Promise, which is compatible with some free and open source licenses, but not with the most recent version of the GPL license, version 3.x.[citation needed]
v=spf1 for PRA from theSPF project (2006).