[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kucherawy-dkim-reporting) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6651

MARF Working Group                                          M. Kucherawy
Internet-Draft                                                 Cloudmark
Intended status: Standards Track                              H. Fontana
Expires: July 11, 2011                                     eCert Systems
                                                         January 7, 2011


     Authentication Failure Reporting using the Abuse Report Format
                   draft-ietf-marf-dkim-reporting-01

Abstract

   This memo presents extensions to the Abuse Reporting Format (ARF),
   DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF)
   specifications to allow for detailed reporting of message
   authentication failures in an on-demand fashion.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 11, 2011.

Copyright Notice

   Copyright (c) 2011 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.



Kucherawy & Fontana       Expires July 11, 2011                 [Page 1]

Internet-Draft           Auth Failure Reporting             January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Imported Definitions . . . . . . . . . . . . . . . . . . .  4
   3.  Optional Reporting Address for DKIM  . . . . . . . . . . . . .  5
   4.  Optional Reporting Address for DKIM-ADSP . . . . . . . . . . .  7
   5.  Optional Reporting Address for SPF . . . . . . . . . . . . . .  9
   6.  Requested Reports  . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Requested Reports for DKIM Failures  . . . . . . . . . . . 11
     6.2.  Requested Reports for DKIM ADSP Failures . . . . . . . . . 11
     6.3.  Requested Reports for SPF Failures . . . . . . . . . . . . 11
   7.  Reporting Formats  . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Extension ARF Fields for Authentication Failure Reporting  . . 13
     8.1.  New ARF Feedback Type  . . . . . . . . . . . . . . . . . . 13
     8.2.  New ARF Header Field Names . . . . . . . . . . . . . . . . 14
       8.2.1.  Required For All Reports . . . . . . . . . . . . . . . 14
       8.2.2.  Required For DKIM Reports  . . . . . . . . . . . . . . 14
       8.2.3.  Optional For DKIM Reports  . . . . . . . . . . . . . . 15
       8.2.4.  Optional For SPF Reports . . . . . . . . . . . . . . . 15
     8.3.  Authentication Failure Types . . . . . . . . . . . . . . . 15
   9.  Syntax For Added Fields  . . . . . . . . . . . . . . . . . . . 17
   10. Redacting Data . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     11.1. DKIM Key Tag Registration  . . . . . . . . . . . . . . . . 19
     11.2. DKIM ADSP Tag Registration . . . . . . . . . . . . . . . . 19
     11.3. SPF Tag Registration . . . . . . . . . . . . . . . . . . . 19
     11.4. Updates to ARF Feedback Types  . . . . . . . . . . . . . . 20
     11.5. Updates to ARF Header Field Names  . . . . . . . . . . . . 20
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     12.1. Inherited Considerations . . . . . . . . . . . . . . . . . 23
     12.2. Forgeries  . . . . . . . . . . . . . . . . . . . . . . . . 23
     12.3. Automatic Generation . . . . . . . . . . . . . . . . . . . 23
     12.4. Envelope Sender Selection  . . . . . . . . . . . . . . . . 24
     12.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 24
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     13.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 26
   Appendix B.  Examples  . . . . . . . . . . . . . . . . . . . . . . 27
     B.1.  Example Use of DKIM Key Extension Tags . . . . . . . . . . 27
     B.2.  Example Use of DKIM ADSP Extension Tags  . . . . . . . . . 27
     B.3.  Example Use of ARF Extension Headers . . . . . . . . . . . 28
   Appendix C.  Public Discussion . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31





Kucherawy & Fontana       Expires July 11, 2011                 [Page 2]

Internet-Draft           Auth Failure Reporting             January 2011


1.  Introduction

   [ARF] defines a message format for sending reports of abuse in the
   messaging infrastructure, with an eye toward automating both the
   generating and consumption of those reports.

   [SPF] and [DKIM] introduced mechanisms for message sender
   authentication; the former is "path-based" meaning it authenticates
   the route that a message took from origin to destination, and the
   latter uses digital signing to associate a domain name with a message
   in a reliable (i.e. not forgeable) manner.  In both cases the output
   is a verified domain name that can then be subjected to some sort of
   evaluation process (e.g., comparison to a known-good list, submission
   to a reputation service, etc.).

   Deployers of message sender authentication technologies are
   increasingly seeking visibility into DKIM verification failures,
   unauthorized path traversals (SPF failures), and conformance failures
   involving an ADMD's published signing practices ([ADSP]).

   This document extends [DKIM], [SPF] and [ADSP] to add an optional
   reporting address, an optional means of specifying a desired report
   format and other parameters, and furthermore extends [ARF] to add
   features required for the reporting of these incidents.



























