GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6591

Internet Engineering Task Force (IETF) H. Fontana Request for Comments: 6591 April 2012 Category: Standards Track ISSN: 2070-1721

 Authentication Failure Reporting Using the Abuse Reporting Format

Abstract

 This memo registers an extension report type for the Abuse Reporting
 Format (ARF), affecting multiple registries, for use in generating
 receipt-time reports about messages that fail one or more email
 message authentication checks.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6591.

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Fontana Standards Track [Page 1] RFC 6591 Auth Failure Reporting April 2012

Table of Contents

 1. Introduction ....................................................2
 2. Definitions .....................................................3
    2.1. Key Words ..................................................3
    2.2. Email Architecture .........................................3
    2.3. Base64 .....................................................3
    2.4. Technologies ...............................................3
 3. ARF Extension for Authentication Failure Reporting ..............3
    3.1. New ARF Feedback Type ......................................4
    3.2. New ARF Header Field Names .................................5
         3.2.1. Required for All Reports ............................5
         3.2.2. Optional for All Reports ............................5
         3.2.3. Required for DKIM Reports ...........................5
         3.2.4. Optional for DKIM Reports ...........................6
         3.2.5. Required for ADSP Reports ...........................6
         3.2.6. Required for SPF Reports ............................6
    3.3. Authentication Failure Types ...............................6
 4. Syntax for Added ARF Header Fields ..............................7
 5. IANA Considerations .............................................8
    5.1. Updates to ARF Feedback Types ..............................8
    5.2. Updates to ARF Header Field Names ..........................8
 6. Security Considerations ........................................10
    6.1. Inherited Considerations ..................................10
    6.2. Forgeries .................................................10
    6.3. Automatic Generation ......................................11
    6.4. Envelope Sender Selection .................................11
    6.5. Reporting Multiple Incidents ..............................11
    6.6. Redaction of Data in DKIM Reports .........................12
 7. References .....................................................12
    7.1. Normative References ......................................12
    7.2. Informative References ....................................13
 Appendix A. Acknowledgements ......................................14
 Appendix B. Example ...............................................14
   B.1. Example Use of ARF Extension Headers .......................14

1. Introduction

 The Abuse Reporting Format [ARF] defines a message format for sending
 reports of abuse in the messaging infrastructure, with an eye towards
 automating both the generation and consumption of those reports.
 There is now also a desire to extend the ARF to include the reporting
 of messages that fail to authenticate using known message
 authentication methods, such as DomainKeys Identified Mail [DKIM] and
 Sender Policy Framework [SPF], as these are sometimes evidence of
 abuse that can be detected and reported through automated means.  The
 same mechanism can be used to convey forensic information about the

Fontana Standards Track [Page 2] RFC 6591 Auth Failure Reporting April 2012

 specific reason the authentication method failed.  Thus, this memo
 presents such extensions to ARF that allow for detailed reporting of
 message authentication method failures.

2. Definitions

2.1. Key Words

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [KEYWORDS].

2.2. Email Architecture

 This memo uses some terms whose definitions and descriptions can be
 found in [EMAIL-ARCH].

2.3. Base64

 Base64 is defined in Section 4 of [BASE64].
 The values that are base64 encodings MAY contain folding whitespace
 (FWS) for formatting purposes as per the usual header field wrapping
 defined in [MAIL].  During decoding, any characters not in the base64
 alphabet are ignored so that such line wrapping does not harm the
 value.  The ABNF token "FWS" is defined in [DKIM].  No other
 extensions to the valid base64 character set are permitted.

2.4. Technologies

 There are technologies in email security that provide authentication
 services and some that do authorization.  These are often conflated.
 A discussion that is useful for establishing context can be found in
 Section 1.5.2 of [AUTH-RESULTS].

3. ARF Extension for Authentication Failure Reporting

 The current report format defined in [ARF] lacks some specific
 features required to do effective email authentication failure
 reporting.  This section defines extensions to ARF to accommodate
 this requirement.
 A single report describes a single email authentication failure.
 Multiple reports MAY be used to report multiple failures for a single
 message.

