idnits 2.17.1 draft-kucherawy-spfbis-experiment-01.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 19, 2012) is 4449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PRA' is defined on line 199, 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 (~~), 2 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 19, 2012 5 Expires: August 22, 2012 7 The SPF/Sender-ID Experiment 8 draft-kucherawy-spfbis-experiment-01 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 created by simultaneous use of 15 the two protocols by a receiver, the IESG required them to have 16 Experimental status and invited the community to observe their 17 deployments for a period of time, hoping convergence would be 18 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 forward 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 22, 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 Consensus . . . . . . . . . . . . . . . . . . . . 3 61 3. Evidence of Deployment . . . . . . . . . . . . . . . . . . . . 4 62 4. Evidence of Differences . . . . . . . . . . . . . . . . . . . . 4 63 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 In April, 2006, the IETF published the [SPF] and [SUBMITTER]/ 73 [SENDER-ID]/[PRA] email authentication protocols. Both of these 74 enabled one to publish via the Domain Name System a policy declaring 75 which mail servers were authorized to send email on behalf of a 76 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. (For further details about the IESG's concern, see the IESG 90 Note prepended to all of those documents.) 92 Accordingly, this working group has convened to resolve this 93 experiment and propose advancement of a single protocol going 94 forward. This memo presents evidence on both deployment and efficacy 95 of the two protocols, and further discusses the increasing need for 96 consensus. At the end it presents conclusions and recommends a path 97 forward, as the IESG requested. 99 2. The Need For Consensus 101 These two protocols fall into a family of protocols that provide 102 domain-level email authentication services. Another prominent one is 103 [DKIM]. Various efforts exist that use these as building blocks to 104 increased abuse filtering capabilties, and indeed this sort of work 105 has spawned another working group in the Applications area, with 106 still more of these incubating in associations and trade groups 107 outside of the IETF. 109 There is thus some palpable interest in having a path authorization 110 scheme, as well as a domain-level signing scheme, on the Standards 111 Track so that these newer technologies can develop with confidence. 112 This is, in part, why the community has decided to expend the effort 113 to bring this experiment to a conclusion and document the results, 114 and then advance a single path authorization technology. 116 3. Evidence of Deployment 118 Two different sources (see Appendix A) report that over 239,000 119 domains have been observed to be publishing SPF records of some kind. 120 This includes either TXT or SPF resource record types, with the 121 prefix "v=spf1" found. The same two reporting sources indicated far 122 fewer that published "spf2.0" records that would indicate the 123 publisher requested Sender-ID handling only; one source projected 124 approximately 1,200 such domains while the other observed fewer than 125 100. 127 It is likely impossible to determine from a survey which MTAs have 128 SPF or Sender-ID checking enabled at message ingress since it does 129 not appear, for example, in the reply to the EHLO command from 130 extended [SMTP]. 132 A survey of over 20 MTAs in current or recent use includes only one 133 implementation of the SMTP SUBMITTER extension that could act as an 134 enabler to [SENDER-ID]. 136 The OpenSPF web site maintains a list of known implementations of 137 SPF. At the time of this memo's writing it listed six libraries, 22 138 MTAs with built-in SPF implementations, and numerous patches for MTAs 139 and mail clients. No such summary about Sender-ID support in 140 software could be found; one specific product implementation for 141 inbound checking was discovered. 143 [other data TBD] 145 4. Evidence of Differences 147 It is plain from inspection of the two protocols that they have much 148 in common: For a single message, both require the same number of DNS 149 queries, and both require the same code to parse the result. The PRA 150 algorithm applied by Sender-ID is, however, more expensive than 151 simply extracting the domain name from the omnipresent 152 RFC5321.MailFrom. Thus, SPF is cheaper to apply to a message. 154 One set of specific data collected by a working group contributor 155 shows that in more than 95.5% of cases, Sender-ID and SPF reach the 156 same conclusion about a message, meaning either both protocols return 157 a "pass" result or both return a "fail" result. The data set 158 yielding this response could not further characterize the cases in 159 which the answers differed. 161 Another data set from a different (much larger) source showed that in 162 fewer than 5% of cases did the RFC5321.MailFrom domain and the 163 RFC5322.From domain differ. This is somewhat meaningful when 164 determining the difference between the two protocols, but is more 165 important when considering the fact that most Mail User Agents 166 (MUAs), which actually present mail to the end user, typically only 167 render the contents of the RFC5322.From field. 169 [other data TBD] 171 5. Conclusions 173 It is standard procedure within the IETF to document as standard 174 those protocols and practices that have come into sufficient common 175 use as to become part of the basic infrastructure. 177 Given the evidence above, the working group feels that the experiment 178 allows the following conclusions: 180 1. [WG conclusions here] 182 6. IANA Considerations 184 This memo presents no actions for IANA. [RFC Editor: Please remove 185 this section prior to publication.] 187 7. Security Considerations 189 This memo contains information for the community only, akin to an 190 implementation report, and does not introduce any new security 191 concerns. Its implications could, in fact, resolve some. 193 8. Informative References 195 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 196 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 197 September 2011. 199 [PRA] Lyon, J., "Purported Responsible Address in E-Mail 200 Messages", RFC 4407, April 2006. 202 [SENDER-ID] 203 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 204 RFC 4406, April 2006. 206 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 207 October 2008. 209 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 210 for Authorizing Use of Domains in E-Mail, Version 1", 211 RFC 4408, April 2006. 213 [SUBMITTER] 214 Allman, E. and H. Katz, "SMTP Service Extension for 215 Indicating the Responsible Submitter of an E-Mail 216 Message", RFC 4405, April 2006. 218 Appendix A. Acknowledgments 220 The following provided operational data that contributed to the 221 findings presented above: 223 Cisco: contributed data about observed Sender-ID and SPF records in 224 the DNS for a large number of domains 226 Hotmail: contributed data about the difference between Sender-ID and 227 SPF evaluations 229 The Trusted Domain Project: contributed data about the difference 230 between Sender-ID and SPF evaluations, and counts of unique 231 domains appearing to request Sender-ID processing 233 The author would also like to thank the following for their 234 contributions to the development of this memo: Dave Crocker, Scott 235 Kitterman 237 Author's Address 239 Murray S. Kucherawy 240 Cloudmark 241 128 King St., 2nd Floor 242 San Francisco, CA 94107 243 USA 245 Phone: +1 415 946 3800 246 Email: msk@cloudmark.com