idnits 2.17.1 draft-kucherawy-spfbis-experiment-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2012) is 4452 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PRA' is defined on line 171, but no explicit reference was found in the text == Unused Reference: 'SENDER-ID' is defined on line 174, but no explicit reference was found in the text == Unused Reference: 'SUBMITTER' is defined on line 185, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 February 17, 2012 5 Expires: August 20, 2012 7 The SPF/Sender-ID Experiment 8 draft-kucherawy-spfbis-experiment-00 10 Abstract 12 In 2006 the IETF published a suite of protocol documents comprising 13 SPF and Sender-ID, two proposed email authentication protocols. 14 Because of interoperability concerns and the inability of the working 15 group producing them to converge on a single specification, the IESG 16 required them to have Experimental status and invited the community 17 to observe their deployments for a period of time, hoping convergence 18 would be possible later. 20 After six years, sufficient experience and evidence have been 21 collected that the experiment thus created can be considered 22 concluded, and a common path toward can be selected. This memo 23 presents those findings. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 20, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Need For Convergence . . . . . . . . . . . . . . . . . . . 3 61 3. Evidence of Deployment . . . . . . . . . . . . . . . . . . . . 4 62 4. Evidence of Differences . . . . . . . . . . . . . . . . . . . . 4 63 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 In April, 2006, the MARID working group published the [SPF] and 73 [SUBMITTER]/[SENDER-ID]/[PRA] email authentication protocols. Both 74 of these enabled one to publish via the Domain Name System a policy 75 declaring which mail servers were authorized to send email on behalf 76 of a specific domain name. The two protocols made use of this policy 77 statement and some specific (but different) logic to evaluate whether 78 or not the email client sending or relaying a message was authorized 79 to do so. 81 Because Sender-ID could use the same policy statement as SPF, the 82 IESG at the time was concerned that an implementation of Sender-ID 83 might erroneously apply that statement to a message and, depending on 84 selected recipient actions, could improperly interfere with message 85 delivery. As a result, the IESG required the publication of all of 86 these documents as Experimental, and requested that the community 87 observe deployment and operation of the protocols over a period of 88 two years from publication in order to determine a reasonable path 89 forward. 91 This working group has convened to resolve this experiment and 92 propose advancement of a single protocol going forward. This memo 93 presents evidence on both deployment and efficacy of the two 94 protocols, and further discusses the increasing need for convergence. 95 At the end it presents conclusions and recommends a path forward, as 96 the IESG requested. 98 2. The Need For Convergence 100 These two protocols fall into a family of protocols that provide 101 domain-level email authentication services. Another prominent one is 102 [DKIM]. Various efforts exist that use these as building blocks to 103 increased abuse filtering capabilties, and indeed this sort of work 104 has spawned another working group in the Applications area, with 105 still more of these incubating in associations and trade groups 106 outside of the IETF. 108 There is thus some palpable interest in having a path authorization 109 scheme, as well as a domain-level signing scheme, on the Standards 110 Track so that these newer technologies can develop. This is, in 111 part, why the community has decided to expend the energy to bring 112 this experiment to a conclusion and document the results. 114 3. Evidence of Deployment 116 A query of approximately 287,000 domains known to be publishing SPF 117 policy records in some way revealed that only 1.63% of them published 118 using the SPF resource record type. This suggests that using SPF 119 records as a way of separating SPF processing from Sender-ID 120 processing is not a reliable heuristic. For sites that published 121 both SPF and TXT RRs, as many as 17% of these actually included 122 separate policies, which suggests that keeping the two synchronized 123 could actually be an operational concern. It is possible, but 124 considered unlikely, that the deviation was deliberate in the 125 observed cases. 127 Further analysis suggests that of that same large set of domains, 128 approximately 1,200, or fewer than 1%, published Sender-ID records 129 (identified by "v=spf2"). 131 It is likely impossible to determine from a survey which MTAs have 132 SPF or Sender-ID checking enabled at message ingress since it does 133 not appear, for example in the reply to the EHLO command from 134 extended [SMTP]. 136 4. Evidence of Differences 138 Specific data collected by multiple independent working group 139 contributors (see Appendix A) shows that in more than 95% of cases, 140 Sender-ID and SPF reach the same conclusion about a message. Given 141 the data presented in the previous section, this means the domains 142 found in PRA-selected header fields in the message matched the 143 RFC5321.MailFrom domain. 145 [other data TBD] 147 5. Conclusions 149 Given the evidence above, the working group feels that the experiment 150 allows the following conclusions: 152 1. [conclusions here] 154 6. IANA Considerations 156 This memo presents no actions for IANA. [RFC Editor: Please remove 157 this section prior to publication.] 159 7. Security Considerations 161 This memo contains information for the community only, akin to an 162 implementation report, and does not introduce any new security 163 concerns. Its implications could, in fact, resolve some. 165 8. Informative References 167 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 168 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 169 September 2011. 171 [PRA] Lyon, J., "Purported Responsible Address in E-Mail 172 Messages", RFC 4407, April 2006. 174 [SENDER-ID] 175 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 176 RFC 4406, April 2006. 178 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 179 October 2008. 181 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 182 for Authorizing Use of Domains in E-Mail, Version 1", 183 RFC 4408, April 2006. 185 [SUBMITTER] 186 Allman, E. and H. Katz, "SMTP Service Extension for 187 Indicating the Responsible Submitter of an E-Mail 188 Message", RFC 4405, April 2006. 190 Appendix A. Acknowledgments 192 The following provided operational data that contributed to the 193 findings presented above: 195 Cisco: contributed data about observed Sender-ID and SPF data in the 196 DNS for a large number of domains 198 Hotmail: contributed data about the difference between Sender-ID and 199 SPF evaluations 201 The Trusted Domain Project: contributed data about the difference 202 between Sender-ID and SPF evaluations 204 The author would also like to thank the following for their 205 contributions to the development of this memo: (names) 207 Author's Address 209 Murray S. Kucherawy 210 Cloudmark 211 128 King St., 2nd Floor 212 San Francisco, CA 94107 213 USA 215 Phone: +1 415 946 3800 216 Email: msk@cloudmark.com