Fontana Standards Track [Page 3] RFC 6591 Auth Failure Reporting April 2012

3.1. New ARF Feedback Type

 A new feedback type, "auth-failure", is defined in this document as
 an extension, per Section 7.3 of [ARF].
 A message that uses this feedback type has the following modified
 header field requirements for the second (machine-parseable) [MIME]
 part of the report:
 Authentication-Results:  Syntax as specified in [AUTH-RESULTS].
    Furthermore, [ARF] specifies this field is OPTIONAL and appears at
    most once; for this extension, this field MUST be present, but it
    MUST reflect only a single authentication method's result.
 Original-Envelope-Id:  Syntax as specified in [ARF].  Furthermore,
    [ARF] specifies this field is OPTIONAL and appears at most once;
    for this extension, this field's inclusion is RECOMMENDED, where
    that value is available, to aid in diagnosing the authentication
    failure.
 Original-Mail-From:  Syntax as specified in [ARF].  Furthermore,
    [ARF] specifies this field is OPTIONAL and appears at most once;
    for this extension, this field's inclusion is RECOMMENDED, where
    that value is available, to aid in diagnosing the authentication
    failure.
 Source-IP:  Syntax as specified in [ARF].  Furthermore, [ARF]
    specifies this field is OPTIONAL and appears at most once; for
    this extension, this field's inclusion is RECOMMENDED, where that
    value is available, to aid in diagnosing the authentication
    failure.
 Reported-Domain:  Syntax as specified in [ARF].  Furthermore, [ARF]
    specifies this field is OPTIONAL and appears at most once; for
    this extension, this field MUST be present if such a value is
    available.
 Delivery-Result:  As specified in Section 3.2.2.  This field is
    OPTIONAL, but it MUST NOT appear more than once.  If present, it
    SHOULD indicate the outcome of the message in some meaningful way,
    but it MAY be set to "other" for local policy reasons.
 The third MIME part of the message is either of type "message/rfc822"
 (as defined in [MIME-TYPES]) or of type "text/rfc822-headers" (as
 defined in [REPORT]) and contains a copy of the entire header block
 from the original message.  This part MUST be included (contrary to
 [REPORT], which makes it optional).

Fontana Standards Track [Page 4] RFC 6591 Auth Failure Reporting April 2012

 For privacy reasons, report generators might need to redact portions
 of a reported message, such as an identifier or address associated
 with the end user whose complaint action resulted in the report.  A
 discussion of relevant issues and a suggested method for doing so can
 be found in [RFC6590].

3.2. New ARF Header Field Names

 The following new ARF field names are defined as extensions to
 Section 3.1 of [ARF].

3.2.1. Required for All Reports

 Auth-Failure:  Indicates the failure from an email authentication
    method that is being reported.  The list of valid values is
    enumerated in Section 3.3.

3.2.2. Optional for All Reports

 Delivery-Result:  The final message disposition that was enacted by
    the ADministrative Management Domain (ADMD) generating the report.
    It MUST NOT appear more than once.  Possible values are as
    follows:
    delivered:  The message was delivered (not specific as to where).
    spam:  The message was delivered to the recipient's spam folder
       (or equivalent).
    policy:  The message was not delivered to the intended inbox due
       to a failure from an email authentication method.  The specific
       action taken is not specified.
    reject:  The message was rejected.
    other:  The message had a final disposition not covered by one of
       the above values.

3.2.3. Required for DKIM Reports

 DKIM-Domain:  The domain that signed the message, taken from the "d="
    tag of the signature.
 DKIM-Identity:  The identity of the signature that failed
    verification, taken from the "i=" tag of the signature.
 DKIM-Selector:  The selector of the signature that failed
    verification, taken from the "s=" tag of the signature.

