idnits 2.17.1 draft-ietf-marf-spf-reporting-10.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 (Using the creation date from RFC4408, updated by this document, for RFC5378 checks: 2005-01-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2012) is 4398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARF Working Group S. Kitterman 3 Internet-Draft Agari 4 Updates: 4408 (if approved) March 14, 2012 5 Intended status: Standards Track 6 Expires: September 15, 2012 8 SPF Authentication Failure Reporting using the Abuse Report Format 9 draft-ietf-marf-spf-reporting-10 11 Abstract 13 This memo presents extensions to the Abuse Reporting Format (ARF), 14 and Sender Policy Framework (SPF) specifications to allow for 15 detailed reporting of message authentication failures in an on-demand 16 fashion. 18 This memo updates RFC4408 by providing an IANA registry for SPF 19 modifiers. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 15, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Imported Definitions . . . . . . . . . . . . . . . . . . . 4 59 3. Optional Reporting Address for SPF . . . . . . . . . . . . . . 5 60 4. Requested Reports . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Requested Reports for SPF Failures . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. SPF Modifier Registration . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6.1. Identity Selection . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Report Volume . . . . . . . . . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 71 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 12 72 B.1. SPF DNS record for domain that sends no mail, but 73 requests reports . . . . . . . . . . . . . . . . . . . . . 12 74 B.2. Minimal SPF DNS record change to add a reporting 75 address . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 B.3. SPF DNS record with reporting address, report 77 percentage, and requested report type . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Abuse Reporting Format [ARF] defines a message format for sending 83 reports of abuse in the messaging infrastructure, with an eye toward 84 automating both the generating and consumption of those reports. 86 Sender Policy Framework [SPF] is one mechanism for message sender 87 authentication; it is "path-based" meaning it authenticates the route 88 that a message took from origin to destination. The output is a 89 verified domain name that can then be subjected to some sort of 90 evaluation process (e.g., comparison to a known-good list, submission 91 to a reputation service, etc.). 93 This document extends [SPF] to add an optional reporting address and 94 other parameters. Extension of [ARF] to add features required for 95 the reporting of these incidents is covered in 96 [I-D.IETF-MARF-AUTHFAILURE-REPORT] and [I-D.IETF-MARF-AS]. 98 This document additionally creates a an IANA registry of [SPF] record 99 modifiers to avoid modifier namespace collisions. 101 2. Definitions 103 2.1. Keywords 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORDS]. 109 2.2. Imported Definitions 111 The ABNF token "qp-section" is defined in [MIME]. 113 "local-part" is defined in [MAIL]. 115 "addr-spec" is defined in [MAIL]. 117 3. Optional Reporting Address for SPF 119 There exist cases in which an ADministrative Management Domain (ADMD) 120 (see [EMAIL-ARCH]) employing [SPF] for announcing sending practices 121 may want to know when messages are received via unauthorized routing. 122 Currently there is no such method defined in conjunction with 123 standardized approaches such as [ARF]. Similar information can be 124 gathered using a specially crafted [SPF] record and a special DNS 125 server to track [SPF] record lookups. 127 This document defines the following optional "modifier" (as defined 128 in Section 4.6.1 of [SPF]) to SPF records, using the form defined in 129 that specification: 131 ra= Reporting Address (plain-text; OPTIONAL; no default). MUST be a 132 local-part (see Section 3.4.1 of [MAIL]) specifying an e-mail 133 address to which a report SHOULD be sent when mail claiming to be 134 from this domain (see Section 2.4 of [SPF] for a description of 135 how domains are identified for SPF checks) has failed the 136 evaluation algorithm described in [SPF], in particular because a 137 message arrived via an unauthorized route. To generate a complete 138 address to which the report is sent, the verifier simply appends 139 to this value an "@" followed by the SPF-compliant domain per 140 paragraph 4.1 of [SPF]. ra= modifiers in a record that was reached 141 by following an "include" mechanism (defined in [SPF] paragraph 142 5.2) MUST be ignored. 144 ABNF: 146 spf-report-tag = "ra=" qp-section 148 rp= Requested Report Percentage (plain-text; OPTIONAL; default is 149 "100"). The value is an integer from 0 to 100 inclusive that 150 indicates what percentage of incidents of SPF failures, selected 151 at random, are to cause reports to be generated. The report 152 generator SHOULD NOT issue reports for more than the requested 153 percentage of incidents. An exception to this might be some out- 154 of-band arrangement between two parties to override it with some 155 mutually agreed value. Report generators MAY make use of the 156 "Incidents:" field in [ARF] to indicate that there are more 157 reportable incidents than there are reports. 159 ABNF: 161 spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT 163 rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The 164 value MUST be a colon-separated list of tokens representing those 165 conditions under which a report is desired. See Section 4.1 for a 166 list of valid tags. 168 ABNF: 170 spf-rr-type = ( "all" / "e" / "f" / "s" / "n" ) 172 spf-rr-tag = "rr=" spf-rr-type 0* ( ":" spf-rr-type ) 174 In the absence of an "ra=" tag in the SPF record, the "rp=" and "rr=" 175 tags MUST be ignored, and the report generator MUST NOT issue a 176 report. 178 4. Requested Reports 180 This memo also includes, as the "rr" tokens defined above, the means 181 by which the sender can request reports for specific circumstances of 182 interest. Verifiers MUST NOT generate reports for incidents that do 183 not match a requested report, and MUST ignore requests for reports 184 not included in this list. 186 4.1. Requested Reports for SPF Failures 188 The following report requests are defined for SPF results: 190 all All reports are requested. 192 e Reports are requested for messages that produced an SPF result of 193 "TempError" or "PermError". 195 f Reports are requested for messages that produced an SPF result of 196 "Fail". 198 s Reports are requested for messages that produced an SPF result of 199 "SoftFail". 201 n Reports are requested for messages that produced an SPF result of 202 "Neutral" or "None". 204 5. IANA Considerations 206 As required by [IANA-CONSIDERATIONS], this section contains registry 207 information for the new [SPF] modifiers. 209 5.1. SPF Modifier Registration 211 IANA is requested to create the Sender Policy Framework Modifier 212 Registry, to include a list of all registered SPF modifier names and 213 their defining documents. 215 New registrations or updates are to be published in accordance with 216 the "Specification Required" guidelines as described in 217 [IANA-CONSIDERATIONS]. New registrations and updates MUST contain 218 the following information: 220 1. Name of the modifier being registered or updated 222 2. The document in which the specification of the modifier is 223 published 225 3. New or updated status, which MUST be one of: 227 current: The field is in current use 229 deprecated: The field might be in current use but its use is 230 discouraged 232 historic: The field is no longer in current use 234 An update may make a notation on an existing registration indicating 235 that a registered field is historic or deprecated if appropriate. 237 +------------+-----------------+---------+ 238 | MODIFIER | REFERENCE | STATUS | 239 +------------+-----------------+---------+ 240 | exp | RFC4408 | current | 241 | redirect | RFC4408 | current | 242 | ra | (this document) | current | 243 | rp | (this document) | current | 244 | rr | (this document) | current | 245 +------------+-----------------+---------+ 247 6. Security Considerations 249 Inherited considerations: implementors are advised to consider the 250 Security Considerations sections of [SPF], [ARF], [I-D.IETF-MARF-AS], 251 and [I-D.IETF-MARF-AUTHFAILURE-REPORT]. 253 In addition to the advice in the Security Considerations section of 254 [I-D.IETF-MARF-AS], these additional considerations apply to 255 generation of [SPF] authentication failure reports: 257 6.1. Identity Selection 259 Preventing an [SPF] failure for SPF authentication failure reports is 260 essential to mitigate the risk of data loops. 262 If the [SMTP] return address to be used will not be the NULL 263 return address, i.e., "MAIL FROM:<>", then the selected return 264 address MUST be selected such that it will pass [SPF] MAIL FROM 265 checks upon initial receipt. 267 If the report is passed to the Mail Submission Agent (MSA) (MSA is 268 described in [EMAIL-ARCH] using [SMTP]), the HELO/EHLO command 269 parameter SHOULD also be selected so that it will pass [SPF] HELO 270 checks. 272 6.2. Report Volume 274 It is impossible to predict the volume of reports this facility will 275 generate when enabled by a report receiver. An implementer ought to 276 anticipate substantial volume, since the amount of abuse occurring at 277 receivers cannot be known ahead of time, and may vary rapidly and 278 unpredictably. 280 7. References 282 7.1. Normative References 284 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 285 Extensible Format for Email Feedback Reports", RFC 5965, 286 August 2010. 288 [I-D.IETF-MARF-AS] 289 Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email 290 Feedback Reports: An Applicability Statement for the Abuse 291 Reporting Format (ARF)", draft-ietf-marf-as (work in 292 progress), February 2012. 294 [I-D.IETF-MARF-AUTHFAILURE-REPORT] 295 Fontana, H., "Authentication Failure Reporting using the 296 Abuse Report Format", draft-ietf-marf-authfailure-report 297 (work in progress), January 2012. 299 [IANA-CONSIDERATIONS] 300 Alvestrand, H. and T. Narten, "Guidelines for Writing an 301 IANA Considerations Section in RFCs", RFC 5226, May 2008. 303 [KEYWORDS] 304 Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", RFC 2119, March 1997. 307 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 308 October 2008. 310 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 311 Extensions (MIME) Part One: Format of Internet Message 312 Bodies", RFC 2045, November 1996. 314 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 315 October 2008. 317 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 318 for Authorizing Use of Domains in E-Mail, Version 1", 319 RFC 4408, April 2006. 321 7.2. Informative References 323 [EMAIL-ARCH] 324 Crocker, D., "Internet Mail Architecture", RFC 5598, 325 October 2008. 327 Appendix A. Acknowledgements 329 The author wishes to acknowledge the following for their review and 330 constructive criticism of this proposal: Murray Kucherawy, Tim 331 Draegen, Julian Mehnle, and John Levine. 333 Appendix B. Examples 335 B.1. SPF DNS record for domain that sends no mail, but requests reports 337 v=spf1 ra=postmaster -all 339 B.2. Minimal SPF DNS record change to add a reporting address 341 v=spf1 mx:example.org ra=postmaster -all 343 B.3. SPF DNS record with reporting address, report percentage, and 344 requested report type 346 v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e 348 Author's Address 350 Scott Kitterman 351 Agari 352 3611 Scheel Dr 353 Ellicott City, MD 21042 354 US 356 Phone: +1 301 325 5475 357 Email: skitterman@agari.com