idnits 2.17.1 draft-ietf-marf-authfailure-report-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2012) is 4475 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) ** Downref: Normative reference to an Historic RFC: RFC 5617 (ref. 'ADSP') ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 3462 (ref. 'REPORT') (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 5 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 H. Fontana 3 Internet-Draft January 18, 2012 4 Intended status: Standards Track 5 Expires: July 21, 2012 7 Authentication Failure Reporting using the Abuse Report Format 8 draft-ietf-marf-authfailure-report-10 10 Abstract 12 This memo registers an extension report type to the Abuse Reporting 13 Format (ARF), affecting multiple registries, for use in generating 14 receipt-time reports about messages that fail one or more email 15 message authentication checks. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 21, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Email Architecture . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Base 64 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Technologies . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. ARF Extension for Authentication Failure Reporting . . . . . . 5 58 3.1. New ARF Feedback Type . . . . . . . . . . . . . . . . . . 5 59 3.2. New ARF Header Field Names . . . . . . . . . . . . . . . . 6 60 3.2.1. Required For All Reports . . . . . . . . . . . . . . . 6 61 3.2.2. Optional For All Reports . . . . . . . . . . . . . . . 6 62 3.2.3. Required For DKIM Reports . . . . . . . . . . . . . . 7 63 3.2.4. Optional For DKIM Reports . . . . . . . . . . . . . . 7 64 3.2.5. Required For ADSP Reports . . . . . . . . . . . . . . 7 65 3.2.6. Required For SPF Reports . . . . . . . . . . . . . . . 7 66 3.3. Authentication Failure Types . . . . . . . . . . . . . . . 8 67 4. Syntax For Added ARF Header Fields . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Updates to ARF Feedback Types . . . . . . . . . . . . . . 10 70 5.2. Updates to ARF Header Field Names . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6.1. Inherited Considerations . . . . . . . . . . . . . . . . . 13 73 6.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.3. Automatic Generation . . . . . . . . . . . . . . . . . . . 13 75 6.4. Envelope Sender Selection . . . . . . . . . . . . . . . . 14 76 6.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 14 77 6.6. Redaction of Data in DKIM Reports . . . . . . . . . . . . 14 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 82 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . . 18 83 B.1. Example Use of ARF Extension Headers . . . . . . . . . . . 18 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 The Abuse Reporting Format ([ARF]) defines a message format for 89 sending reports of abuse in the messaging infrastructure, with an eye 90 towards automating both the generation and consumption of those 91 reports. There is now also a desire to extend the ARF format to 92 include reporting of messages that fail to authenticate using known 93 message authentication methods, such as DomainKeys Identified Mail 94 ([DKIM]) and Sender Policy Framework ([SPF]), as these are sometimes 95 evidence of abuse that can be detected and reported through automated 96 means. The same mechanism can be used to convey forensic information 97 about the specific reason the authentication method failed. Thus, 98 this memo presents such extensions to ARF that allow for detailed 99 reporting of message authentication method failures. 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. Email Architecture 111 This memo uses some terms whose definitions and descriptions can be 112 found in [EMAIL-ARCH]. 114 2.3. Base 64 116 base64 is defined in Section 4 of [BASE64]. 118 The values that are base64 encodings MAY contain FWS for formatting 119 purposes as per the usual header field wrapping defined in [MAIL]. 120 During decoding, any characters not in the base64 alphabet are 121 ignored so that such line wrapping does not harm the value. The ABNF 122 token "FWS" is defined in [DKIM]. No other extensions to the valid 123 base64 character set are permitted. 125 2.4. Technologies 127 There are technologies in email security that provide authentication 128 services and some that do authorization. These are often conflated. 129 A discussion of this that is useful for establishing context can be 130 found in Section 1.5.2 in [AUTH-RESULTS]. 132 3. ARF Extension for Authentication Failure Reporting 134 The current report format defined in [ARF] lacks some specific 135 features required to do effective email authentication failure 136 reporting. This section defines extensions to ARF to accommodate 137 this requirement. 139 A single report describes a single email authentication failure. 140 Multiple reports MAY be used to report multiple failures for a single 141 message. 143 3.1. New ARF Feedback Type 145 A new feedback type of "auth-failure" is defined as an extension per 146 Section 7.3 of [ARF]. 148 A message that uses this feedback type has the following modified 149 header field requirements for the second (machine-parseable) [MIME] 150 part of the report: 152 Authentication-Results: Syntax as specified in [AUTH-RESULTS]. 153 Furthermore, [ARF] specifies this field is OPTIONAL and appears at 154 most once; for this extension, this field MUST be present, but 155 MUST reflect only a single authentication method's result. 157 Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore, 158 [ARF] specifies this field is OPTIONAL and appears at most once; 159 for this extension, this field's inclusion is RECOMMENDED, where 160 that value is available, to aid in diagnosing of the 161 authentication failure. 163 Original-Mail-From: Syntax as specified in [ARF]. Furthermore, 164 [ARF] specifies this field is OPTIONAL and appears at most once; 165 for this extension, this field's inclusion is RECOMMENDED, where 166 that value is available, to aid in diagnosing of the 167 authentication failure. 169 Source-IP: Syntax as specified in [ARF]. Furthermore, [ARF] 170 specifies this field is OPTIONAL and appears at most once; for 171 this extension, this field's inclusion is RECOMMENDED, where that 172 value is available, to aid in diagnosing of the authentication 173 failure. 175 Reported-Domain: Syntax as specified in [ARF]. Furthermore, [ARF] 176 specifies this field is OPTIONAL and appears at most once; for 177 this extension, this field MUST be present if such a value is 178 available. 180 Delivery-Result: As specified in Section 3.2.2. This field is 181 OPTIONAL, but MUST NOT appear more than once. If present, it 182 SHOULD indicate the outcome of the message in some meaningful way, 183 but MAY be set to "other" for local policy reasons. 185 The third MIME part of the message is either of type "message/rfc822" 186 (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in 187 [REPORT]) and contains a copy of the entire header block from the 188 original message. This part MUST be included (contrary to [REPORT], 189 which makes it optional). 191 For privacy reasons, report generators might need to redact portions 192 of a reported message such as an identifier or address associated 193 with the end user whose complaint action resulted in the report. A 194 discussion of relevant issues and a suggested method for doing so can 195 be found in [I-D.IETF-MARF-REDACTION]. 197 3.2. New ARF Header Field Names 199 The following new ARF field names are defined as extensions to 200 Section 3.1 of [ARF]. 202 3.2.1. Required For All Reports 204 Auth-Failure: Indicates the failure from an email authentication 205 method that is being reported. The list of valid values is 206 enumerated in Section 3.3. 208 3.2.2. Optional For All Reports 210 Delivery-Result: The final message disposition that was enacted by 211 the Administrative Management Domain (ADMD) generating the report 212 and MUST NOT appear more than once. Possible values are: 214 delivered: The message was delivered (not specific as to where). 216 spam: The message was delivered to the recipient's spam folder 217 (or equivalent). 219 policy: The message was not delivered to the intended inbox due 220 to a failure from an email authentication method. The specific 221 action taken is not specified. 223 reject: The message was rejected. 225 other: The message had a final disposition not covered by one of 226 the above values. 228 3.2.3. Required For DKIM Reports 230 DKIM-Domain: The domain that signed the message, taken from the "d=" 231 tag of the signature. 233 DKIM-Identity: The identity of the signature that failed 234 verification, taken from the "i=" tag of the signature. 236 DKIM-Selector: The selector of the signature that failed 237 verification, taken from the "s=" tag of the signature. 239 3.2.4. Optional For DKIM Reports 241 DKIM-Canonicalized-Header: A base64 encoding of the canonicalized 242 header of the message as generated by the verifier. 244 DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body 245 of the message as generated by the verifier. The encoded content 246 MUST be limited to those octets that contribute to the DKIM body 247 hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]). 249 If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode 250 redacted data, they MUST NOT be included. Otherwise, they SHOULD be 251 included. The data presented there have to be exactly the 252 canonicalized header and body as defined by [DKIM] and computed at 253 the verifier. This is because these fields are intended to aid in 254 identifying message alterations that invalidate DKIM signatures in 255 transit. Including redacted data in them renders the data unusable. 256 (See also Section 3.1 and Section 6.6 for further discussion.) 258 3.2.5. Required For ADSP Reports 260 DKIM-ADSP-DNS: Includes the Author Domain Signing Practices (ADSP) 261 policy used to obtain the verifier's ADSP result. This MUST be 262 formatted per Section 4.2.1 of [ADSP]. 264 3.2.6. Required For SPF Reports 266 SPF-DNS: This field MUST appear once for every Sender Policy 267 Framework ([SPF]) SPF record used to obtain the SPF result. It 268 MUST include the DNS RRTYPE used, the DNS domain from which the 269 record was retrieved, and the content of that record. The syntax 270 is defined in Section 4. 272 3.3. Authentication Failure Types 274 The list of defined email authentication failure types used in the 275 "Auth-Failure:" header field (defined above), is as follows: 277 adsp: The message did not conform to the author domain's published 278 [ADSP] signing practises. The DKIM-ADSP-DNS field MUST be 279 included in the report. 281 bodyhash: The body hash in the signature and the body hash computed 282 by the verifier did not match. The DKIM-Canonicalized-Body field 283 SHOULD be included in the report (see Section 3.2.4). 285 revoked: The DKIM key referenced by the signature on the message has 286 been revoked. The DKIM-Domain and DKIM-Selector fields MUST be 287 included in the report. 289 signature: The DKIM signature on the message did not successfully 290 verify against the header hash and public key. The DKIM-Domain 291 and DKIM-Selector fields MUST be included in the report, and the 292 DKIM-Canonicalized-Header field SHOULD be included in the report 293 (see Section 3.2.4). 295 spf: The evaluation of the author domain's SPF record produced a 296 "none", "fail", "softfail", "temperror" or "permerror" result. 297 ("none" is not strictly a failure per [SPF], but a service that 298 demands successful SPF evaluations of clients could treat it like 299 a failure.) 301 Supplementary data MAY be included in the form of [MAIL]-compliant 302 comments. For example, "Auth-Failure: adsp" could be augmented by a 303 comment to indicate that the failed message was rejected because it 304 was not signed when it should have been. See Appendix B for an 305 example. 307 4. Syntax For Added ARF Header Fields 309 The [ABNF] definitions for the new fields are as follows: 311 auth-failure = "Auth-Failure:" [CFWS] 312 ( "adsp" / "bodyhash" / "revoked" / 313 "signature" / "spf" ) [CFWS] CRLF 314 ; "CFWS" is defined in [MAIL] 316 delivery-result = "Delivery-Result:" [CFWS] 317 ( "delivered" / "spam" /"policy" / 318 "reject" / "other" ) [CFWS] CRLF 320 dkim-header = "DKIM-Canonicalized-Header:" [CFWS] 321 base64string CRLF 322 ; "base64string" is defined in [DKIM] 324 dkim-sig-domain = "DKIM-Domain:" [CFWS] dkim-domain [CFWS] 325 CRLF 326 ; "dkim-domain" is defined in [DKIM] 328 dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@" 329 domain-name [CFWS] CRLF 330 ; "local-part" is defined in [MAIL] 332 dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF 333 ; "selector" is defined in [DKIM] 335 dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS] 336 quoted-string [CFWS] CRLF 337 ; "quoted-string" is defined in [MAIL] 339 dkim-body = "DKIM-Canonicalized-Body:" [CFWS] 340 base64string CRLF 342 dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS] 343 quoted-string [CFWS] CRLF 345 spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS] 346 domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF 348 5. IANA Considerations 350 As required by [IANA], this section contains registry information for 351 the extension to [ARF]. 353 5.1. Updates to ARF Feedback Types 355 The following feedback type is added to the Feedback Report Type 356 Values registry: 358 Feedback Type: auth-failure 359 Description: email authentication failure report 360 Published in: [this memo] 361 Status: current 363 5.2. Updates to ARF Header Field Names 365 The following headers are added to the Feedback Report Header Fields 366 registry: 368 Field Name: Auth-Failure 369 Description: Type of email authentication method failure 370 Multiple Appearances: No 371 Related "Feedback-Type": auth-failure 372 Published in: [this memo] 373 Status: current 375 Field Name: Delivery-Result 376 Description: Final disposition of the subject message 377 Multiple Appearances: No 378 Related "Feedback-Type": auth-failure 379 Published in: [this memo] 380 Status: current 382 Field Name: DKIM-ADSP-DNS 383 Description: Retrieved DKIM ADSP record 384 Multiple Appearances: No 385 Related "Feedback-Type": auth-failure 386 Published in: [this memo] 387 Status: current 388 Field Name: DKIM-Canonicalized-Body 389 Description: Canonicalized body, per DKIM 390 Multiple Appearances: No 391 Related "Feedback-Type": auth-failure 392 Published in: [this memo] 393 Status: current 395 Field Name: DKIM-Canonicalized-Header 396 Description: Canonicalized header, per DKIM 397 Multiple Appearances: No 398 Related "Feedback-Type": auth-failure 399 Published in: [this memo] 400 Status: current 402 Field Name: DKIM-Domain 403 Description: DKIM signing domain from "d=" tag 404 Multiple Appearances: No 405 Related "Feedback-Type": auth-failure 406 Published in: [this memo] 407 Status: current 409 Field Name: DKIM-Identity 410 Description: Identity from DKIM signature 411 Multiple Appearances: No 412 Related "Feedback-Type": auth-failure 413 Published in: [this memo] 414 Status: current 416 Field Name: DKIM-Selector 417 Description: Selector from DKIM signature 418 Multiple Appearances: No 419 Related "Feedback-Type": auth-failure 420 Published in: [this memo] 421 Status: current 423 Field Name: DKIM-Selector-DNS 424 Description: Retrieved DKIM key record 425 Multiple Appearances: No 426 Related "Feedback-Type": auth-failure 427 Published in: [this memo] 428 Status: current 429 Field Name: SPF-DNS 430 Description: Retrieved SPF record 431 Multiple Appearances: No 432 Related "Feedback-Type": auth-failure 433 Published in: [this memo] 434 Status: current 436 6. Security Considerations 438 Security issues with respect to these reports are similar to those 439 found in [DSN]. 441 6.1. Inherited Considerations 443 Implementers are advised to consider the Security Considerations 444 sections of [DKIM], [ADSP] [SPF] and [ARF]. 446 6.2. Forgeries 448 These reports can be forged as easily as ordinary Internet electronic 449 mail. User agents and automatic mail handling facilities (such as 450 mail distribution list exploders) that wish to make automatic use of 451 DSNs of any kind should take appropriate precautions to minimize the 452 potential damage from denial-of-service attacks. 454 Security threats related to forged DSNs include the sending of: 456 a. A falsified email authentication method failure notification when 457 the message was in fact delivered to the indicated recipient; 459 b. Falsified signature information, such as selector, domain, etc. 461 Perhaps the simplest means of mitigating this threat is to assert 462 that these reports should themselves be signed with something like 463 DKIM. On the other hand, if there's a problem with the DKIM 464 infrastructure at the verifier, signing DKIM failure reports might 465 produce reports that aren't trusted or even accepted by their 466 intended recipients. 468 6.3. Automatic Generation 470 Automatic generation of these reports by verifying agents can cause a 471 denial-of-service attack when a large volume of e-mail is sent that 472 causes email authentication failures for whatever reason. 474 Limiting the rate of generation of these messages might be 475 appropriate but threatens to inhibit the distribution of important 476 and possibly time-sensitive information. 478 In general ARF feedback loop terms, it is suggested that report 479 generators only create these (or any) ARF reports after an out-of- 480 band arrangement has been made between two parties. This mechanism 481 then becomes a way to adjust parameters of an authorized abuse report 482 feedback loop that is configured and activated by private agreement 483 rather than starting to send them automatically based solely on 484 discovered data in the DNS. 486 6.4. Envelope Sender Selection 488 In the case of transmitted reports in the form of a new message, it 489 is necessary to consider the construction and transmission of the 490 message so as to avoid amplification attacks, deliberate or 491 otherwise. See Section 5 of [ARF] for further information. 493 6.5. Reporting Multiple Incidents 495 If it is known that a particular host generates abuse reports upon 496 certain incidents, an attacker could forge a high volume of messages 497 that will trigger such a report. The recipient of the report could 498 then be innundated with reports. This could easily be extended to a 499 distributed denial-of-service attack by finding a number of report- 500 generating servers. 502 The incident count referenced in [ARF] provides a limited form of 503 mitigation. The host generating reports may elect to send reports 504 only periodically, with each report representing a number of 505 identical or near-identical incidents. One might even do something 506 inverse-exponentially, sending reports for each of the first ten 507 incidents, then every tenth incident up to 100, then every 100th 508 incident up to 1000, etc. until some period of relative quiet after 509 which the limitation resets. 511 The use of this for "near-identical" incidents in particular causes a 512 degradation in reporting quality, however. If for example a large 513 number of pieces of spam arrive from one attacker, a reporting agent 514 might decide only to send a report about a fraction of those 515 messages. While this averts a flood of reports to a system 516 administrator, the precise details of each incident are similarly not 517 sent. 519 6.6. Redaction of Data in DKIM Reports 521 This memo requires that the canonicalized header and body be returned 522 without being subject to redaction when a DKIM failure is being 523 reported. This is necessary to ensure that the returned 524 canonicalized forms are useful for debugging as they must be compared 525 to the equivalent form at the signer. If a message is altered in 526 transit, and the returned data are also redacted, the redacted 527 portion and the altered portion may overlap, rendering the comparison 528 results meaningless. However, unredacted data can leak information 529 the reporting entity considers to be private. It is for this reason 530 the return of the canonicalized forms is not required. 532 7. References 534 7.1. Normative References 536 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", RFC 5234, January 2008. 539 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 540 Sender Signing Practises", RFC 5617, August 2009. 542 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 543 Extensible Format for Email Feedback Reports", RFC 5965, 544 August 2010. 546 [AUTH-RESULTS] 547 Kucherawy, M., "Message Header Field for Indicating 548 Message Authentication Status", RFC 5451, April 2009. 550 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 551 Encodings", RFC 4648, October 2006. 553 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 554 Identified Mail (DKIM) Signatures", RFC 6376, 555 September 2011. 557 [I-D.IETF-MARF-REDACTION] 558 Falk, JD., "Redaction of Potentially Sensitive Data from 559 Mail Abuse Reports", I-D draft-ietf-marf-redaction, 560 March 2011. 562 [IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing an 563 IANA Considerations Section in RFCs", RFC 5226, May 2008. 565 [KEYWORDS] 566 Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", RFC 2119, March 1997. 569 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 570 October 2008. 572 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 573 Extensions (MIME) Part One: Format of Internet Message 574 Bodies", RFC 2045, November 1996. 576 [MIME-TYPES] 577 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 578 Extensions (MIME) Part Two: Media Types", RFC 2046, 579 November 1996. 581 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 582 Reporting of Mail System Administrative Messages", 583 RFC 3462, January 2003. 585 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 586 for Authorizing Use of Domains in E-Mail, Version 1", 587 RFC 4408, April 2006. 589 7.2. Informative References 591 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 592 for Delivery Status Notifications", RFC 3464, 593 January 2003. 595 [EMAIL-ARCH] 596 Crocker, D., "Internet Mail Architecture", RFC 5598, 597 October 2008. 599 Appendix A. Acknowledgements 601 The authors wish to acknowledge the following for their review and 602 constructive criticism of this proposal: Frank Ellerman, J.D. Falk, 603 Scott Kitterman, John Levine, Mike Markley, Kelly Wanser, Murray 604 Kucherawy and Alessandro Vesely. 606 Appendix B. Example 608 This section contains an example of the use of the extension defined 609 by this memo. 611 B.1. Example Use of ARF Extension Headers 613 An ARF-formatted report using the proposed ARF extension fields: 615 Message-ID: <433689.81121.example@mta.mail.receiver.example> 616 From: "SomeISP Antispam Feedback" 617 To: arf-failure@sender.example 618 Subject: FW: You have a new bill from your bank 619 Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT) 620 MIME-Version: 1.0 621 Content-Type: multipart/report; 622 boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg"; 623 report-type=feedback-report 624 Content-Transfer-Encoding: 7bit 626 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg 627 Content-Type: text/plain; charset="us-ascii" 628 Content-Disposition: inline 629 Content-Transfer-Encoding: 7bit 631 This is an authentication failure report for an email message 632 received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT). 633 For more information about this format please see [this memo]. 635 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg 636 Content-Type: message/feedback-report 637 Content-Transfer-Encoding: 7bit 639 Feedback-Type: auth-failure 640 User-Agent: Someisp!Mail-Feedback/1.0 641 Version: 1 642 Original-Mail-From: anexample.reply@a.sender.example 643 Original-Envelope-Id: o3F52gxO029144 644 Authentication-Results: mta1011.mail.tp2.receiver.example; 645 dkim=fail (bodyhash) header.d=sender.example 646 Auth-Failure: bodyhash 647 DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0 648 aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU 649 gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH 650 RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI 651 HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu 652 ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l 653 uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG 654 NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb 655 GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw 656 bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN 657 pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH 658 BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K 659 DKIM-Domain: sender.example 660 DKIM-Identity: @sender.example 661 DKIM-Selector: testkey 662 Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT) 663 Source-IP: 192.0.2.1 664 Reported-Domain: a.sender.example 665 Reported-URI: http://www.sender.example/ 667 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg 668 Content-Type: text/rfc822-headers 669 Content-Transfer-Encoding: 7bit 671 Authentication-Results: mta1011.mail.tp2.receiver.example; 672 dkim=fail (bodyhash) header.d=sender.example; 673 spf=pass smtp.mailfrom=anexample.reply@a.sender.example 674 Received: from smtp-out.sender.example 675 by mta1011.mail.tp2.receiver.example 676 with SMTP id oB85W8xV000169; 677 Sat, 08 Oct 2011 13:15:58 -0700 (PDT) 678 DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256; 679 s=testkey; d=sender.example; h=From:To:Subject:Date; 680 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 681 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 682 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 683 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 684 4bmp/YzhwvcubU4= 685 Received: from mail.sender.example 686 by smtp-out.sender.example 687 with SMTP id o3F52gxO029144; 688 Sat, 08 Oct 2011 13:15:31 -0700 (PDT) 689 Received: from internal-client-001.sender.example 690 by mail.sender.example 691 with SMTP id o3F3BwdY028431; 692 Sat, 08 Oct 2011 13:15:24 -0700 (PDT) 693 Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT) 694 Reply-To: anexample.reply@a.sender.example 695 From: anexample@a.sender.example 696 To: someuser@receiver.example 697 Subject: You have a new bill from your bank 698 Message-ID: <87913910.1318094604546@out.sender.example> 700 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg-- 701 Example 1: Example ARF report using these extensions 703 This example ARF message is making the following assertion: 705 o DKIM verification of the signature added within "example.com" 706 failed 708 o The cause for the verification failure was a mismatch between the 709 body contents observed at the verifier and the body hash contained 710 in the signature. 712 Author's Address 714 Hilda L. Fontana 715 3579 E. Foothill Blvd., suite 282 716 Pasadena, CA 91107 717 US 719 Phone: +1 626 676 8852 720 Email: hilda@hfontana.com