Fontana Standards Track [Page 5] RFC 6591 Auth Failure Reporting April 2012

3.2.4. Optional for DKIM Reports

 DKIM-Canonicalized-Header:  A base64 encoding of the canonicalized
    header of the message as generated by the verifier.
 DKIM-Canonicalized-Body:  A base64 encoding of the canonicalized body
    of the message as generated by the verifier.  The encoded content
    MUST be limited to those octets that contribute to the DKIM body
    hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).
 If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode
 redacted data, they MUST NOT be included.  Otherwise, they SHOULD be
 included.  The data presented there have to be exactly the
 canonicalized header and body as defined by [DKIM] and computed at
 the verifier.  This is because these fields are intended to aid in
 identifying message alterations that invalidate DKIM signatures in
 transit.  Including redacted data in them renders the data unusable.
 (See also Sections 3.1 and 6.6 for further discussion.)

3.2.5. Required for ADSP Reports

 DKIM-ADSP-DNS:  Includes the Author Domain Signing Practices (ADSP)
    policy used to obtain the verifier's ADSP result.  This MUST be
    formatted per Section 4.2.1 of [ADSP].

3.2.6. Required for SPF Reports

 SPF-DNS:  This field MUST appear once for every SPF record [SPF] used
    to obtain the SPF result.  It MUST include the DNS RRTYPE used,
    the DNS domain from which the record was retrieved, and the
    content of that record.  The syntax is defined in Section 4.

3.3. Authentication Failure Types

 The list of defined email authentication failure types used in the
 "Auth-Failure:" header field (defined above), is as follows:
 adsp:  The message did not conform to the author domain's published
    [ADSP] signing practices.  The DKIM-ADSP-DNS field MUST be
    included in the report.
 bodyhash:  The body hash in the signature and the body hash computed
    by the verifier did not match.  The DKIM-Canonicalized-Body field
    SHOULD be included in the report (see Section 3.2.4).
 revoked:  The DKIM key referenced by the signature on the message has
    been revoked.  The DKIM-Domain and DKIM-Selector fields MUST be
    included in the report.

Fontana Standards Track [Page 6] RFC 6591 Auth Failure Reporting April 2012

 signature:  The DKIM signature on the message did not successfully
    verify against the header hash and public key.  The DKIM-Domain
    and DKIM-Selector fields MUST be included in the report, and the
    DKIM-Canonicalized-Header field SHOULD be included in the report
    (see Section 3.2.4).
 spf:  The evaluation of the author domain's SPF record produced a
    "none", "fail", "softfail", "temperror", or "permerror" result.
    ("none" is not strictly a failure per [SPF], but a service that
    demands successful SPF evaluations of clients could treat it like
    a failure.)
 Supplementary data MAY be included in the form of comments compliant
 with [MAIL].  For example, "Auth-Failure: adsp" could be augmented by
 a comment to indicate that the failed message was rejected because it
 was not signed when it should have been.  See Appendix B for an
 example.

4. Syntax for Added ARF Header Fields

 The [ABNF] definitions for the new fields are as follows:
   auth-failure = "Auth-Failure:" [CFWS]
                  ( "adsp" / "bodyhash" / "revoked" /
                    "signature" / "spf" ) [CFWS] CRLF
                ; "CFWS" is defined in [MAIL]
   delivery-result = "Delivery-Result:" [CFWS]
                     ( "delivered" / "spam" / "policy" /
                       "reject" / "other" ) [CFWS] CRLF
   dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
                 base64string CRLF
               ; "base64string" is defined in [DKIM]
   dkim-sig-domain = "DKIM-Domain:" [CFWS] domain-name [CFWS]
                     CRLF
                   ; "domain-name" is defined in [DKIM]
   dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
                   domain-name [CFWS] CRLF
                 ; "local-part" is defined in [MAIL]
   dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF
                 ; "selector" is defined in [DKIM]

