7Internet Engineering Task Force (IETF) H. Fontana
8Request for Comments: 6591 April 2012
9Category: Standards Track
13 Authentication Failure Reporting Using the Abuse Reporting Format
17 This memo registers an extension report type for the Abuse Reporting
18 Format (ARF), affecting multiple registries, for use in generating
19 receipt-time reports about messages that fail one or more email
20 message authentication checks.
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc6591.
38 Copyright (c) 2012 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
58Fontana Standards Track [Page 1]
60RFC 6591 Auth Failure Reporting April 2012
65 1. Introduction ....................................................2
66 2. Definitions .....................................................3
67 2.1. Key Words ..................................................3
68 2.2. Email Architecture .........................................3
69 2.3. Base64 .....................................................3
70 2.4. Technologies ...............................................3
71 3. ARF Extension for Authentication Failure Reporting ..............3
72 3.1. New ARF Feedback Type ......................................4
73 3.2. New ARF Header Field Names .................................5
74 3.2.1. Required for All Reports ............................5
75 3.2.2. Optional for All Reports ............................5
76 3.2.3. Required for DKIM Reports ...........................5
77 3.2.4. Optional for DKIM Reports ...........................6
78 3.2.5. Required for ADSP Reports ...........................6
79 3.2.6. Required for SPF Reports ............................6
80 3.3. Authentication Failure Types ...............................6
81 4. Syntax for Added ARF Header Fields ..............................7
82 5. IANA Considerations .............................................8
83 5.1. Updates to ARF Feedback Types ..............................8
84 5.2. Updates to ARF Header Field Names ..........................8
85 6. Security Considerations ........................................10
86 6.1. Inherited Considerations ..................................10
87 6.2. Forgeries .................................................10
88 6.3. Automatic Generation ......................................11
89 6.4. Envelope Sender Selection .................................11
90 6.5. Reporting Multiple Incidents ..............................11
91 6.6. Redaction of Data in DKIM Reports .........................12
92 7. References .....................................................12
93 7.1. Normative References ......................................12
94 7.2. Informative References ....................................13
95 Appendix A. Acknowledgements ......................................14
96 Appendix B. Example ...............................................14
97 B.1. Example Use of ARF Extension Headers .......................14
101 The Abuse Reporting Format [ARF] defines a message format for sending
102 reports of abuse in the messaging infrastructure, with an eye towards
103 automating both the generation and consumption of those reports.
104 There is now also a desire to extend the ARF to include the reporting
105 of messages that fail to authenticate using known message
106 authentication methods, such as DomainKeys Identified Mail [DKIM] and
107 Sender Policy Framework [SPF], as these are sometimes evidence of
108 abuse that can be detected and reported through automated means. The
109 same mechanism can be used to convey forensic information about the
114Fontana Standards Track [Page 2]
116RFC 6591 Auth Failure Reporting April 2012
119 specific reason the authentication method failed. Thus, this memo
120 presents such extensions to ARF that allow for detailed reporting of
121 message authentication method failures.
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in [KEYWORDS].
1312.2. Email Architecture
133 This memo uses some terms whose definitions and descriptions can be
134 found in [EMAIL-ARCH].
138 Base64 is defined in Section 4 of [BASE64].
140 The values that are base64 encodings MAY contain folding whitespace
141 (FWS) for formatting purposes as per the usual header field wrapping
142 defined in [MAIL]. During decoding, any characters not in the base64
143 alphabet are ignored so that such line wrapping does not harm the
144 value. The ABNF token "FWS" is defined in [DKIM]. No other
145 extensions to the valid base64 character set are permitted.
149 There are technologies in email security that provide authentication
150 services and some that do authorization. These are often conflated.
151 A discussion that is useful for establishing context can be found in
152 Section 1.5.2 of [AUTH-RESULTS].
1543. ARF Extension for Authentication Failure Reporting
156 The current report format defined in [ARF] lacks some specific
157 features required to do effective email authentication failure
158 reporting. This section defines extensions to ARF to accommodate
161 A single report describes a single email authentication failure.
162 Multiple reports MAY be used to report multiple failures for a single
170Fontana Standards Track [Page 3]
172RFC 6591 Auth Failure Reporting April 2012
1753.1. New ARF Feedback Type
177 A new feedback type, "auth-failure", is defined in this document as
178 an extension, per Section 7.3 of [ARF].
180 A message that uses this feedback type has the following modified
181 header field requirements for the second (machine-parseable) [MIME]
184 Authentication-Results: Syntax as specified in [AUTH-RESULTS].
185 Furthermore, [ARF] specifies this field is OPTIONAL and appears at
186 most once; for this extension, this field MUST be present, but it
187 MUST reflect only a single authentication method's result.
189 Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore,
190 [ARF] specifies this field is OPTIONAL and appears at most once;
191 for this extension, this field's inclusion is RECOMMENDED, where
192 that value is available, to aid in diagnosing the authentication
195 Original-Mail-From: Syntax as specified in [ARF]. Furthermore,
196 [ARF] specifies this field is OPTIONAL and appears at most once;
197 for this extension, this field's inclusion is RECOMMENDED, where
198 that value is available, to aid in diagnosing the authentication
201 Source-IP: Syntax as specified in [ARF]. Furthermore, [ARF]
202 specifies this field is OPTIONAL and appears at most once; for
203 this extension, this field's inclusion is RECOMMENDED, where that
204 value is available, to aid in diagnosing the authentication
207 Reported-Domain: Syntax as specified in [ARF]. Furthermore, [ARF]
208 specifies this field is OPTIONAL and appears at most once; for
209 this extension, this field MUST be present if such a value is
212 Delivery-Result: As specified in Section 3.2.2. This field is
213 OPTIONAL, but it MUST NOT appear more than once. If present, it
214 SHOULD indicate the outcome of the message in some meaningful way,
215 but it MAY be set to "other" for local policy reasons.
217 The third MIME part of the message is either of type "message/rfc822"
218 (as defined in [MIME-TYPES]) or of type "text/rfc822-headers" (as
219 defined in [REPORT]) and contains a copy of the entire header block
220 from the original message. This part MUST be included (contrary to
221 [REPORT], which makes it optional).
226Fontana Standards Track [Page 4]
228RFC 6591 Auth Failure Reporting April 2012
231 For privacy reasons, report generators might need to redact portions
232 of a reported message, such as an identifier or address associated
233 with the end user whose complaint action resulted in the report. A
234 discussion of relevant issues and a suggested method for doing so can
235 be found in [RFC6590].
2373.2. New ARF Header Field Names
239 The following new ARF field names are defined as extensions to
240 Section 3.1 of [ARF].
2423.2.1. Required for All Reports
244 Auth-Failure: Indicates the failure from an email authentication
245 method that is being reported. The list of valid values is
246 enumerated in Section 3.3.
2483.2.2. Optional for All Reports
250 Delivery-Result: The final message disposition that was enacted by
251 the ADministrative Management Domain (ADMD) generating the report.
252 It MUST NOT appear more than once. Possible values are as
255 delivered: The message was delivered (not specific as to where).
257 spam: The message was delivered to the recipient's spam folder
260 policy: The message was not delivered to the intended inbox due
261 to a failure from an email authentication method. The specific
262 action taken is not specified.
264 reject: The message was rejected.
266 other: The message had a final disposition not covered by one of
2693.2.3. Required for DKIM Reports
271 DKIM-Domain: The domain that signed the message, taken from the "d="
272 tag of the signature.
274 DKIM-Identity: The identity of the signature that failed
275 verification, taken from the "i=" tag of the signature.
277 DKIM-Selector: The selector of the signature that failed
278 verification, taken from the "s=" tag of the signature.
282Fontana Standards Track [Page 5]
284RFC 6591 Auth Failure Reporting April 2012
2873.2.4. Optional for DKIM Reports
289 DKIM-Canonicalized-Header: A base64 encoding of the canonicalized
290 header of the message as generated by the verifier.
292 DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body
293 of the message as generated by the verifier. The encoded content
294 MUST be limited to those octets that contribute to the DKIM body
295 hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).
297 If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode
298 redacted data, they MUST NOT be included. Otherwise, they SHOULD be
299 included. The data presented there have to be exactly the
300 canonicalized header and body as defined by [DKIM] and computed at
301 the verifier. This is because these fields are intended to aid in
302 identifying message alterations that invalidate DKIM signatures in
303 transit. Including redacted data in them renders the data unusable.
304 (See also Sections 3.1 and 6.6 for further discussion.)
3063.2.5. Required for ADSP Reports
308 DKIM-ADSP-DNS: Includes the Author Domain Signing Practices (ADSP)
309 policy used to obtain the verifier's ADSP result. This MUST be
310 formatted per Section 4.2.1 of [ADSP].
3123.2.6. Required for SPF Reports
314 SPF-DNS: This field MUST appear once for every SPF record [SPF] used
315 to obtain the SPF result. It MUST include the DNS RRTYPE used,
316 the DNS domain from which the record was retrieved, and the
317 content of that record. The syntax is defined in Section 4.
3193.3. Authentication Failure Types
321 The list of defined email authentication failure types used in the
322 "Auth-Failure:" header field (defined above), is as follows:
324 adsp: The message did not conform to the author domain's published
325 [ADSP] signing practices. The DKIM-ADSP-DNS field MUST be
326 included in the report.
328 bodyhash: The body hash in the signature and the body hash computed
329 by the verifier did not match. The DKIM-Canonicalized-Body field
330 SHOULD be included in the report (see Section 3.2.4).
332 revoked: The DKIM key referenced by the signature on the message has
333 been revoked. The DKIM-Domain and DKIM-Selector fields MUST be
334 included in the report.
338Fontana Standards Track [Page 6]
340RFC 6591 Auth Failure Reporting April 2012
343 signature: The DKIM signature on the message did not successfully
344 verify against the header hash and public key. The DKIM-Domain
345 and DKIM-Selector fields MUST be included in the report, and the
346 DKIM-Canonicalized-Header field SHOULD be included in the report
349 spf: The evaluation of the author domain's SPF record produced a
350 "none", "fail", "softfail", "temperror", or "permerror" result.
351 ("none" is not strictly a failure per [SPF], but a service that
352 demands successful SPF evaluations of clients could treat it like
355 Supplementary data MAY be included in the form of comments compliant
356 with [MAIL]. For example, "Auth-Failure: adsp" could be augmented by
357 a comment to indicate that the failed message was rejected because it
358 was not signed when it should have been. See Appendix B for an
3614. Syntax for Added ARF Header Fields
363 The [ABNF] definitions for the new fields are as follows:
365 auth-failure = "Auth-Failure:" [CFWS]
366 ( "adsp" / "bodyhash" / "revoked" /
367 "signature" / "spf" ) [CFWS] CRLF
368 ; "CFWS" is defined in [MAIL]
370 delivery-result = "Delivery-Result:" [CFWS]
371 ( "delivered" / "spam" / "policy" /
372 "reject" / "other" ) [CFWS] CRLF
374 dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
376 ; "base64string" is defined in [DKIM]
378 dkim-sig-domain = "DKIM-Domain:" [CFWS] domain-name [CFWS]
380 ; "domain-name" is defined in [DKIM]
382 dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
383 domain-name [CFWS] CRLF
384 ; "local-part" is defined in [MAIL]
386 dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF
387 ; "selector" is defined in [DKIM]
394Fontana Standards Track [Page 7]
396RFC 6591 Auth Failure Reporting April 2012
399 dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
400 quoted-string [CFWS] CRLF
401 ; "quoted-string" is defined in [MAIL]
403 dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
406 dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
407 quoted-string [CFWS] CRLF
409 spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
410 domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF
4125. IANA Considerations
414 As required by [IANA], this section contains registry information for
415 the extension to [ARF].
4175.1. Updates to ARF Feedback Types
419 The following feedback type has been added to the Feedback Report
420 Type Values registry:
422 Feedback Type: auth-failure
423 Description: email authentication failure report
424 Published in: [RFC6591]
4275.2. Updates to ARF Header Field Names
429 The following headers are added to the Feedback Report Header Fields
432 Field Name: Auth-Failure
433 Description: Type of email authentication method failure
434 Multiple Appearances: No
435 Related "Feedback-Type": auth-failure
436 Published in: [RFC6591]
439 Field Name: Delivery-Result
440 Description: Final disposition of the subject message
441 Multiple Appearances: No
442 Related "Feedback-Type": auth-failure
443 Published in: [RFC6591]
450Fontana Standards Track [Page 8]
452RFC 6591 Auth Failure Reporting April 2012
455 Field Name: DKIM-ADSP-DNS
456 Description: Retrieved DKIM ADSP record
457 Multiple Appearances: No
458 Related "Feedback-Type": auth-failure
459 Published in: [RFC6591]
462 Field Name: DKIM-Canonicalized-Body
463 Description: Canonicalized body, per DKIM
464 Multiple Appearances: No
465 Related "Feedback-Type": auth-failure
466 Published in: [RFC6591]
469 Field Name: DKIM-Canonicalized-Header
470 Description: Canonicalized header, per DKIM
471 Multiple Appearances: No
472 Related "Feedback-Type": auth-failure
473 Published in: [RFC6591]
476 Field Name: DKIM-Domain
477 Description: DKIM signing domain from "d=" tag
478 Multiple Appearances: No
479 Related "Feedback-Type": auth-failure
480 Published in: [RFC6591]
483 Field Name: DKIM-Identity
484 Description: Identity from DKIM signature
485 Multiple Appearances: No
486 Related "Feedback-Type": auth-failure
487 Published in: [RFC6591]
490 Field Name: DKIM-Selector
491 Description: Selector from DKIM signature
492 Multiple Appearances: No
493 Related "Feedback-Type": auth-failure
494 Published in: [RFC6591]
497 Field Name: DKIM-Selector-DNS
498 Description: Retrieved DKIM key record
499 Multiple Appearances: No
500 Related "Feedback-Type": auth-failure
501 Published in: [RFC6591]
506Fontana Standards Track [Page 9]
508RFC 6591 Auth Failure Reporting April 2012
512 Description: Retrieved SPF record
513 Multiple Appearances: No
514 Related "Feedback-Type": auth-failure
515 Published in: [RFC6591]
5186. Security Considerations
520 Security issues with respect to these reports are similar to those
5236.1. Inherited Considerations
525 Implementers are advised to consider the Security Considerations
526 sections of [DKIM], [ADSP], [SPF], and [ARF].
530 These reports can be forged as easily as ordinary Internet electronic
531 mail. User agents and automatic mail-handling facilities (such as
532 mail distribution list exploders) that wish to make automatic use of
533 Delivery Status Notifications (DSNs) of any kind should take
534 appropriate precautions to minimize the potential damage from denial-
537 Security threats related to forged DSNs include the sending of
539 a. A falsified email authentication method failure notification when
540 the message was in fact delivered to the indicated recipient;
542 b. Falsified signature information, such as selector, domain, etc.
544 Perhaps the simplest means of mitigating this threat is to assert
545 that these reports should themselves be signed with something like
546 DKIM. On the other hand, if there's a problem with the DKIM
547 infrastructure at the verifier, signing DKIM failure reports might
548 produce reports that aren't trusted or even accepted by their
562Fontana Standards Track [Page 10]
564RFC 6591 Auth Failure Reporting April 2012
5676.3. Automatic Generation
569 Automatic generation of these reports by verifying agents can cause a
570 denial-of-service attack when a large volume of email is sent that
571 causes email authentication failures for whatever reason.
573 Limiting the rate of generation of these messages might be
574 appropriate but threatens to inhibit the distribution of important
575 and possibly time-sensitive information.
577 In general ARF feedback loop terms, it is suggested that report
578 generators only create these (or any) ARF reports after an out-of-
579 band arrangement has been made between two parties. This mechanism
580 then becomes a way to adjust parameters of an authorized abuse report
581 feedback loop that is configured and activated by private agreement
582 rather than starting to send them automatically based solely on
583 discovered data in the DNS.
5856.4. Envelope Sender Selection
587 In the case of transmitted reports in the form of a new message, it
588 is necessary to consider the construction and transmission of the
589 message so as to avoid amplification attacks, deliberate or
590 otherwise. See Section 5 of [ARF] for further information.
5926.5. Reporting Multiple Incidents
594 If it is known that a particular host generates abuse reports upon
595 certain incidents, an attacker could forge a high volume of messages
596 that will trigger such a report. The recipient of the report could
597 then be inundated with reports. This could easily be extended to a
598 distributed denial-of-service attack by finding a number of report-
601 The incident count referenced in [ARF] provides a limited form of
602 mitigation. The host generating reports may elect to send reports
603 only periodically, with each report representing a number of
604 identical or near-identical incidents. One might even do something
605 inverse-exponentially, sending reports for each of the first ten
606 incidents, then every tenth incident up to 100, then every 100th
607 incident up to 1000, etc., until some period of relative quiet after
608 which the limitation resets.
610 The use of this technique for "near-identical" incidents in
611 particular causes a degradation in reporting quality, however. If,
612 for example, a large number of pieces of spam arrive from one
613 attacker, a reporting agent might decide only to send a report about
618Fontana Standards Track [Page 11]
620RFC 6591 Auth Failure Reporting April 2012
623 a fraction of those messages. While this averts a flood of reports
624 to a system administrator, the precise details of each incident are
6276.6. Redaction of Data in DKIM Reports
629 This memo requires that the canonicalized header and body be returned
630 without being subject to redaction when a DKIM failure is being
631 reported. This is necessary to ensure that the returned
632 canonicalized forms are useful for debugging, as they must be
633 compared to the equivalent form at the signer. If a message is
634 altered in transit, and the returned data are also redacted, the
635 redacted portion and the altered portion may overlap, rendering the
636 comparison results meaningless. However, unredacted data can leak
637 information the reporting entity considers to be private. It is for
638 this reason the return of the canonicalized forms is not required.
6427.1. Normative References
644 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
645 Syntax Specifications: ABNF", STD 68, RFC 5234,
648 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine,
649 "DomainKeys Identified Mail (DKIM) Author Domain Signing
650 Practices (ADSP)", RFC 5617, August 2009.
652 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
653 Extensible Format for Email Feedback Reports", RFC 5965,
657 Kucherawy, M., "Message Header Field for Indicating
658 Message Authentication Status", RFC 5451, April 2009.
660 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
661 Encodings", RFC 4648, October 2006.
663 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
664 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
667 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
668 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
674Fontana Standards Track [Page 12]
676RFC 6591 Auth Failure Reporting April 2012
679 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
680 Requirement Levels", BCP 14, RFC 2119, March 1997.
682 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
685 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
686 Extensions (MIME) Part One: Format of Internet Message
687 Bodies", RFC 2045, November 1996.
690 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
691 Extensions (MIME) Part Two: Media Types", RFC 2046,
694 [REPORT] Kucherawy, M., Ed., "The Multipart/Report Media Type for
695 the Reporting of Mail System Administrative Messages",
696 STD 73, RFC 6522, January 2012.
698 [RFC6590] Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of
699 Potentially Sensitive Data from Mail Abuse Reports",
700 RFC 6590, April 2012.
702 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
703 for Authorizing Use of Domains in E-Mail, Version 1",
704 RFC 4408, April 2006.
7067.2. Informative References
708 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
709 for Delivery Status Notifications", RFC 3464,
713 Crocker, D., "Internet Mail Architecture", RFC 5598,
730Fontana Standards Track [Page 13]
732RFC 6591 Auth Failure Reporting April 2012
735Appendix A. Acknowledgements
737 The author wishes to acknowledge the following for their review and
738 constructive criticism of this proposal: Frank Ellermann, J.D. Falk,
739 Scott Kitterman, John Levine, Mike Markley, Kelly Wanser, Murray
740 Kucherawy, and Alessandro Vesely.
744 This section contains an example of the use of the extension defined
747B.1. Example Use of ARF Extension Headers
749 An ARF-formatted report using the proposed ARF extension fields:
751 Message-ID: <433689.81121.example@mta.mail.receiver.example>
752 From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
753 To: arf-failure@sender.example
754 Subject: FW: You have a new bill from your bank
755 Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
757 Content-Type: multipart/report;
758 boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
759 report-type=feedback-report
760 Content-Transfer-Encoding: 7bit
762 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
763 Content-Type: text/plain; charset="us-ascii"
764 Content-Disposition: inline
765 Content-Transfer-Encoding: 7bit
767 This is an authentication failure report for an email message
768 received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT).
769 For more information about this format, please see [RFC6591].
771 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
772 Content-Type: message/feedback-report
773 Content-Transfer-Encoding: 7bit
775 Feedback-Type: auth-failure
776 User-Agent: Someisp!Mail-Feedback/1.0
778 Original-Mail-From: anexample.reply@a.sender.example
779 Original-Envelope-Id: o3F52gxO029144
780 Authentication-Results: mta1011.mail.tp2.receiver.example;
781 dkim=fail (bodyhash) header.d=sender.example
782 Auth-Failure: bodyhash
786Fontana Standards Track [Page 14]
788RFC 6591 Auth Failure Reporting April 2012
791 DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0
792 aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU
793 gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH
794 RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI
795 HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu
796 ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l
797 uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG
798 NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb
799 GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw
800 bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN
801 pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH
802 BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K
803 DKIM-Domain: sender.example
804 DKIM-Identity: @sender.example
805 DKIM-Selector: testkey
806 Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT)
808 Reported-Domain: a.sender.example
809 Reported-URI: http://www.sender.example/
811 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
812 Content-Type: text/rfc822-headers
813 Content-Transfer-Encoding: 7bit
815 Authentication-Results: mta1011.mail.tp2.receiver.example;
816 dkim=fail (bodyhash) header.d=sender.example;
817 spf=pass smtp.mailfrom=anexample.reply@a.sender.example
818 Received: from smtp-out.sender.example
819 by mta1011.mail.tp2.receiver.example
820 with SMTP id oB85W8xV000169;
821 Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
822 DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
823 s=testkey; d=sender.example; h=From:To:Subject:Date;
824 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
825 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
826 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
827 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
829 Received: from mail.sender.example
830 by smtp-out.sender.example
831 with SMTP id o3F52gxO029144;
832 Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
833 Received: from internal-client-001.sender.example
834 by mail.sender.example
835 with SMTP id o3F3BwdY028431;
836 Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
837 Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
838 Reply-To: anexample.reply@a.sender.example
842Fontana Standards Track [Page 15]
844RFC 6591 Auth Failure Reporting April 2012
847 From: anexample@a.sender.example
848 To: someuser@receiver.example
849 Subject: You have a new bill from your bank
850 Message-ID: <87913910.1318094604546@out.sender.example>
852 --------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--
854 Example 1: Example ARF Report Using These Extensions
856 This example ARF message is making the following assertion:
858 o DKIM verification of the signature added within "sender.example"
861 o The cause of the verification failure was a mismatch between the
862 body contents observed at the verifier and the body hash contained
868 3579 E. Foothill Blvd., Suite 282
872 Phone: +1 626 676 8852
873 EMail: hilda@hfontana.com
898Fontana Standards Track [Page 16]