Kucherawy & Fontana       Expires July 11, 2011                 [Page 3]

Internet-Draft           Auth Failure Reporting             January 2011


2.  Definitions

2.1.  Keywords

   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.  Imported Definitions

   The ABNF token "qp-section" is imported from [MIME].

   base64 is defined in [MIME].






































Kucherawy & Fontana       Expires July 11, 2011                 [Page 4]

Internet-Draft           Auth Failure Reporting             January 2011


3.  Optional Reporting Address for DKIM

   A domain name owner employing [DKIM] for e-mail signing and
   authentication might want to know when signatures in use by specific
   keys are not successfully verifying.  Currently there is no such
   mechanism defined.

   This document adds the following optional "tags" (as defined in
   [DKIM]) to the DKIM key records, using the form defined in that
   specification:

   r= Reporting Address (plain-text; OPTIONAL; no default).  The value
      MUST be a dkim-quoted-printable string containing an e-mail
      address to which a report SHOULD be sent when mail signed with
      this key fails verification because either (a) the signature
      verification itself failed, or (b) the body hash test failed.  The
      format of this reply is selected by the value of the "rf=" tag,
      defined below.  If only a local-part is included, then to generate
      a complete address to which the report is sent, the verifier
      simply appends to this value an "@" followed by the domain found
      in the "d=" tag of the signature whose validation failed.

      ABNF:

      key-r-tag = %x72 *WSP "=" *WSP qp-section

   rf=  Reporting Format (plain-text; OPTIONAL; default is "arf").  The
      value MUST be a colon-separated list of tokens representing
      desired reporting formats in order of preference.  Each element of
      the list MUST be a token that is taken from the registered list of
      report formats.  See Section 11 for a description of the registry
      and Section 7 for a description of recognized formats.  The
      verifier generating reports MUST generate a report using the first
      token in the list that represents a report format it is capable of
      generating.

      ABNF:

      rep-format = ( "arf" / "smtp" )

      key-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP
      rep-format )

   ri=  Requested Report Interval (plain-text; OPTIONAL; default is
      "0").  The value is an unsigned 32-bit integer that specifies an
      interval during which the report generator SHOULD NOT issue more
      than one report about a given incident type.  A value of "0"
      requests a report for every incident.  Where the requested



Kucherawy & Fontana       Expires July 11, 2011                 [Page 5]

Internet-Draft           Auth Failure Reporting             January 2011


      interval is not zero, the agent generating a report SHOULD include
      an "Incidents:" field in the generated report so the receiving
      agent has some indication of how many reports were suppressed.

      ABNF:

      key-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT

   ro=  Requested Reports (plain-text; OPTIONAL; default is "all").  The
      value MUST be a colon-separated list of tokens representing those
      conditions under which a report is desired.  See Section 6.1 for a
      list of valid tags.

      ABNF:

      key-ro-type = ( "all" / "s" / "v" / "x" )

      key-ro-tag = %x72 %x6f *WSP "=" *WSP key-ro-type *WSP 0* ( ":"
      *WSP key-ro-type )

   rs=  Requested SMTP Error String (plain-text; OPTIONAL; no default).
      The value is a string the signing domain requests be included in
      [SMTP] error strings when messages are rejected.

      ABNF:

      key-rs-tag = %x72 %x73 *WSP "=" qp-section
























Kucherawy & Fontana       Expires July 11, 2011                 [Page 6]

Internet-Draft           Auth Failure Reporting             January 2011