Fontana Standards Track [Page 7] RFC 6591 Auth Failure Reporting April 2012

   dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
                   quoted-string [CFWS] CRLF
                 ; "quoted-string" is defined in [MAIL]
   dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
               base64string CRLF
   dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
                       quoted-string [CFWS] CRLF
   spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
             domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF

5. IANA Considerations

 As required by [IANA], this section contains registry information for
 the extension to [ARF].

5.1. Updates to ARF Feedback Types

 The following feedback type has been added to the Feedback Report
 Type Values registry:
     Feedback Type: auth-failure
     Description: email authentication failure report
     Published in: [RFC6591]
     Status: current

5.2. Updates to ARF Header Field Names

 The following headers are added to the Feedback Report Header Fields
 registry:
     Field Name: Auth-Failure
     Description: Type of email authentication method failure
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: Delivery-Result
     Description: Final disposition of the subject message
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current

Fontana Standards Track [Page 8] RFC 6591 Auth Failure Reporting April 2012

     Field Name: DKIM-ADSP-DNS
     Description: Retrieved DKIM ADSP record
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Canonicalized-Body
     Description: Canonicalized body, per DKIM
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Canonicalized-Header
     Description: Canonicalized header, per DKIM
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Domain
     Description: DKIM signing domain from "d=" tag
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Identity
     Description: Identity from DKIM signature
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Selector
     Description: Selector from DKIM signature
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current
     Field Name: DKIM-Selector-DNS
     Description: Retrieved DKIM key record
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current

Fontana Standards Track [Page 9] RFC 6591 Auth Failure Reporting April 2012

     Field Name: SPF-DNS
     Description: Retrieved SPF record
     Multiple Appearances: No
     Related "Feedback-Type": auth-failure
     Published in: [RFC6591]
     Status: current

6. Security Considerations

 Security issues with respect to these reports are similar to those
 found in [DSN].

6.1. Inherited Considerations

 Implementers are advised to consider the Security Considerations
 sections of [DKIM], [ADSP], [SPF], and [ARF].

6.2. Forgeries

 These reports can be forged as easily as ordinary Internet electronic
 mail.  User agents and automatic mail-handling facilities (such as
 mail distribution list exploders) that wish to make automatic use of
 Delivery Status Notifications (DSNs) of any kind should take
 appropriate precautions to minimize the potential damage from denial-
 of-service attacks.
 Security threats related to forged DSNs include the sending of
 a.  A falsified email authentication method failure notification when
     the message was in fact delivered to the indicated recipient;
 b.  Falsified signature information, such as selector, domain, etc.
 Perhaps the simplest means of mitigating this threat is to assert
 that these reports should themselves be signed with something like
 DKIM.  On the other hand, if there's a problem with the DKIM
 infrastructure at the verifier, signing DKIM failure reports might
 produce reports that aren't trusted or even accepted by their
 intended recipients.

Fontana Standards Track [Page 10] RFC 6591 Auth Failure Reporting April 2012

6.3. Automatic Generation

 Automatic generation of these reports by verifying agents can cause a
 denial-of-service attack when a large volume of email is sent that
 causes email authentication failures for whatever reason.
 Limiting the rate of generation of these messages might be
 appropriate but threatens to inhibit the distribution of important
 and possibly time-sensitive information.
 In general ARF feedback loop terms, it is suggested that report
 generators only create these (or any) ARF reports after an out-of-
 band arrangement has been made between two parties.  This mechanism
 then becomes a way to adjust parameters of an authorized abuse report
 feedback loop that is configured and activated by private agreement
 rather than starting to send them automatically based solely on
 discovered data in the DNS.

6.4. Envelope Sender Selection

 In the case of transmitted reports in the form of a new message, it
 is necessary to consider the construction and transmission of the
 message so as to avoid amplification attacks, deliberate or
 otherwise.  See Section 5 of [ARF] for further information.

