idnits 2.17.1 draft-kucherawy-spfbis-experiment-03.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 (March 6, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PRA' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'SENDER-ID' is defined on line 223, 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 (~~), 3 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 March 6, 2012 5 Expires: September 7, 2012 7 The SPF/Sender-ID Experiment 8 draft-kucherawy-spfbis-experiment-03 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, and some concerns with Sender-ID and 16 compatibility with existing standards, the IESG required them to have 17 Experimental status and invited the community to observe their 18 deployments for a period of time, hoping convergence would be 19 possible later. 21 After six years, sufficient experience and evidence have been 22 collected that the experiment thus created can be considered 23 concluded, and a common path forward can be selected. This memo 24 presents those findings. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. The Need For Consensus . . . . . . . . . . . . . . . . . . . . 3 62 3. Evidence of Deployment . . . . . . . . . . . . . . . . . . . . 4 63 4. Evidence of Differences . . . . . . . . . . . . . . . . . . . . 5 64 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 8. Informative References . . . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 In April, 2006, the IETF published the [SPF] and [SUBMITTER]/ 74 [SENDER-ID]/[PRA] email authentication protocols. Both of these 75 enabled one to publish via the Domain Name System a policy declaring 76 which mail servers were authorized to send email on behalf of a 77 specific domain name. The two protocols made use of this policy 78 statement and some specific (but different) logic to evaluate whether 79 or not the email client sending or relaying a message was authorized 80 to do so. 82 Because Sender-ID could use the same policy statement as SPF, the 83 IESG at the time was concerned that an implementation of Sender-ID 84 might erroneously apply that statement to a message and, depending on 85 selected recipient actions, could improperly interfere with message 86 delivery. As a result, the IESG required the publication of all of 87 these documents as Experimental, and requested that the community 88 observe deployment and operation of the protocols over a period of 89 two years from publication in order to determine a reasonable path 90 forward. (For further details about the IESG's concern, see the IESG 91 Note prepended to all of those documents.) 93 Accordingly, this working group has convened to resolve this 94 experiment and propose advancement of a single protocol going 95 forward. This memo presents evidence on both deployment and efficacy 96 of the two protocols, and further discusses the increasing need for 97 consensus. At the end it presents conclusions and recommends a path 98 forward, as the IESG requested. 100 2. The Need For Consensus 102 These two protocols fall into a family of protocols that provide 103 domain-level email authentication services. Another prominent one is 104 [DKIM]. Various efforts exist that use these as building blocks to 105 increased abuse filtering capabilties, and indeed this sort of work 106 has spawned another working group in the Applications area, with 107 still more of these incubating in associations and trade groups 108 outside of the IETF. 110 There is thus some palpable interest in having a path authorization 111 scheme, as well as a domain-level signing scheme, on the Standards 112 Track so that these newer technologies can develop with confidence. 113 This is, in part, why the community has decided to expend the effort 114 to bring this experiment to a conclusion and document the results, 115 and then advance a single path authorization technology. 117 3. Evidence of Deployment 119 Two participants ran large-scale DNS surveys looking for SPF policy 120 records. 122 One data source for this report requested SPF records from 123 approximately 287,000 domains that had a TXT (type 16) policy record. 124 Of these, 4,613 (1.6%) also publish SPF (type 99) resource records. 126 [pending: updated TDP report numbers go in here] Another source 127 requested SPF records from 239,000 domains. Of these, # returned 128 type 16 answers, # returned type 99 answers, # returned both types, 129 and # returned neither. Of those answers retrieved, # included 130 records that start with the string "spf2.0/pra" which are specific 131 requests for Sender-ID processing by receivers. 133 During this second survey, some domains were observed to provide 134 immediate answers for type 16 queries, but would time out waiting for 135 replies to type 99 queries. 137 It is likely impossible to determine from a survey which MTAs have 138 SPF and/or Sender-ID checking enabled at message ingress since it 139 does not appear, for example, in the reply to the EHLO command from 140 extended [SMTP]. We therefore rely on evidence found via web 141 searches, and observed the following: 143 o A web site [SID-IMPL] dedicated to highlighting Sender-ID 144 implementations last updated in late 2007 listed 13 145 implementations, which we assume means they implement the PRA 146 checks. At least one of them is known no longer to be supported 147 by its vendor. 149 o The [OPENSPF] web site maintains a list of known implementations 150 of SPF. At the time of this memo's writing it listed six 151 libraries, 22 MTAs with built-in SPF implementations, and numerous 152 patches for MTAs and mail clients. 154 In a survey of numerous MTAs in current or recent use, only two 155 (Santronics WinServer and McAfee MxLogic) were found to contain 156 implementations of the SMTP SUBMITTER extension in server mode, which 157 could act as an enabler to Sender-ID. An unknown number of clients 158 implement it; although there is substantial activity showing its use 159 in logs, it is unclear whether these are separate implementations by 160 legitimate senders, or merely instances of distributed automated 161 malware seeking to improve their odds of reaching the end user. 163 [pending: passive DNS query report from John Levine] 165 [pending: SPF query results from Hotmail] 167 [other data TBD] 169 4. Evidence of Differences 171 It is plain from inspection of the two protocols that they have much 172 in common: For a single message, both require the same number of DNS 173 queries, and both require the same code to parse the result. The PRA 174 algorithm applied by Sender-ID is, however, more expensive than 175 simply extracting the domain name from the omnipresent 176 RFC5321.MailFrom. Thus, SPF is cheaper to apply to a message. 178 One set of specific data collected by a working group contributor 179 shows that in more than 95.5% of cases, Sender-ID and SPF reach the 180 same conclusion about a message, meaning either both protocols return 181 a "pass" result or both return a "fail" result. The data set 182 yielding this response could not further characterize the cases in 183 which the answers differed. 185 [pending: MAIL FROM/PRA comparison report from Hotmail] 187 [other data TBD] 189 5. Conclusions 191 It is standard procedure within the IETF to document as standard 192 those protocols and practices that have come into sufficient common 193 use as to become part of the basic infrastructure. 195 Given the evidence above, the working group feels that the experiment 196 allows the following conclusions: 198 1. [WG conclusions here] 200 6. IANA Considerations 202 This memo presents no actions for IANA. [RFC Editor: Please remove 203 this section prior to publication.] 205 7. Security Considerations 207 This memo contains information for the community only, akin to an 208 implementation report, and does not introduce any new security 209 concerns. Its implications could, in fact, resolve some. 211 8. Informative References 213 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 214 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 215 September 2011. 217 [OPENSPF] "Sender Policy Framework: Project Overview", 218 . 220 [PRA] Lyon, J., "Purported Responsible Address in E-Mail 221 Messages", RFC 4407, April 2006. 223 [SENDER-ID] 224 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 225 RFC 4406, April 2006. 227 [SID-IMPL] 228 "Sender ID Framework Industry Support and Solutions", 229 October 2007, . 232 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 233 October 2008. 235 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 236 for Authorizing Use of Domains in E-Mail, Version 1", 237 RFC 4408, April 2006. 239 [SUBMITTER] 240 Allman, E. and H. Katz, "SMTP Service Extension for 241 Indicating the Responsible Submitter of an E-Mail 242 Message", RFC 4405, April 2006. 244 Appendix A. Acknowledgments 246 The following provided operational data that contributed to the 247 findings presented above: 249 Cisco: contributed data about observed Sender-ID and SPF records in 250 the DNS for a large number of domains 252 Hotmail: contributed data about the difference between 253 RFC5321.MailFrom and RFC5322.From domains across large mail 254 volumes, and a survey of DNS queries observed in response to 255 outgoing mail traffic 257 Santronics: contributed data about the use of the SUBMITTER 258 extension in aggregate SMTP client traffic 260 The Trusted Domain Project: contributed data about the difference 261 between Sender-ID and SPF results, and counts of unique domains 262 appearing to publish different kinds of SPF and Sender-ID records 264 The author would also like to thank the following for their 265 contributions to the development of this memo: Dave Crocker, and 266 Scott Kitterman 268 Author's Address 270 Murray S. Kucherawy 271 Cloudmark 272 128 King St., 2nd Floor 273 San Francisco, CA 94107 274 USA 276 Phone: +1 415 946 3800 277 Email: msk@cloudmark.com