Sender ID: Difference between revisions

Latest revision as of 22:44, 3 November 2026

Template:Primary sources Sender ID is an historic^[1] 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,^[2] but there are additional parts in RFC 4405,^[3] RFC 4407^[4] and RFC 4408.^[5]

Principles of operation

Sender ID is heavily based on SPF, with only a few additions.

Sender ID tries to improve on SPF: SPF does not verify the header 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 that v=spf1 is replaced with one of:

spf2.0/mfromTemplate:Sndmeaning to verify the envelope sender address just like SPF.
spf2.0/mfrom,pra or spf2.0/pra,mfromTemplate:Sndmeaning to verify both the envelope sender and the PRA.
spf2.0/praTemplate:Sndmeaning to verify only the PRA.

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. However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.^[6]

Standardization issues

The pra has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. by inserting a Sender or Resent-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 pointTemplate:According to whom 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.^[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 the pra, compared to some 40~50% of mail domains using SPF.^[6]

Patents

The Sender ID proposal was the subject of controversy regarding licensing issues: Microsoft holds patents^[10]^[11] 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 some free and open source licenses, but not with the most recent version of the GPL license, version 3.x.

References

External links

ASF Position Regarding Sender ID statement from the Apache Software Foundation
IAB appeal Template:Webarchive about Sender ID's reuse of v=spf1 for PRA from the SPF project (2006).
Debian project unable to deploy Sender ID statement by the Debian project
IETF Decides on SPF / Sender-ID issue coverage and discussion on slashdot
Template:Usurped coverage and discussion on groklaw
MARID Co-Chairs Clarify Consensus Statement
MARID to close mailing list thread.
Sender ID: A Tale of Open Standards and Corporate Greed?
"SPF: SPF vs Sender ID" Template:Webarchive
"Sender Id Types in Different Countries"
"Sender Id"
Sender IDs, SMS templates

[1] Alexey Melnikov (7 February 2020). "Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic". https://datatracker.ietf.org/doc/status-change-change-sender-id-to-historic/.

[2] Template:Cite IETF

[3] Template:Cite IETF

[:0-4] 4.0 ^4.1 Template:Cite IETF

[5] Template:Cite IETF

[rfc6686-6] 6.0 ^6.1 Template:Cite IETF

[rfc2822-7] 7.0 ^7.1 Template:Cite IETF

[8] Template:Cite IETF

[9] Template:Cite IETF

[10] Template:Cite mailing list

[11] "Exposed Sender ID Patents up Debate". 20 September 2004. http://www.internetnews.com/dev-news/article.php/3409971/Exposed+Sender+ID+Patents+Up+Debate.htm.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

@@ Line 1: / Line 1: @@
-{{Short description|Failed anti-spoofing proposal}}
+{{Primary sources |date=May 2024}}
-'''Sender ID''' is an historic<ref>{{cite web| url=https://datatracker.ietf.org/doc/status-change-change-sender-id-to-historic/| title=Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic| author=Alexey Melnikov| date=7 February 2020| website=[[Internet Engineering Task Force|IETF]]}}</ref> anti-[[E-mail spoofing|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 <nowiki>RFC 4406</nowiki>,<ref>{{Cite web|last1=Wong|first1=Meng Weng|last2=Lyon|first2=Jim|title=Sender ID: Authenticating E-Mail|url=https://tools.ietf.org/html/rfc4406.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref> but there are additional parts in <nowiki>RFC 4405</nowiki>,<ref>{{Cite web|last1=Katz|first1=Harry|last2=Allman|first2=Eric|title=SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message|url=https://tools.ietf.org/html/rfc4405.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref> <nowiki>RFC 4407</nowiki><ref name=":0">{{Cite web|last=Lyon <jimlyon@microsoft.com>|first=Jim|title=Purported Responsible Address in E-Mail Messages|url=https://tools.ietf.org/html/rfc4407.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref> and <nowiki>RFC 4408</nowiki>.<ref>{{Cite web|last1=Schlitt|first1=Wayne|last2=Wong|first2=Meng Weng|title=Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1|url=https://tools.ietf.org/html/rfc4408.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref>
+'''Sender ID''' is an historic<ref>{{cite web| url=https://datatracker.ietf.org/doc/status-change-change-sender-id-to-historic/| title=Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic| author=Alexey Melnikov| date=7 February 2020| website=[[Internet Engineering Task Force|IETF]]}}</ref> anti-[[E-mail spoofing|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 <nowiki>RFC 4406</nowiki>,<ref>{{Cite IETF|last1=Wong|first1=Meng Weng|last2=Lyon|first2=Jim|title=Sender ID: Authenticating E-Mail|RFC=4406}}</ref> but there are additional parts in <nowiki>RFC 4405</nowiki>,<ref>{{Cite IETF|last1=Katz|first1=Harry|last2=Allman|first2=Eric|title=SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message|rfc=4405}}</ref> <nowiki>RFC 4407</nowiki><ref name=":0">{{Cite IETF|last=Lyon|first=Jim|title=Purported Responsible Address in E-Mail Messages|rfc=4407}}</ref> and <nowiki>RFC 4408</nowiki>.<ref>{{Cite IETF|last1=Schlitt|first1=Wayne|last2=Wong|first2=Meng Weng|title=Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1|rfc=4408}}</ref>
 == Principles of operation ==
@@ Line 17: / Line 17: @@
 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.
+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|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. However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.<ref name=rfc6686>{{cite IETF |title=Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |rfc=6686 |author=Murray Kucherawy |year=2012 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref>
+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. However, Sender-ID and SPF yield the same result in approximately 80% of the cases, according to a billion message analysis.<ref name=rfc6686>{{cite IETF |title=Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |rfc=6686 |author=[[Murray Kucherawy]] |year=2012 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref>
 ==Standardization issues==
-The ''pra'' has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. by inserting a <code>Sender</code> or <code>Resent-Sender</code>. The latter violates <nowiki>RFC 2822</nowiki><ref>{{Cite web|last=Resnick <presnick@qualcomm.com>|first=Peter W.|title=Internet Message Format|url=https://tools.ietf.org/html/rfc2822.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref> and can be incompatible with <nowiki>RFC 822</nowiki>.<ref>{{Cite web|last=Crocker|first=D.|title=STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES|url=https://tools.ietf.org/html/rfc822.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref>
+The ''pra'' has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. by inserting a <code>Sender</code> or <code>Resent-Sender</code>. The latter violates <nowiki>RFC 2822</nowiki><ref name="rfc2822">{{Cite IETF|last=Resnick|first=Peter W.|title=Internet Message Format|rfc=2822}}</ref> and can be incompatible with <nowiki>RFC 822</nowiki>.<ref>{{Cite IETF|last=Crocker|first=D.|title=STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES|rfc=822}}</ref>
-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 <nowiki>RFC 821</nowiki><ref>{{Cite web|last=Postel|first=J.|title=Simple Mail Transfer Protocol|url=https://tools.ietf.org/html/rfc821.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref> SMTP forwarders always added their host name to the reverse path in the MAIL FROM.
+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 <nowiki>RFC 821</nowiki><ref>{{Cite IETF|last=Postel|first=J.|title=Simple Mail Transfer Protocol|rfc=821}}</ref> SMTP forwarders always added their host name to the reverse path in the MAIL FROM.
-The most problematic point{{According to whom|date=March 2021}} in the core Sender ID specification is its recommendation to interpret <code>v=spf1</code> policies like <code>spf2.0/mfrom,pra</code> instead of <code>spf2.0/mfrom</code>. This was never intended by all published SPF drafts since 2003, and for an unknown large number of <code>v=spf1</code> 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|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 <nowiki>RFC 2822</nowiki>.<ref>{{Cite web|last=Resnick <presnick@qualcomm.com>|first=Peter W.|title=Internet Message Format|url=https://tools.ietf.org/html/rfc2822.html|access-date=2021-03-11|website=tools.ietf.org|language=en}}</ref>
+The most problematic point{{According to whom|date=March 2021}} in the core Sender ID specification is its recommendation to interpret <code>v=spf1</code> policies like <code>spf2.0/mfrom,pra</code> instead of <code>spf2.0/mfrom</code>. This was never intended by all published SPF drafts since 2003, and for an unknown large number of <code>v=spf1</code> 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|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 <nowiki>RFC 2822</nowiki>.<ref name="rfc2822" />
 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 the ''pra'', compared to some 40~50% of mail domains using SPF.<ref name=rfc6686/>
@@ Line 32: / Line 32: @@
 == Patents ==
-The Sender ID proposal was the subject of controversy regarding [[licensing]] issues: [[Microsoft]] holds [[patent]]s<ref>{{cite web |url=http://www.imc.org/ietf-mxcomp/mail-archive/msg04844.html |title=Archived copy |accessdate=2011-12-20 |url-status=dead |archiveurl=https://web.archive.org/web/20120414184741/http://www.imc.org/ietf-mxcomp/mail-archive/msg04844.html |archivedate=2012-04-14 }}</ref><ref>{{Cite web|url=http://www.internetnews.com/dev-news/article.php/3409971/Exposed+Sender+ID+Patents+Up+Debate.htm|title=Exposed Sender ID Patents up Debate|date=20 September 2004}}</ref> 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]] [[implementation]]s in general. On October 23, 2006, Microsoft placed those patents under the [[Open 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|date=March 2021}}
+The Sender ID proposal was the subject of controversy regarding [[licensing]] issues: [[Microsoft]] holds [[patent]]s<ref>{{cite mailing list |url=http://www.imc.org/ietf-mxcomp/mail-archive/msg04844.html |title=FW: Microsoft's Updated Statement about IPR Claimed in <draft-ietf-marid-core-03.txt> and <draft-ietf-marid-pra-00.txt> in Combination |mailing-list=IETF MARID List |access-date=2011-12-20 |url-status=dead |archive-url=https://web.archive.org/web/20120414184741/http://www.imc.org/ietf-mxcomp/mail-archive/msg04844.html |archive-date=2012-04-14 }}</ref><ref>{{Cite web|url=http://www.internetnews.com/dev-news/article.php/3409971/Exposed+Sender+ID+Patents+Up+Debate.htm|title=Exposed Sender ID Patents up Debate|date=20 September 2004}}</ref> 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]] [[implementation]]s in general. On October 23, 2006, Microsoft placed those patents under the [[Open 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|date=March 2021}}
 ==See also==
@@ Line 46: / Line 46: @@
 ==External links==
 * [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 <code>v=spf1</code> for PRA from the [https://web.archive.org/web/20060702025443/http://new.openspf.org/ SPF project] (2006).
+* [http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html IAB appeal] {{Webarchive|url=https://web.archive.org/web/20110530023347/http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html |date=2011-05-30 }} about Sender ID's reuse of <code>v=spf1</code> for PRA from the [https://web.archive.org/web/20060702025443/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]]
+* {{usurped|1=[https://web.archive.org/web/20100505084303/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]
 * [https://web.archive.org/web/20040929020641/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.openspf.org/SPF_vs_Sender_ID "SPF: SPF vs Sender ID"]
+* [http://www.openspf.org/SPF_vs_Sender_ID "SPF: SPF vs Sender ID"] {{Webarchive|url=https://web.archive.org/web/20071102120517/http://www.openspf.org/SPF_vs_Sender_ID |date=2007-11-02 }}
 * [https://help.msg91.com/article/53-sender-id-in-various-countries "Sender Id Types in Different Countries"]
 * [http://www.mysmsmart.com/ "Sender Id"]
+* [https://nrt.co.in/bulk-sms/ Sender IDs, SMS templates]
 [[Category:Email authentication]]
-[[Category:Spam filtering]]
+[[Category:Anti-spam]]
 [[Category:Microsoft initiatives]]

Waza (talk | contribs)