6.5. Reporting Multiple Incidents

 If it is known that a particular host generates abuse reports upon
 certain incidents, an attacker could forge a high volume of messages
 that will trigger such a report.  The recipient of the report could
 then be inundated with reports.  This could easily be extended to a
 distributed denial-of-service attack by finding a number of report-
 generating servers.
 The incident count referenced in [ARF] provides a limited form of
 mitigation.  The host generating reports may elect to send reports
 only periodically, with each report representing a number of
 identical or near-identical incidents.  One might even do something
 inverse-exponentially, sending reports for each of the first ten
 incidents, then every tenth incident up to 100, then every 100th
 incident up to 1000, etc., until some period of relative quiet after
 which the limitation resets.
 The use of this technique for "near-identical" incidents in
 particular causes a degradation in reporting quality, however.  If,
 for example, a large number of pieces of spam arrive from one
 attacker, a reporting agent might decide only to send a report about

Fontana Standards Track [Page 11] RFC 6591 Auth Failure Reporting April 2012

 a fraction of those messages.  While this averts a flood of reports
 to a system administrator, the precise details of each incident are
 similarly not sent.

6.6. Redaction of Data in DKIM Reports

 This memo requires that the canonicalized header and body be returned
 without being subject to redaction when a DKIM failure is being
 reported.  This is necessary to ensure that the returned
 canonicalized forms are useful for debugging, as they must be
 compared to the equivalent form at the signer.  If a message is
 altered in transit, and the returned data are also redacted, the
 redacted portion and the altered portion may overlap, rendering the
 comparison results meaningless.  However, unredacted data can leak
 information the reporting entity considers to be private.  It is for
 this reason the return of the canonicalized forms is not required.

7. References