4.  Optional Reporting Address for DKIM-ADSP

   There also exist cases in which a domain name owner employing [ADSP]
   for announcing signing practises with DKIM may want to know when
   messages are received without valid author domain signatures.
   Currently there is no such mechanism defined.

   This document adds the following optional "tags" (as defined in
   [ADSP]) to the DKIM ADSP records, using the form defined in that
   specification:

   r= Reporting Address (plain-text; OPTIONAL; no default).  The value
      MUST be a dkim-quoted-printable string containing an e-mail
      address to which a report SHOULD be sent when mail claiming to be
      from this domain failed the verification algorithm described in
      [ADSP], in particular because a message arrived without a
      signature that validates, which contradicts what the ADSP record
      claims, the format of this reply MUST be in the format specified
      by the "rf=" tag defined below.  If only a local-part is provided,
      then to generate a complete address to which the report is sent,
      the verifier simply appends to this value an "@" followed by the
      domain whose policy was queried in order to evaluate the sender's
      ADSP.

      ABNF:

      adsp-r-tag = %x72 *WSP "=" qp-section

   rf=  Reporting Format (plain-text; OPTIONAL; default is "arf").  The
      value MUST be a colon-separated list of tokens representing
      desired reporting formats in decreasing order of preference.  Each
      element of the list MUST be a token that is taken from the
      registered list of DKIM report formats.  See Section 11 for a
      description of the registry and Section 7 for a description of
      recognized formats.  The verifier generating reports MUST generate
      a report using the first token in the list that represents a
      report format it is capable of generating.

      ABNF:

      adsp-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP
      rep-format )

   ri=  Requested Report Interval (plain-text; OPTIONAL; default is
      "0").  The value is an unsigned 32-bit integer that specifies an
      interval during which the report generator SHOULD NOT issue more
      than one report about a given type of incident should be
      generated.  A value of "0" requests a report for every incident.



Kucherawy & Fontana       Expires July 11, 2011                 [Page 7]

Internet-Draft           Auth Failure Reporting             January 2011


      Where the requested interval is not zero, the agent generating a
      report SHOULD include an "Incidents:" field in the generated
      report so the receiving agent has some indication of how many
      reports were suppressed.

      ABNF:

      adsp-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT

   ro=  Requested Reports (plain-text; OPTIONAL; default is "all").  The
      value MUST be a colon-separated list of tokens representing those
      conditions under which a report is desired.  See Section 6.2 for a
      list of valid tags.

      ABNF:

      adsp-ro-type = ( "all" / "s" / "u" )

      adsp-ro-tag = %x72 %x6f *WSP "=" *WSP adsp-ro-type *WSP 0* ( ":"
      *WSP adsp-ro-type )

   rs=  Requested SMTP Error String (plain-text; OPTIONAL; no default).
      The value is a string the signing domain requests be included in
      [SMTP] error strings when messages are rejected.

      ABNF:

      adsp-rs-tag = %x72 %x73 *WSP "=" qp-section























Kucherawy & Fontana       Expires July 11, 2011                 [Page 8]

Internet-Draft           Auth Failure Reporting             January 2011


5.  Optional Reporting Address for SPF

   There also exist cases in which a domain name owner employing [SPF]
   for announcing sending practises may want to know when messages are
   received via unauthorized routing.  Currently there is no such
   mechanism defined.

   This document adds the following optional "modifier" (as defined in
   Section 4.6.1 of [SPF]) to SPF records, using the form defined in
   that specification:

   report=  Reporting Address (plain-text; OPTIONAL; no default).  The
      value MUST be a dkim-quoted-printable string containing an e-mail
      address to which a report SHOULD be sent when mail claiming to be
      from this domain failed the SPF evaluation algorithm described in
      [SPF], in particular because a message arrived via an unauthorized
      route.  The format of this reply MUST be in the format specified
      by the "reportform=" tag defined below.  If only a local-part is
      provided, then to generate a complete address to which the report
      is sent, the verifier simply appends to this value an "@" followed
      by the domain whose policy was queried in order to evaluate the
      sender's SPF record.

      ABNF:

      spf-report-tag = "report" *WSP "=" qp-section

   reportform=  Reporting Format (plain-text; OPTIONAL; default is
      "arf").  The value MUST be a colon-separated list of tokens
      representing desired reporting formats in decreasing order of
      preference.  Each element of the list MUST be a token that is
      taken from the registered list of report formats.  See Section 11
      for a description of the registry and Section 7 for a description
      of recognized formats.  The verifier generating reports MUST
      generate a report using the first token in the list that
      represents a report format it is capable of generating.

      ABNF:

      spf-rf-tag = "reportform" *WSP "=" *WSP rep-format *WSP 0*( ":"
      *WSP rep-format )

   reportint=  Requested Report Interval (plain-text; OPTIONAL; default
      is "0").  The value is an unsigned 32-bit integer that specifies
      an interval during which the report generator SHOULD NOT issue
      more than one report about a given type of incident should be
      generated.  A value of "0" requests a report for every incident.
      Where the requested interval is not zero, the agent generating a



Kucherawy & Fontana       Expires July 11, 2011                 [Page 9]

