RFC 6686

Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments

📅 published July 2012, from ietf

📜 RFC 6686: The Tea on SPF vs Sender ID 💅

okay bestie, so this is RFC 6686, titled "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments" ✨. It was written by M. Kucherawy from Cloudmark and published in July 2012 as an Informational doc, so it's sharing findings, not setting a standard 🎀. It has ISSN 2070-1721 🦋. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 🌸.

Abstract 🌈

okay so back in 2006 the IETF dropped a whole suite of email authentication docs: SPF and Sender ID 📬. Both let you publish a policy in DNS saying which mail servers are allowed to send email for a domain 💌. The worry was that these two would clash in some real-world situations and mess up delivery 😬.

The IESG said all of these docs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) had to be published as Experimental RFCs. They also asked the community to watch how things were deployed and run for two years from publication, so everyone could figure out a good path forward 🔍.

Fast forward six years, and there's now enough experience and evidence that the experiments can be called concluded 🎉. This document is the receipts 🧾✨.

Status of This Memo 🧁

This doc is not an Internet Standards Track spec. It's published just for info 💖.

It's an IETF product 💜. It reflects IETF community consensus, got public review, and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 for the deets 🧐.

For the current status, errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6686 🔗.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🛡️.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read them, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 📜💅.

Table of Contents 🗂️

1. Introduction ....................................................2
2. Definitions .....................................................3
3. Evidence of Deployment ..........................................3
   3.1. DNS Resource Record Types ..................................3
   3.2. Implementations ............................................5
   3.3. The SUBMITTER SMTP Extension ...............................6
4. Evidence of Differences .........................................7
5. Analysis ........................................................7
6. Conclusions .....................................................8
7. Security Considerations .........................................9
8. References ......................................................9
   8.1. Normative References .......................................9
   8.2. Informative References .....................................9
Appendix A. Background on the RRTYPE Issue ........................10
Appendix B. Acknowledgments .......................................11

1. Introduction ✨

okay so in April 2006 the IETF published the [SPF] protocol and the Sender ID protocol 📮. Sender ID is made of three docs: [SUBMITTER], [SENDER-ID], and [PRA] 🧩. Both protocols let you publish, through the Domain Name System, a policy that says which mail servers can send email on behalf of the domain you picked 💌.

So the consensus didn't clearly favour one protocol over the other 🤷‍♀️. There was a lot of worry that they'd collide in some important operational situations and interfere with message delivery 😭. The IESG made all of these docs Experimental and asked the community to watch deployment and operation for two years after publication, so they could decide what to do next 🔍.

Following the IESG's request to evaluate after a while, this document wraps up the experiments. It shares evidence about both deployment and the comparative effects of the two protocols, then ends with conclusions based on the data 📊🎀.

It's really important to know this doc does not do a direct technical comparison of the two protocols on correctness, weaknesses, or use case coverage 🙅‍♀️. The email community already did that through its deployment choices 💅. What this doc does is just observe what got deployed and supported since the protocols came out, and then draws conclusions from those observations 👀.

The data here is presumed to be a reasonably representative view of global deployment data 🌍. Obviously nobody could survey all of that within a reasonable amount of time 😅.

2. Definitions 📚

The term "RRTYPE" refers to a Domain Name System ([DNS]) Resource Record (RR) type 🧾. Software always stores these internally as numbers, assigned according to the procedures in [DNS-IANA]. Assigned RRTYPEs also have names 🏷️. The two that matter for this work are the TXT RRTYPE (16) and the SPF RRTYPE (99) 💜.

3. Evidence of Deployment 🔎

This section shares the research done to figure out which parts of the two protocol suites are actually in use, plus related stuff like [DNS] support 🧐🌸.

3.1. DNS Resource Record Types 🍓

Three big DNS surveys were run, looking for the two kinds of RRTYPEs that can hold SPF policy statements 🔍. The surveys picked large sets of distinct domain names from email headers and logs over long periods. It didn't matter whether the DNS data for those domains included A, MX, or any other RRTYPEs 🙌. The nameservers for these domains were queried for both RRTYPEs that could be used for SPF and/or Sender ID 📬.

In the tables below, a reply only counted if it had a prefix showing the record was meant to be one of the forms defined in [SPF] or [SENDER-ID]. Full syntax validation of the replies was not done 🙈. So the records had to start with either "v=spf1" or "spf2.0/", or they didn't count as replies 💅.

The tables are split into three parts: (a) the size of the sample set, (b) a report on RRTYPE use independent of content, and (c) a report on content independent of RRTYPE 🎀.

"SPF+TXT" counts the domains where both types were in use 💖.

DNS Survey #1 (Cisco)

  +------------------+-----------+-------+
  | Domains queried  | 1,000,000 |   -   |
  +------------------+-----------+-------+
  | TXT replies      |   397,511 | 39.8% |
  | SPF replies      |     6,627 | <1.0% |
  | SPF+TXT replies  |     6,603 | <1.0% |
  +------------------+-----------+-------+
  | v=spf1 replies   |   395,659 | 39.6% |
  | spf2.0/* replies |     5,291 | <1.0% |
  +------------------+-----------+-------+

The domains were the top million as reported by Alexa, which tracks browser activity 🌐✨.

DNS Survey #2 (The Trusted Domain Project)

  +------------------+-----------+-------+
  | Domains queried  |   278,353 |   -   |
  +------------------+-----------+-------+
  | TXT replies      |   156,894 | 56.4% |
  | SPF replies      |     2,876 |  1.0% |
  | SPF+TXT replies  |     2,689 | <1.0% |
  +------------------+-----------+-------+
  | v=spf1 replies   |   149,985 | 53.9% |
  | spf2.0/* replies |     7,285 |  2.7% |
  +------------------+-----------+-------+

This survey picked its domains from data seen in email headers and from earlier SPF and Sender ID evaluations 📨. The data came from 23 reporting hosts across a handful of unrelated operators, over a period of 22 months 🗓️💜.

Here's the tea from this second survey: some domains answered RRTYPE 16 queries right away, but timed out waiting on RRTYPE 99 queries 😳. For example, 4,360 distinct domains (over 1.6%) gave some kind of result (a record or an error) for the TXT query in time N, while the SPF query ultimately failed after at least time 4N 💀.

DNS Survey #3 (Hotmail)

  +------------------+-----------+-------+
  | Domains queried  |   100,000 |   -   |
  +------------------+-----------+-------+
  | TXT replies      |    46,221 | 46.2% |
  | SPF replies      |       954 | <1.0% |
  | SPF+TXT replies  |     1,383 |  1.4% |
  +------------------+-----------+-------+

Hotmail's domain set came from live email traffic at the moment the sample was pulled 📬. Only the RRTYPE part of their report is available 🙃.

There was also a separate survey of queries for RRTYPE 16 and RRTYPE 99 records, done by watching nameserver traffic logs 👀. Only a few queries for RRTYPE 99 records ever came in, and they almost all came from one big email service provider that queried for both RRTYPEs 📈. Pretty much every other querying agent only ever asked for RRTYPE 16 😌.

3.2. Implementations 🛠️

It's probably impossible to figure out from a survey which Mail Transfer Agents (MTAs) have SPF and/or Sender ID checking turned on at message ingress 🙈. It doesn't show up in the reply to the EHLO command from extended [SMTP], for example 🤷‍♀️. So instead, the authors relied on web searches, and found the following 🔍:

  • A website [SID-IMPL] dedicated to highlighting Sender ID implementations, last updated in late 2007, listed 13 commercial implementations 💼. The authors assume these implement the Purported Responsible Address (PRA) checks 🧠. At least one of them is known to no longer be supported by its vendor 🥀. There were no free open-source implementations listed 😬.
  • The [OPENSPF] website keeps a list of SPF implementations 📋. When this document was being written, it listed six libraries, 22 MTAs with built-in SPF implementations, and loads of patches for MTAs and mail clients 🧩✨. The set was a mix of commercial and free open-source implementations 🌈.

Part 1 of 3 is done, bestie 🎀. Part 2 starts with Section 3.3, so stay tuned 💖🫶

3.3. The SUBMITTER SMTP Extension ✨

okay so the PRA is basically the output of a heuristic that scans a message header and picks out the email address most likely responsible for getting that message into the mail stream 📬. The SUBMITTER extension to SMTP is a way to give the receiving MTA an early hint, as part of the MAIL command in an SMTP session, about what the PRA would turn out to be once the whole message arrives. Early hints are lowkey iconic 🔥

When the researchers reviewed a bunch of MTAs that are in use or were recently in use, two of them, Santronics WinServer and McAfee MxLogic, had implementations of the SMTP SUBMITTER extension as part of the MTA service 💅. That could help Sender ID along.

Nobody knows exactly how many SMTP clients implement the SUBMITTER SMTP extension 🤷‍♀️. The MTA logs show it's used a lot, but there's no way to tell if all that usage comes from several instances of the same SMTP client or from different client implementations.

Next, there was an active survey of MTAs you can reach over the Internet 🌐. The MTAs were found by querying the MX and A resource records of a subset of all the domains that The Trusted Domain Project's data collection system had seen in the previous 20 months. Here's how it went:

SUBMITTER Survey (The Trusted Domain Project)

  +-------------------+-----------+-------+
  | MTAs selected     |   484,980 |   -   |
  | MTAs responding   |   371,779 | 76.7% |
  | SUBMITTER enabled |    17,425 |  4.7% |
  | MXLogic banner    |    16,914 |  4.6% |
  +-------------------+-----------+-------+
Heads up, bestie: the bottom two rows are percentages of the responding MTAs that have the stated property, NOT percentages of the selected MTAs 🙈

Going by the SMTP banner shown on connection, the whole set of SUBMITTER-enabled MTAs was made up of the two from the review above plus a third one whose identity couldn't be positively determined 🕵️‍♀️.

Out of those few responding MTAs that advertised the SUBMITTER SMTP extension, 97% were different instances of one MTA. The service running that MTA (MXLogic, a division of McAfee) said that about 11% of all the SMTP sessions it observed involved SMTP clients that use the SUBMITTER extension. Just to be clear, that's about 11% of the clients of the 4.6% of responding MTAs in the survey. Tiny slice, very dramatic 💀

4. Evidence of Differences 🦋

separate surveys from Hotmail and The Trusted Domain Project compared the cases where the PRA (which Sender ID uses) and the RFC5321.MailFrom address (which SPF uses) came out different 👀. The results showed that at least 50% of the time, the two addresses were the same. Past that point, the percentage swung a lot from one sampling location to the next, because each place gets a totally different kind of mail stream 📊.

The Trusted Domain Project also analyzed about 150,000 messages. In more than 95% of those cases, Sender ID and SPF reached the same conclusion about the message, meaning both returned a "pass" or both returned a "fail" 💖. Quick reality check though: this doesn't tell you whether a "fail" meant spam or other abusive mail was caught, or whether a "pass" means the mail is good. It's only a measure of how often the two protocols agreed. The dataset couldn't say more about the cases where the answers didn't match 🤔.

Hotmail ran a second analysis of the same kind and found the two protocols gave the same result about 80% of the time, across billions of messages 🌸.

Anecdotally, the email-receiving community hasn't noticed these differences in conclusions causing any big operational problems 🫶.

5. Analysis 🔍

It's been six years since the Experimental RFCs were published, and given that plus the evidence in the earlier sections, the following analysis looks solid 💅:

  1. There has not been substantial adoption of the RRTYPE 99 (SPF) DNS resource record. In all the large-scale surveys done for this work, fewer than 2% of responding domains published RRTYPE 99 records, and almost no clients asked for them 😭.
  2. Of the DNS resource records that were retrieved, fewer than 3% specifically asked for processing of messages using the PRA algorithm, which is a core part of Sender ID 🧚.
  3. Although the two protocols often used different email address fields as the subject being evaluated, no collected data showed any substantial operational benefit, in terms of better accuracy, from using one mechanism over the other ⚖️.
  4. A review of known implementations shows significant support for both protocols, though there were more implementations supporting SPF than Sender ID. The SPF implementations also showed better upkeep and more current interest than the Sender ID ones 🌈.
  5. A survey of running MTAs shows fewer than 5% of them advertised the SUBMITTER extension, which is a Sender ID enabler. Only three implementations of it were found 🍓.
  6. There are still obstacles to deploying protocols that use DNS RRTYPEs other than the most common ones. These include firewalls and DNS servers that block or discard requests for unknown RRTYPEs. On top of that, few if any web-based DNS configuration tools offer support for RRTYPE 99 records 🙄.

6. Conclusions 👑

Based on the analysis in the previous section, these conclusions are supported ✨:

  1. The experiments comprising the series of RFCs that define the SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism (RFC4406), the Purported Responsible Address algorithm (RFC4407), and SPF (RFC4408), should be considered concluded 🎀.
  2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it hasn't attracted enough support to be useful 🥀.
  3. Unavailability of software implementing the protocols was not a gating factor in choosing which ones to use 🛠️.
  4. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA] indicates there isn't a strong community deploying and using these protocols 😔.
  5. [SPF] has widespread implementation and deployment, comparable to that of many Standards Track protocols. Iconic behavior from SPF, honestly 💜.

Appendix A is offered as a cautionary review of the problems that affected the process of developing SPF and Sender ID in terms of their use of the DNS. Please read it, it's the tea ☕.

7. Security Considerations 🔐

This document contains information for the community, akin to an implementation report, and does not introduce any new security concerns. Phew 😌

8. References 📚

8.1. Normative References

[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.

[SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.

[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.

[SUBMITTER] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.

8.2. Informative References

[DNS-EXPAND] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.

[DNS-IANA] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.

[OPENSPF] "Sender Policy Framework: Project Overview", <http://www.openspf.net>.

[SID-IMPL] "Sender ID Framework Industry Support and Solutions", October 2007, <http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx>.

[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

Appendix A. Background on the RRTYPE Issue 🎀

okay so SPF was originally cooked up by a community of devs outside the IETF 🧚 the plan was to bring it to the IETF for standardization once it was mature and ready for the Standards process 💅

back when SPF was first being built, nobody was seriously thinking about getting an RRTYPE allocated for it 🙈 partly bc doing that had really high barriers to entry. so by the time it reached the IETF for development and publication, there was already a big, growing installed base running SPF on TXT RRs 📜 eventually, the DNS experts in the community pushed for a new RRTYPE, insisting it was the preferred path for storing policy data in the DNS. iconic of them honestly 👑

later on, after RRTYPE 99 was assigned (long after IESG approval of [SPF], fr) there was a plan to gradually move everyone from RRTYPE 16 over to RRTYPE 99 🦋 and the plan flopped, for four main reasons:

  1. people hesitated to switch bc existing nameservers (and DNS-aware firewalls, too!) would drop or reject queries for unknown RRTYPEs 💀 (see Section 3 for the evidence). so a successful rollout of a new RRTYPE depends on widespread adoption of updated nameservers and resolver functions 🫶
  2. a lot of DNS provisioning tools (like web interfaces for controlling DNS zone data) were, and still are, super lethargic about adding support for new RRTYPEs 😭
  3. the massive deployed base was already on RRTYPE 16 and it was working just fine, so there was major inertia 🌸
  4. [SPF] itself had a faulty transition plan 😬 probably bc a requirement to write one got added super late. the text says:
An SPF-compliant domain name SHOULD have SPF records of both RR types.  A compliant domain name MUST have a record of at least one type.

which means both types can claim to be fully compliant while totally failing to interoperate 💀 the document was published without proper IETF review, so nobody caught it before publication. big oops 🍓

it's likely this will happen again if the bar for creating new RRTYPEs, even for experimental development purposes, doesn't get lowered, and if handling of unknown RRTYPEs in software doesn't become more graceful 🌈 encouraging support for new RRTYPEs in DNS record provisioning tools is also important, no cap ✨

thankfully, in the meantime, the requirements for new RRTYPE assignments got less strict (see [DNS-IANA]) ⭐ and the publication of [DNS-EXPAND] gave some useful guidance too 🎀 still, there's a common perception that adding new types of data to the DNS will hit resistance because of the lack of appropriate software support 🥺

the DNS experts in the community will absolutely point at DNS servers and firewalls that mistreat queries for unknown RRTYPEs, and at overly simplistic provisioning tools, and say they're broken as a way of answering these concerns 💅 and honestly? that's undoubtedly correct 💯 but they're among us and will likely be for some time, so this needs to be considered as new protocols and IETF procedures get developed 🫶

Appendix B. Acknowledgments 💖

the following folks provided operational data that helped build the evidence above, and they are absolutely iconic 👑

  • Cisco: contributed data about observed Sender ID and SPF records in the DNS for a large number of domains (DNS survey #1) 🍓
  • Hotmail: contributed data about the difference between RFC5321.MailFrom and RFC5322.From domains across large mail volumes, and a survey of DNS replies observed in response to incoming mail traffic (DNS survey #3) 📬
  • John Levine: conducted a survey of DNS server logs to evaluate SPF-related query traffic 🧚
  • McAfee: provided details about their SUBMITTER implementation and usage statistics 🛡️
  • Santronics: contributed data about the use of the SUBMITTER extension in aggregate SMTP client traffic 🌈
  • The Trusted Domain Project: contributed data about the difference between Sender ID and SPF results, conducted one of the detailed TXT/SPF RRTYPE surveys including collecting timing data (DNS survey #2), and conducted the MTA SUBMITTER survey 🦋

the author would also like to thank the following for their contributions to the development of the text in this document: Dave Crocker, Scott Kitterman, Barry Leiba, John Leslie, John Levine, Hector Santos, and Alessandro Vesely 🫶🎀

Author's Address 📮

Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA  94107
USA

Phone: +1 415 946 3800
EMail: superuser@gmail.com
📦 where this page comes from