7.1. Normative References

 [ABNF]     Crocker, D., Ed., and P. Overell, "Augmented BNF for
            Syntax Specifications: ABNF", STD 68, RFC 5234,
            January 2008.
 [ADSP]     Allman, E., Fenton, J., Delany, M., and J. Levine,
            "DomainKeys Identified Mail (DKIM) Author Domain Signing
            Practices (ADSP)", RFC 5617, August 2009.
 [ARF]      Shafranovich, Y., Levine, J., and M. Kucherawy, "An
            Extensible Format for Email Feedback Reports", RFC 5965,
            August 2010.
 [AUTH-RESULTS]
            Kucherawy, M., "Message Header Field for Indicating
            Message Authentication Status", RFC 5451, April 2009.
 [BASE64]   Josefsson, S., "The Base16, Base32, and Base64 Data
            Encodings", RFC 4648, October 2006.
 [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
            "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
            September 2011.
 [IANA]     Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

Fontana Standards Track [Page 12] RFC 6591 Auth Failure Reporting April 2012

 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [MAIL]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
            October 2008.
 [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
            Extensions (MIME) Part One: Format of Internet Message
            Bodies", RFC 2045, November 1996.
 [MIME-TYPES]
            Freed, N. and N. Borenstein, "Multipurpose Internet Mail
            Extensions (MIME) Part Two: Media Types", RFC 2046,
            November 1996.
 [REPORT]   Kucherawy, M., Ed., "The Multipart/Report Media Type for
            the Reporting of Mail System Administrative Messages",
            STD 73, RFC 6522, January 2012.
 [RFC6590]  Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of
            Potentially Sensitive Data from Mail Abuse Reports",
            RFC 6590, April 2012.
 [SPF]      Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
            for Authorizing Use of Domains in E-Mail, Version 1",
            RFC 4408, April 2006.

7.2. Informative References

 [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
            for Delivery Status Notifications", RFC 3464,
            January 2003.
 [EMAIL-ARCH]
            Crocker, D., "Internet Mail Architecture", RFC 5598,
            July 2009.

Fontana Standards Track [Page 13] RFC 6591 Auth Failure Reporting April 2012

Appendix A. Acknowledgements

 The author wishes to acknowledge the following for their review and
 constructive criticism of this proposal: Frank Ellermann, J.D. Falk,
 Scott Kitterman, John Levine, Mike Markley, Kelly Wanser, Murray
 Kucherawy, and Alessandro Vesely.

Appendix B. Example

 This section contains an example of the use of the extension defined
 by this memo.

B.1. Example Use of ARF Extension Headers

 An ARF-formatted report using the proposed ARF extension fields:
 Message-ID: <433689.81121.example@mta.mail.receiver.example>
 From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
 To: arf-failure@sender.example
 Subject: FW: You have a new bill from your bank
 Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
 MIME-Version: 1.0
 Content-Type: multipart/report;
   boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
   report-type=feedback-report
 Content-Transfer-Encoding: 7bit
  1. ————-Boundary-00=_3BCR4Y7kX93yP9uUPRhg

Content-Type: text/plain; charset="us-ascii"

 Content-Disposition: inline
 Content-Transfer-Encoding: 7bit
 This is an authentication failure report for an email message
 received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT).
 For more information about this format, please see [RFC6591].
  1. ————-Boundary-00=_3BCR4Y7kX93yP9uUPRhg

Content-Type: message/feedback-report

 Content-Transfer-Encoding: 7bit
 Feedback-Type: auth-failure
 User-Agent: Someisp!Mail-Feedback/1.0
 Version: 1
 Original-Mail-From: anexample.reply@a.sender.example
 Original-Envelope-Id: o3F52gxO029144
 Authentication-Results: mta1011.mail.tp2.receiver.example;
  dkim=fail (bodyhash) header.d=sender.example
 Auth-Failure: bodyhash

Fontana Standards Track [Page 14] RFC 6591 Auth Failure Reporting April 2012

 DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0
   aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU
   gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH
   RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI
   HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu
   ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l
   uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG
   NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb
   GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw
   bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN
   pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH
   BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K
 DKIM-Domain: sender.example
 DKIM-Identity: @sender.example
 DKIM-Selector: testkey
 Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT)
 Source-IP: 192.0.2.1
 Reported-Domain: a.sender.example
 Reported-URI: http://www.sender.example/
  1. ————-Boundary-00=_3BCR4Y7kX93yP9uUPRhg

Content-Type: text/rfc822-headers

 Content-Transfer-Encoding: 7bit
 Authentication-Results: mta1011.mail.tp2.receiver.example;
  dkim=fail (bodyhash) header.d=sender.example;
  spf=pass smtp.mailfrom=anexample.reply@a.sender.example
 Received: from smtp-out.sender.example
  by mta1011.mail.tp2.receiver.example
  with SMTP id oB85W8xV000169;
  Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
 DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
  s=testkey; d=sender.example; h=From:To:Subject:Date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
  4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
  KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
  4bmp/YzhwvcubU4=
 Received: from mail.sender.example
  by smtp-out.sender.example
  with SMTP id o3F52gxO029144;
  Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
 Received: from internal-client-001.sender.example
  by mail.sender.example
  with SMTP id o3F3BwdY028431;
  Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
 Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
 Reply-To: anexample.reply@a.sender.example

Fontana Standards Track [Page 15] RFC 6591 Auth Failure Reporting April 2012

 From: anexample@a.sender.example
 To: someuser@receiver.example
 Subject: You have a new bill from your bank
 Message-ID: <87913910.1318094604546@out.sender.example>
  1. ————-Boundary-00=_3BCR4Y7kX93yP9uUPRhg–
 Example 1: Example ARF Report Using These Extensions
 This example ARF message is making the following assertion:
 o  DKIM verification of the signature added within "sender.example"
    failed.
 o  The cause of the verification failure was a mismatch between the
    body contents observed at the verifier and the body hash contained
    in the signature.

Author's Address

 Hilda L. Fontana
 3579 E. Foothill Blvd., Suite 282
 Pasadena, CA  91107
 US
 Phone: +1 626 676 8852
 EMail: hilda@hfontana.com

Fontana Standards Track [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6591.txt · Last modified: 2012/04/13 17:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki