idnits 2.17.1 draft-ietf-spfbis-experiment-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 473: '... server SHOULD publish both RRTY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2012) is 4337 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 6195 (ref. 'DNS-IANA') (Obsoleted by RFC 6895) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPFBIS Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational June 12, 2012 5 Expires: December 14, 2012 7 Resolution of The SPF and Sender ID Experiments 8 draft-ietf-spfbis-experiment-11 10 Abstract 12 In 2006 the IETF published a suite of protocol documents comprising 13 SPF and Sender ID, two proposed email authentication protocols. Both 14 of these protocols enable one to publish via the Domain Name System a 15 policy declaring which mail servers were authorized to send email on 16 behalf of the domain name being queried. There was concern that the 17 two would conflict in some significant operational situations, 18 interfering with message delivery. 20 The IESG required the publication of all of these documents (RFC4405, 21 RFC4406, RFC4407, and RFC4408) with Experimental status, and 22 requested that the community observe deployment and operation of the 23 protocols over a period of two years from the date of publication to 24 determine a reasonable path forward. 26 After six years, sufficient experience and evidence have been 27 collected that the experiments thus created can be considered 28 concluded. This document presents those findings. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 14, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Evidence of Deployment . . . . . . . . . . . . . . . . . . . . 4 66 3.1. DNS Resource Record Types . . . . . . . . . . . . . . . . 4 67 3.2. Implementations . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. The SUBMITTER SMTP Extension . . . . . . . . . . . . . . . 6 69 4. Evidence of Differences . . . . . . . . . . . . . . . . . . . 7 70 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Appendix A. Background on the RRTYPE Issue . . . . . . . . . . . 10 78 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 In April 2006, the IETF published the [SPF] and Sender ID email 84 authentication protocols, the latter consisting of three documents 85 ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols 86 enable one to publish via the Domain Name System a policy declaring 87 which mail servers are authorized to send email on behalf of the 88 selected domain name. 90 Consensus did not clearly support one protocol over the other, and 91 there was significant concern that the two would conflict in some 92 significant operational situations, interfering with message 93 delivery. The IESG required the publication of all of these 94 documents as Experimental, and requested that the community observe 95 deployment and operation of the protocols over a period of two years 96 from the date of publication in order to determine a reasonable path 97 forward. 99 In line with the IESG's request to evaluate after a period of time, 100 this document concludes the experiments by presenting evidence 101 regarding both deployment and comparative effect of the two 102 protocols. At the end it presents conclusions based on the data 103 collected. 105 It is important to note that this document makes no direct technical 106 comparison of the two protocols in terms of correctness, weaknesses, 107 or use case coverage. The email community at large has already done 108 that through its deployment choices. Rather, the analysis presented 109 here merely observes what has been deployed and supported in the time 110 since the protocols were published, and draws conclusions based on 111 those observations. 113 The data collected and presented here are presumed to be a reasonable 114 representative view of the global deployment data, which could never 115 itself be fully surveyed within a reasonable period of time. 117 2. Definitions 119 The term "RRTYPE" is used to refer to a Domain Name System ([DNS]) 120 Resource Record (RR) type. These are always expressed internally in 121 software as numbers, assigned according to the procedures in 122 [DNS-IANA] Assigned RRTYPEs also have names. The two of interest in 123 this work are the TXT RRTYPE (16) and the SPF RRTYPE (99). 125 3. Evidence of Deployment 127 This section presents the collected research done to determine what 128 parts of the two protocol suites are in general use, as well as 129 related issues like [DNS] support. 131 3.1. DNS Resource Record Types 133 Three large-scale DNS surveys were run that looked for the two 134 supported kinds of RRTYPEs that can contain SPF policy statements. 135 These surveys selected substantial sets of distinct domain names from 136 email headers and logs over long periods, regardless of whether the 137 DNS data for those domains included A, MX, or any other RRTYPEs. The 138 nameservers for these domains were queried, asking for both of the 139 RRTYPEs that could be used for SPF and/or Sender ID. 141 In the tables below, replies were counted only if they included 142 prefixes that indicated the record was intended to be of a form 143 defined in either [SPF] or [SENDER-ID], though complete syntax 144 validation of the replies was not done. That is, the records either 145 started "v=spf1" or "spf2.0/", or they were not counted as replies. 147 The tables are broken down into three parts: (a) the size of the 148 sample set, (b) a report about RRTYPE use independent of content, and 149 (c) a report about content independent of RRTYPE. 151 "SPF+TXT" indicates the count of domains where both types were in 152 use. 154 DNS Survey #1 (Cisco) 156 +------------------+-----------+-------+ 157 | Domains queried | 1,000,000 | - | 158 +------------------+-----------+-------+ 159 | TXT replies | 397,511 | 39.8% | 160 | SPF replies | 6,627 | <1.0% | 161 | SPF+TXT replies | 6,603 | <1.0% | 162 +------------------+-----------+-------+ 163 | v=spf1 replies | 395,659 | 39.6% | 164 | spf2.0/* replies | 5,291 | <1.0% | 165 +------------------+-----------+-------+ 167 Domains were selected as the top million domains as reported by 168 Alexa, which monitors browser activity. 170 DNS Survey #2 (The Trusted Domain Project) 172 +------------------+-----------+-------+ 173 | Domains queried | 278,353 | - | 174 +------------------+-----------+-------+ 175 | TXT replies | 156,894 | 56.4% | 176 | SPF replies | 2,876 | 1.0% | 177 | SPF+TXT replies | 2,689 | <1.0% | 178 +------------------+-----------+-------+ 179 | v=spf1 replies | 149,985 | 53.9% | 180 | spf2.0/* replies | 7,285 | 2.7% | 181 +------------------+-----------+-------+ 183 This survey selected its domains from data observed in email headers 184 and previous SPF and Sender ID evaluations, collected from 23 185 reporting hosts across a handful of unrelated operators over a period 186 of 22 months. 188 During this second survey, some domains were observed to provide 189 immediate answers for RRTYPE 16 queries, but would time out waiting 190 for replies to RRTYPE 99 queries. For example, it was observed that 191 4,360 (over 1.6%) distinct domains in the survey returned a result of 192 some kind (a record or an error) for the TXT query in time N, while 193 the SPF query ultimately failed after at least time 4N. 195 DNS Survey #3 (Hotmail) 197 +------------------+-----------+-------+ 198 | Domains queried | 100,000 | - | 199 +------------------+-----------+-------+ 200 | TXT replies | 46,221 | 46.2% | 201 | SPF replies | 954 | <1.0% | 202 | SPF+TXT replies | 1,383 | 1.4% | 203 +------------------+-----------+-------+ 205 Hotmail's domain set was selected from live email traffic at the time 206 the sample was extracted. Only the RRTYPE portion of the report is 207 available. 209 A separate survey was done of queries for RRTYPE 16 and RRTYPE 99 210 records by observing nameserver traffic records. Only a few queries 211 were ever received for RRTYPE 99 records, and those almost 212 exclusively came from one large email service provider that queried 213 for both RRTYPEs. The vast majority of other querying agents only 214 ever requested RRTYPE 16. 216 3.2. Implementations 218 It is likely impossible to determine from a survey which Mail 219 Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at 220 message ingress since it does not appear, for example, in the reply 221 to the EHLO command from extended [SMTP]. We therefore rely on 222 evidence found via web searches, and observed the following: 224 o A web site [SID-IMPL] dedicated to highlighting Sender ID 225 implementations last updated in late 2007 listed 13 commercial 226 implementations, which we assume means they implement the 227 Purported Responsible Address (PRA) checks. At least one of them 228 is known no longer to be supported by its vendor. There were no 229 free open source implementations listed. 231 o The [OPENSPF] web site maintains a list of implementations of SPF. 232 At the time of this document's writing it listed six libraries, 22 233 MTAs with built-in SPF implementations, and numerous patches for 234 MTAs and mail clients. The set included a mix of commercial and 235 free open source implementations. 237 3.3. The SUBMITTER SMTP Extension 239 The PRA is the output of a heuristic that seeks to scan a message 240 header and extract from it the email address most likely to be the 241 one responsible for injection of that message into the mail stream. 242 The SUBMITTER extension to SMTP is a mechanism to provide an early 243 hint (i.e., as part of the MAIL command in an SMTP session) to the 244 receiving MTA of what the PRA would be on full receipt of the 245 message. 247 In a review of numerous MTAs in current or recent use, two 248 (Santronics WinServer and McAfee MxLogic) were found to contain 249 implementations of the SMTP SUBMITTER extension as part of the MTA 250 service, which could act as an enabler to Sender ID. 252 An unknown number of SMTP clients implement the SUBMITTER SMTP 253 extension. Although information from MTA logs indicates substantial 254 use of the SMTP extension, it is not possible to determine whether 255 the usage is from multiple instances of the same SMTP client or 256 different SMTP client implementations. 258 An active survey of MTAs accessible over the Internet was performed. 259 The MTAs selected were found by querying for MX and A resource 260 records of a subset of all domains observed by The Trusted Domain 261 Project's data collection system in the preceding 20 months. The 262 results were as follows: 264 SUBMITTER Survey (The Trusted Domain Project) 266 +-------------------+-----------+-------+ 267 | MTAs selected | 484,980 | - | 268 | MTAs responding | 371,779 | 76.7% | 269 | SUBMITTER enabled | 17,425 | 4.7% | 270 | MXLogic banner | 16,914 | 4.6% | 271 +-------------------+-----------+-------+ 273 Note: The bottom two rows indicate the percentage of responding MTAs 274 with the stated property, not the percentage of selected MTAs. 276 Based on the SMTP banner presented upon connection, the entire set of 277 SUBMITTER-enabled MTAs consisted of the two found during the review 278 (above) and a third whose identity could not be positively 279 determined. 281 Of those few responding MTAs advertising the SUBMITTER SMTP 282 extension, 97% were different instances of one MTA. The service 283 operating that MTA (MXLogic, a division of McAfee) reported that 284 about 11% of all observed SMTP sessions involved SMTP clients that 285 make use of the SUBMITTER extension. Note that this represents about 286 11% of the clients of 4.6% of the responding MTAs in the survey. 288 4. Evidence of Differences 290 Separate surveys from Hotmail and The Trusted Domain Project compared 291 the cases where the PRA (used by Sender ID) and the RFC5321.MailFrom 292 address (used by SPF) differed. The results of these tests showed 293 that at least 50% of the time the two addresses were the same, but 294 beyond that the percentage varied substantially from one sampling 295 location to the next due to the nature of the mail streams they each 296 receive. 298 Further, The Trusted Domain Project analyzed approximately 150,000 299 messages and found that in more than 95% of those cases, Sender ID 300 and SPF reach the same conclusion about a message, meaning either 301 both protocols return a "pass" result or both return a "fail" result. 302 Note that this does not include an evaluation of whether "fail" meant 303 spam or other abusive mail was thus detected or that "pass" mail is 304 good mail; it is merely a measure of how often the two protocols 305 concurred. The data set yielding this response could not further 306 characterize the cases in which the answers differed. 308 A second analysis of the same nature by Hotmail found that the two 309 protocols yielded the same result approximately 80% of the time when 310 evaluated across billions of messages. 312 Anecdotally, the differences in conclusions have not been noted as 313 causing significant operational problems by the email-receiving 314 community. 316 5. Analysis 318 Given the six years that have passed since the publication of the 319 Experimental RFCs, and the evidence reported in the earlier sections 320 of this document, the following analysis appears to be supported: 322 1. There has not been substantial adoption of the RRTYPE 99 (SPF) 323 DNS resource record. In all large-scale surveys performed for 324 this work, fewer than 2% of responding domains published RRTYPE 325 99 records, and almost no clients requested them. 327 2. Of the DNS resource records retrieved, fewer than 3% included 328 specific requests for processing of messages using the PRA 329 algorithm, which is an essential part of Sender ID. 331 3. Although the two protocols often used different email address 332 fields as the subject being evaluated, no data collected showed 333 any substantial operational benefit, in terms of improved 334 accuracy, to using one mechanism over the other. 336 4. A review of known implementations shows significant support for 337 both protocols, though there were more implementations in support 338 of SPF than of Sender ID. Further, the SPF implementations 339 showed better upkeep and current interest than the Sender ID 340 implemenations. 342 5. A survey of running MTAs shows fewer than 5% of them advertised 343 the SUBMITTER extension, which is a Sender ID enabler. Only 344 three implementations of it were found. 346 6. There remain obstacles to deployment of protocols that use DNS 347 RRTYPEs other than the most common ones, including firewalls and 348 DNS servers that block or discard requests for unknown RRTYPEs. 349 Further, few if any web-based DNS configuration tools offer 350 support for RRTYPE 99 records. 352 6. Conclusions 354 In light of the analysis in the previous section, the following 355 conclusions are supported: 357 1. The experiments comprising the series of RFCs defining the 358 SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism 359 (RFC4406), the Purported Responsible address algorithm (RFC4407), 360 and SPF (RFC4408), should be considered concluded. 362 2. The absence of significant adoption of the RRTYPE 99 DNS Resource 363 Record suggests that it has not attracted enough support to be 364 useful. 366 3. Unavailability of software implementing the protocols was not a 367 gating factor in terms of the selection of which to use. 369 4. The absence of significant adoption of the [SUBMITTER] extension, 370 [SENDER-ID], and [PRA], indicates that there is not a strong 371 community deploying and using these protocols. 373 5. [SPF] has widespread implementation and deployment, comparable to 374 that of many standards track protocols. 376 Appendix A is offered as a cautionary review of problems that 377 affected the process of developing SPF and Sender ID in terms of 378 their use of the DNS. 380 7. Security Considerations 382 This document contains information for the community, akin to an 383 implementation report, and does not introduce any new security 384 concerns. 386 8. IANA Considerations 388 This document presents no actions for IANA. [RFC Editor: Please 389 remove this section prior to publication.] 391 9. References 393 9.1. Normative References 395 [DNS] Mockapetris, P., "Domain names - implementation and 396 specification", STD 13, RFC 1035, November 1987. 398 [PRA] Lyon, J., "Purported Responsible Address in E-Mail 399 Messages", RFC 4407, April 2006. 401 [SENDER-ID] 402 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 403 RFC 4406, April 2006. 405 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 406 for Authorizing Use of Domains in E-Mail, Version 1", 407 RFC 4408, April 2006. 409 [SUBMITTER] 410 Allman, E. and H. Katz, "SMTP Service Extension for 411 Indicating the Responsible Submitter of an E-Mail 412 Message", RFC 4405, April 2006. 414 9.2. Informative References 416 [DNS-EXPAND] 417 Faltstrom, P., Austein, R., and P. Koch, "Design Choices 418 When Expanding the DNS", RFC 5507, April 2009. 420 [DNS-IANA] 421 Eastlake 3rd, D., "Domain Name System (DNS) IANA 422 Considerations", RFC 6195, March 2011. 424 [OPENSPF] "Sender Policy Framework: Project Overview", 425 . 427 [SID-IMPL] 428 "Sender ID Framework Industry Support and Solutions", 429 October 2007, . 432 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 433 October 2008. 435 Appendix A. Background on the RRTYPE Issue 437 SPF was originally created by a community of interested developers 438 outside the IETF, with the intent of bringing it to the IETF for 439 standardization after it had become relatively mature and ready for 440 the IETF standards track process. 442 At the time of SPF's initial development, the prospect of getting an 443 RRTYPE allocated for SPF was not seriously considered, partly because 444 doing so had high barriers to entry. As a result, at the time it was 445 brought to the IETF for development and publication, there was 446 already a substantial and growing installed base that had SPF running 447 using TXT RRs. Eventually the application was made for the new 448 RRTYPE as a result of pressure from the DNS experts in the community, 449 who insisted upon doing so as the preferred path toward using the DNS 450 for storing such things as policy data. 452 Later, after RRTYPE 99 was assigned (long after IESG approval of 453 [SPF], in fact), a plan was put into place to effect a gradual 454 transition to using RRTYPE 99 instead of using RRTYPE 16. This plan 455 failed to take effect for four primary reasons: 457 1. there was hesitation to make the transition because existing 458 nameservers (and, in fact, DNS-aware firewalls) would drop or 459 reject requests for unknown RRTYPEs (see Section 3 for evidence 460 of this), which means successful rollout of a new RRtype is 461 contingent upon widespread adoption of updated nameservers and 462 resolver functions; 464 2. many DNS provisioning tools (e.g., web interfaces to controlling 465 DNS zone data) were, and still are, typically lethargic about 466 adding support for new RRTYPEs; 468 3. the substantial deployed base was already using RRTYPE 16, and it 469 was working just fine, leading to inertia; 471 4. [SPF] itself included a faulty transition plan, likely because of 472 the late addition of a requirement to develop one: It said a 473 server SHOULD publish both RRTYPEs and MUST publish at least one, 474 while a client can query either or both, which means both can 475 claim to be fully compliant while failing utterly to 476 interoperate. Publication occurred without proper IETF review, 477 so this was not detected prior to publication. 479 It is likely that this will happen again if the bar to creating new 480 RRTYPEs even for experimental development purposes is not lowered, 481 and handling of unknown RRTYPEs in software becomes generally more 482 graceful. Also important in this regard is encouragement of support 483 for new RRTYPEs in DNS record provisioning tools. 485 Fortunately in the intervening time, the requirements for new RRTYPE 486 assignments was changed to be less stringent (see [DNS-IANA]). Also, 487 the publication of [DNS-EXPAND] has provided some useful guidance in 488 this regard. However, there is still a common perception that adding 489 new types of data to the DNS will face resistance due to the lack of 490 appropriate software support. 492 There are DNS experts within the community that will undoubtedly 493 point to DNS servers and firewalls that mistreat queries for unknown 494 RRTYPEs, and to overly simplistic provisioning tools, and claim they 495 are broken as a way of answering these concerns. This is undoubtedly 496 correct, but the reality is that they are among us and likely will be 497 for some time, and this needs to be considered as new protocols and 498 IETF procedures are developed. 500 Appendix B. Acknowledgments 502 The following provided operational data that contributed to the 503 evidence presented above: 505 Cisco: contributed data about observed Sender ID and SPF records in 506 the DNS for a large number of domains (DNS survey #1) 508 Hotmail: contributed data about the difference between 509 RFC5321.MailFrom and RFC5322.From domains across large mail 510 volumes, and a survey of DNS replies observed in response to 511 incoming mail traffic (DNS survey #3) 513 John Levine: conducted a survey of DNS server logs to evaluate SPF- 514 related query traffic 516 McAfee: provided details about their SUBMITTER implementation and 517 usage statistics 519 Santronics: contributed data about the use of the SUBMITTER 520 extension in aggregate SMTP client traffic 522 The Trusted Domain Project: contributed data about the difference 523 between Sender ID and SPF results, conducted one of the detailed 524 TXT/SPF RRTYPE surveys including collecting timing data (DNS 525 survey #2), and conducted the MTA SUBMITTER survey 527 The author would also like to thank the following for their 528 contributions to the development of the text in this document: Dave 529 Crocker, Scott Kitterman, Barry Leiba, John Leslie, John Levine, 530 Hector Santos, and Alessandro Vesely. 532 Author's Address 534 Murray S. Kucherawy 535 Cloudmark 536 128 King St., 2nd Floor 537 San Francisco, CA 94107 538 USA 540 Phone: +1 415 946 3800 541 Email: superuser@gmail.com