Internet-Draft           Auth Failure Reporting             January 2011


      report SHOULD include an "Incidents:" field in the generated
      report so the receiving agent has some indication of how many
      reports were suppressed.

      ABNF:

      spf-ri-tag = "reportint" *WSP "=" *WSP 1*DIGIT

   reportopts=  Requested Reports (plain-text; OPTIONAL; default is
      "all").  The value MUST be a colon-separated list of tokens
      representing those conditions under which a report is desired.
      See Section 6.3 for a list of valid tags.

      ABNF:

      spf-ro-type = ( "all" / "s" / "f" )

      spf-ro-tag = "reportopts" *WSP "=" *WSP spf-ro-type *WSP 0* ( ":"
      *WSP spf-ro-type )

   reportsmtp=  Requested SMTP Error String (plain-text; OPTIONAL; no
      default).  The value is a string the signing domain requests be
      included in [SMTP] error strings when messages are rejected.

      ABNF:

      spf-rs-tag = "reportsmtp" *WSP "=" qp-section
























Kucherawy & Fontana       Expires July 11, 2011                [Page 10]

Internet-Draft           Auth Failure Reporting             January 2011


6.  Requested Reports

   This memo also includes, as the "ro" tags defined above, the means by
   which the sender can request reports for specific circumstances of
   interest.  Verifiers MUST NOT generate reports for incidents that do
   not match a requested report, and MUST ignore requests for reports
   not included in this these lists.

6.1.  Requested Reports for DKIM Failures

   The following report requests are defined for DKIM keys:

   all  All reports are requested.

   s  Reports are requested for signature or key syntax errors.

   v  Reports are requested for signature verification failures or body
      hash mismatches.

   x  Reports are requested for signatures rejected by the verifier
      because the expiration time has passed.

6.2.  Requested Reports for DKIM ADSP Failures

   The following report requests are defined for ADSP records:

   all  All reports are requested.

   s  Reports are requested for messages that have a valid [DKIM]
      signature but do not match the published [ADSP] policy.

   u  Reports are requested for messages that have no valid [DKIM]
      signature but do not match the published [ADSP] policy.

6.3.  Requested Reports for SPF Failures

   The following report requests are defined for SPF keys:

   all  All reports are requested.

   f  Reports are requested for messages that produced an SPF result of
      "fail".

   s  Reports are requested for messages that produced an SPF result of
      "softfail".






Kucherawy & Fontana       Expires July 11, 2011                [Page 11]

Internet-Draft           Auth Failure Reporting             January 2011


7.  Reporting Formats

   This section lists reporting formats supported by this reporting
   mechanism.  Currently only two formats are supported:

   arf:  Abuse Reporting Format, as defined in [ARF], and as extended in
      Section 8.

   smtp:  An [SMTP] error with a string descriptive of the problem that
      caused the sender authentication to fail.  This explicitly
      requests evaluation of sender authentication concurrent with the
      SMTP session, and rejection (if appropriate) whenever possible
      rather than acceptance of the message and later generation of a
      feedback report of some kind (e.g. "arf" above) when verification
      fails.  The presence of an "rs" tag (see Section 3 and Section 4)
      or "reportsmtp" tag (see Section 5) further requests a specific
      substring be included in the reply to ease automatic handling of
      such errors by sending or relaying MTAs.

































Kucherawy & Fontana       Expires July 11, 2011                [Page 12]

Internet-Draft           Auth Failure Reporting             January 2011


8.  Extension ARF Fields for Authentication Failure Reporting

   The current ARF format defined in [ARF] lacks some specific features
   required to do effective sender authentication reporting.  This
   section describes the extensions required to do so and thus required
   to conform to this specification.

8.1.  New ARF Feedback Type

   A new feedback type of "auth-failure" is defined as an extension to
   Section 8.2 of [ARF].  See Section 8.3 for details.

   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:  This field MUST be formatted as defined in
      [AUTH-RESULTS], except that it MUST include explicit results for
      both DKIM and SPF even if those tests were not actually performed.
      This field MUST appear at least once, and it is RECOMMENDED that
      the corresponding header fields be copied directly from the
      message about which a report is being generated.

   Original-Envelope-Id:  As specified in [ARF].  This field MUST appear
      exactly once.

   Original-Mail-From:  As specified in [ARF].  This field MUST appear
      exactly once.

   Arrival-Date:  As specified in [ARF].  This field MUST appear exactly
      once.

   Source-IP:  As specified in [ARF].  This field MUST appear exactly
      once.  If this information is either not available at the time the
      report is generated, or the generating ADMD's policy requires it
      be redacted, a value of 0.0.0.0 MUST be used.

   Message-ID:  As specified in [ARF].  This field MUST appear exactly
      once.

   Reported-Domain:  As specified in [ARF].  This field MUST appear
      exactly once.

   Delivery-Result:  As specified in Section 8.2.1.  This field MUST
      appear exactly once.

   For privacy reasons, report generators might need to redact portions
   of a reported message such as the end user whose complaint action



Kucherawy & Fontana       Expires July 11, 2011                [Page 13]

Internet-Draft           Auth Failure Reporting             January 2011


   resulted in the report.  See Section 10 for a discussion of this.

8.2.  New ARF Header Field Names

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

   The values that are base64 encodings may contain 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].

8.2.1.  Required For All Reports

   Auth-Failure:  Indicates the type of authentication failure that is
      being reported.  The list of valid values is enumerated below.

   Delivery-Result:  The final message disposition that was enacted by
      the ADMD generating the report.  Possible values are:

      inbox:  The message was delivered to the intended inbox.

      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 authentication failure.  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.

8.2.2.  Required For DKIM Reports

   DKIM-Canonicalized-Header:  A base64 encoding of the canonicalized
      header of the message as generated by the verifier.

   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.






Kucherawy & Fontana       Expires July 11, 2011                [Page 14]

Internet-Draft           Auth Failure Reporting             January 2011


   DKIM-Selector:  The selector of the signature that failed
      verification, taken from the "s=" tag of the signature.

8.2.3.  Optional For DKIM Reports

   DKIM-ADSP-DNS:  The contents of the DNS TXT record retrieved when
      trying to determine the author domain's signing practices via the
      protocol defined in [ADSP].

   DKIM-Canonicalized-Body:  A base64 encoding of the canonicalized body
      of the message as generated by the verifier.  This header and
      value MUST be present for reports using feedback type "dkim" when
      reporting a "bodyhash" failure.

   DKIM-Selector-DNS:  The contents of the DNS TXT record retrieved when
      trying to evaluate the DKIM signature (i.e. a TXT record whose
      name is assembled from the signature's "s=" and "d=" tags).

8.2.4.  Optional For SPF Reports

   SPF-DNS:  The contents of the SPF policy record retrieved from a TXT
      record in the DNS during SPF evaluation.

8.3.  Authentication Failure Types

   The list of defined authentication failure types, used in the "Auth-
   Failure:" header (defined above), is as follows:

   adsp:  The message did not conform to the sender's published [ADSP]
      signing practises.  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.

   granularity:  The DKIM key referenced by the signature on the message
      was not authorized for use by the sender.  The DKIM-Domain and
      DKIM-Selector fields MUST be included in the report, and the DKIM-
      Identity field SHOULD be included.

   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.







Kucherawy & Fontana       Expires July 11, 2011                [Page 15]

Internet-Draft           Auth Failure Reporting             January 2011


   signature:  The DKIM signature on the message did not successfully
      verify against the header hash and public key.  The DKIM-Domain,
      DKIM-Selector and DKIM-Canonicalized-Header fields MUST be
      included in the report.

   spf:  The evaluation of the sending domain's SPF record produced a
      "fail" or "softfail" result.

   Supplementary data may be included in the form of [MAIL]-compliant
   comments.  For example, "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
   examples.






































Kucherawy & Fontana       Expires July 11, 2011                [Page 16]

Internet-Draft           Auth Failure Reporting             January 2011


9.  Syntax For Added Fields

   The ABNF definitions for the new fields are as follows:

       auth-failure = "Auth-Failure:" [CFWS] token [CFWS] CRLF
         ; "token" must be a registered authentication failure type
         ; as specified elsewhere in this memo

       delivery-result = "Delivery-Result:" [CFWS]
                         ( "inbox" / "spam" / "policy" /
                           "reject" / "other" ) [CFWS] CRLF

       dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
                     base64string CRLF
         ; "base64string" is imported from [DKIM]

       dkim-domain = "DKIM-Domain:" [CFWS] domain [CFWS] CRLF

       dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
                       domain-name [CFWS] CRLF
         ; "local-part" is imported from [MAIL]

       dkim-selector = "DKIM-Selector:" [CFWS] token [CFWS] CRLF

       dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
                       quoted-string [CFWS] CRLF
         ; "quoted-string" is imported from [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] quoted-string [CFWS] CRLF
















Kucherawy & Fontana       Expires July 11, 2011                [Page 17]

Internet-Draft           Auth Failure Reporting             January 2011


10.  Redacting Data

   For privacy considerations it might be the policy of a report
   generator to redact, or obscure, portions of the report that might
   identify an end user that caused the report to be generated.
   Precisely how this is done is unspecified in [ARF] as it will
   generally be a matter of local policy.  That specification does
   admonish generators against being too over-zealous with this
   practice, as obscuring too much data makes the report inactionable.

   Previous redaction practices, such as replacing local-parts of
   addresses with a uniform string like "xxxxxxxx", often frustrated any
   kind of prioritizing or grouping of reports.

   Generally, it is assumed that the recipient fields of a message, when
   copied into a report, are to be obscured to protect the identify of
   an end user that submitted a complaint about a message.  However, it
   is also presumed that other data will be left intact, data that could
   be correlated against logs to determine the source of the message
   that drew a complaint.

   To enable correlation of reports that might refer to a common but
   anonymous source, the following redaction practice is recommended:

   1.  Select an arbitrary string that will be used by an ADMD that
       generates reports.  This string will not be changed except
       according to a key rotation policy or similar.  Call this the
       "redaction key".

   2.  Identify string(s) (such as local-parts of email addresses) in a
       message that need to be redacted.  Call this the "private data".

   3.  Construct a new string that is a copy of the redaction key with
       the private data concatenated to it.

   4.  Compute a digest of that string with any hashing/digest algorithm
       such as SHA1.

   5.  Encode that hash with the base64 algorithm as defined in [MIME].

   6.  Replace the private data with the encoded hash when generating
       the report.

   This has the effect of obscuring the data in an irreversible way but
   still allows the report recipient to observe that numerous reports
   are about one particular end user.  Such detection enables the
   receiver to prioritize its reactions based on problems that appear to
   be focused on specific end users that may be under attack.



Kucherawy & Fontana       Expires July 11, 2011                [Page 18]

Internet-Draft           Auth Failure Reporting             January 2011


11.  IANA Considerations

   As required by [IANA-CONSIDERATIONS], this section contains registry
   information for the new [DKIM] key tags, the new [ADSP] tags, the new
   [SPF] tags, and the extensions to [ARF].

11.1.  DKIM Key Tag Registration

   IANA is requested to update the DKIM Key Tag Specification Registry
   to include the following new items:

                           +------+-----------------+
                           | TYPE | REFERENCE       |
                           +------+-----------------+
                           | r    | (this document) |
                           | rf   | (this document) |
                           | ri   | (this document) |
                           | ro   | (this document) |
                           | rs   | (this document) |
                           +------+-----------------+

11.2.  DKIM ADSP Tag Registration

   IANA is requested to update the DKIM ADSP Tag Specification Registry
   to include the following new items:

                           +------+-----------------+
                           | TYPE | REFERENCE       |
                           +------+-----------------+
                           | r    | (this document) |
                           | rf   | (this document) |
                           | ri   | (this document) |
                           | ro   | (this document) |
                           | rs   | (this document) |
                           +------+-----------------+

11.3.  SPF Tag Registration

   IANA is requested to create the Sender Policy Framework Modifier
   Registry, to include a list of all registered SPF modifier names and
   their defining documents.

   New registrations or updates MUST be published in accordance with the
   "Specification Required" guidelines as described in
   [IANA-CONSIDERATIONS].  New registrations and updates MUST contain
   the following information:





Kucherawy & Fontana       Expires July 11, 2011                [Page 19]

Internet-Draft           Auth Failure Reporting             January 2011


   1.  Name of the modifier being registered or updated

   2.  The document in which the specification of the modifier is
       published

   3.  New or updated status, which MUST be one of:

       current:  The field is in current use

       deprecated:  The field is in current use but its use is
          discouraged

       historic:  The field is no longer in current use

   An update may make a notation on an existing registration indicating
   that a registered field is historic or deprecated if appropriate.

                 +------------+-----------------+---------+
                 | MODIFIER   | REFERENCE       | STATUS  |
                 +------------+-----------------+---------+
                 | exp        | RFC4408         | current |
                 | redirect   | RFC4408         | current |
                 | report     | (this document) | current |
                 | reportform | (this document) | current |
                 | reportint  | (this document) | current |
                 | reportopts | (this document) | current |
                 | reportsmtp | (this document) | current |
                 +------------+-----------------+---------+

11.4.  Updates to ARF Feedback Types

   The following feedback type is added to the Feedback Report Feedback
   Type Registry:

       Feedback Type: auth-failure
       Description: sender authentication failure report
       Registration: (this document)

11.5.  Updates to ARF Header Field Names

   The following headers are added to the Feedback Report Header Names
   Registry:

       Field Name: Auth-Failure
       Description: Type of authentication failure
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure




Kucherawy & Fontana       Expires July 11, 2011                [Page 20]

Internet-Draft           Auth Failure Reporting             January 2011


       Field Name: Delivery-Result
       Description: Final disposition of the subject message
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-ADSP-DNS
       Description: Retrieved DKIM ADSP record
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Canonicalized-Body
       Description: Canonicalized body, per DKIM
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Canonicalized-Header
       Description: Canonicalized header, per DKIM
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Domain
       Description: DKIM signing domain from "d=" tag
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Identity
       Description: Identity from DKIM signature
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Selector
       Description: Selector from DKIM signature
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure


       Field Name: DKIM-Selector-DNS
       Description: Retrieved DKIM key record
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure





Kucherawy & Fontana       Expires July 11, 2011                [Page 21]

Internet-Draft           Auth Failure Reporting             January 2011


       Field Name: SPF-DNS
       Description: Retrieved SPF record
       Multiple Appearances: No
       Related "Feedback-Type": auth-failure















































Kucherawy & Fontana       Expires July 11, 2011                [Page 22]

Internet-Draft           Auth Failure Reporting             January 2011


12.  Security Considerations

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

12.1.  Inherited Considerations

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

12.2.  Forgeries

   These reports may 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
   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 authentication 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 may
   produce reports that aren't trusted or even accepted by their
   intended recipients.

12.3.  Automatic Generation

   Automatic generation of these reports by verifying agents can cause a
   denial-of-service attack when a large volume of e-mail is sent that
   causes sender authentication failures for whatever reason.

   Limiting the rate of generation of these messages may 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



Kucherawy & Fontana       Expires July 11, 2011                [Page 23]

Internet-Draft           Auth Failure Reporting             January 2011


   discovered data in the DNS.

12.4.  Envelope Sender Selection

   In the case of transmitted reports in the form of a new message, it
   is necessary to construct the message so as to avoid amplification
   attacks, deliberate or otherwise.  Thus, per Section 2 of [DSN], the
   envelope sender address of the report SHOULD be chosen to ensure that
   no delivery status reports will be issued in response to the report
   itself, and MUST be chosen so that these reports will not generate
   mail loops.  Whenever an [SMTP] transaction is used to send a report,
   the MAIL FROM command MUST use a NULL return address, i.e.  "MAIL
   FROM:<>".

12.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 innundated 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 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
   may decide only to send a report about 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.













Kucherawy & Fontana       Expires July 11, 2011                [Page 24]

Internet-Draft           Auth Failure Reporting             January 2011


13.  References

13.1.  Normative References

   [ADSP]     Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM
              Sender Signing Practises", 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.

   [DKIM]     Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [IANA-CONSIDERATIONS]
              Alvestrand, H. and T. Narten, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226, May 2008.

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [MAIL]     Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [SPF]      Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1",
              RFC 4408, April 2006.

13.2.  Informative References

   [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              January 2003.





Kucherawy & Fontana       Expires July 11, 2011                [Page 25]

Internet-Draft           Auth Failure Reporting             January 2011


Appendix A.  Acknowledgements

   The authors wish to acknowledge the following for their review and
   constructive criticism of this proposal: Monica Chew, Tim Draegen and
   JD Falk.














































Kucherawy & Fontana       Expires July 11, 2011                [Page 26]

Internet-Draft           Auth Failure Reporting             January 2011


Appendix B.  Examples

   This section contains examples of the use of each of the extensions
   defined by this memo.

B.1.  Example Use of DKIM Key Extension Tags

   A DKIM key record including use of the extensions defined by this
   memo:

       v=DKIM1; k=rsa; t=y; r=dkim-errors; rf=arf; ro=v:x; p=MIGfMA0GCS
       qGSIb3DQEBAQUAA4GNADCBiQKBgQDh2vbhJTijCs2qbyJcwRCa8WqDTxI+PisFJo
       faPtoDJy0Qn41uNayCajfKADVcLqc87sXQS6GxfchPfzx7Vh9crYdxRbN/o/URCu
       ZsKmym1i1IPTwRLcXSnuKS0XDs1eRW2WQHGYlXksUDqSHWOS3ZO1W5t/FLcZHpIl
       l/80xs4QIDAQAB

   Example 1: DKIM key record using these extensions

   This example DKIM key record contains the following data in addition
   to the basic DKIM key data:

   o  Reports about signature evaluation failures should be send to the
      address "dkim-errors" at the sender's domain;

   o  The sender's domain requests reports in the "arf" format;

   o  Only reports about signature verification failures and expired
      signatures should be generated.

B.2.  Example Use of DKIM ADSP Extension Tags

   A DKIM ADSP record including use of the extensions defined by this
   memo:

       dkim=all; r=dkim-adsp-errors; rf=arf; ro=u

   Example 2: DKIM ADSP record using these extensions

   This example ADSP record makes the following assertions:

   o  The sending domain (i.e. the one that is advertising this policy)
      signs all mail it sends;

   o  Reports about ADSP evaluation failures should be send to the
      address "dkim-adsp-errors" at the sender's domain;

   o  The sender's domain requests reports in the "arf" format;




Kucherawy & Fontana       Expires July 11, 2011                [Page 27]

Internet-Draft           Auth Failure Reporting             January 2011


   o  Only reports about unsigned messages should be generated.

B.3.  Example Use of ARF Extension Headers

   An ARF-formatted report using some of the proposed ARF extension
   fields:

       From: arf-daemon@example.com
       To: recipient@example.net
       Subject: This is a test
       Date: Wed, 14 Apr 2010 12:17:45 -0700 (PDT)
       MIME-Version: 1.0
       Content-Type: multipart/report; report-type=feedback-report;
           boundary="part1_13d.2e68ed54_boundary"

       --part1_13d.2e68ed54_boundary
       Content-Type: text/plain; charset="US-ASCII"
       Content-Transfer-Encoding: 7bit

       This is an email abuse report for an email message received
       from IP 192.0.2.1 on Wed, 14 Apr 2010 12:15:31 PDT. For more
       information about this format please see
       http://www.mipassoc.org/arf/.

       --part1_13d.2e68ed54_boundary
       Content-Type: message/feedback-report

       Feedback-Type: auth-failure
       User-Agent: SomeDKIMFilter/1.0
       Version: 1.0
       Original-Mail-From: <randomuser@example.net>
       Original-Rcpt-To: <user@example.com>
       Received-Date: Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
       Source-IP: 192.0.2.1
       Authentication-Results: mail.example.com; dkim=fail
           header.d=example.net
       Reported-Domain: example.net
       DKIM-Domain: example.net
       DKIM-Failure: bodyhash

       --part1_13d.2e68ed54_boundary
       Content-Type: message/rfc822

       DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
           s=testkey; d=example.net; h=From:To:Subject:Date;
           bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
           b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
            4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut



Kucherawy & Fontana       Expires July 11, 2011                [Page 28]

Internet-Draft           Auth Failure Reporting             January 2011


            KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
            4bmp/YzhwvcubU4=
       Received: from smtp-out.example.net by mail.example.com
           with SMTP id o3F52gxO029144;
           Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
       Received: from internal-client-001.example.com
           by mail.example.com
           with SMTP id o3F3BwdY028431;
           Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
       From: randomuser@example.net
       To: user@example.com
       Date: Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
       Subject: This is a test

       Hi, just making sure DKIM is working!

       --part1_13d.2e68ed54_boundary--

   Example 3: Example ARF report using these extensions

   This example ARF message is making the following assertion:

   o  DKIM verification of the signature added within "example.net"
      failed when it was processed on arrival at "mail.example.com".

   o  The cause for the verification failure was a mismatch between the
      body contents observed at the verifier and the body hash contained
      in the signature.























Kucherawy & Fontana       Expires July 11, 2011                [Page 29]

Internet-Draft           Auth Failure Reporting             January 2011


Appendix C.  Public Discussion

   [REMOVE BEFORE PUBLICATION]

   Public discussion of this proposed specification is handled via the
   mail-vet-discuss@mipassoc.org mailing list.  The list is open.
   Access to subscription forms and to list archives can be found at
   http://mipassoc.org/mailman/listinfo/mail-vet-discuss.











































Kucherawy & Fontana       Expires July 11, 2011                [Page 30]

Internet-Draft           Auth Failure Reporting             January 2011


Authors' Addresses

   Murray S. Kucherawy
   Cloudmark
   128 King St., 2nd Floor
   San Francisco, CA  94107
   US

   Phone: +1 415 946 3800
   Email: msk@cloudmark.com


   Hilda Fontana
   eCert Systems
   One Market St., Suite 3600
   San Francisco, CA  94105
   US

   Phone: +1 415 681 8000
   Email: hfontana@ecertsystems.com































Kucherawy & Fontana       Expires July 11, 2011                [Page 31]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/