doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6651.txt b/doc/rfc/rfc6651.txt
new file mode 100644
index 0000000..31028ea
--- /dev/null
+++ b/doc/rfc/rfc6651.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 6651                                     Cloudmark
+Category: Standards Track                                      June 2012
+ISSN: 2070-1721
+
+
+ Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting
+
+Abstract
+
+   This document presents extensions to the DomainKeys Identified Mail
+   (DKIM) specification to allow for detailed reporting of message
+   authentication failures in an on-demand fashion.
+
+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/rfc6651.
+
+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.
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 1]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Definitions .....................................................3
+      2.1. Key Words ..................................................3
+      2.2. Notation ...................................................3
+      2.3. Imported Definitions .......................................3
+      2.4. Other Definitions ..........................................3
+   3. Optional Reporting for DKIM .....................................4
+      3.1. Extension DKIM Signature Tag ...............................4
+      3.2. DKIM Reporting TXT Record ..................................4
+      3.3. DKIM Reporting Algorithm ...................................6
+   4. Optional Reporting Address for DKIM ADSP ........................8
+   5. Requested Reports ...............................................9
+      5.1. Requested Reports for DKIM Failures .......................10
+      5.2. Requested Reports for DKIM ADSP Failures ..................10
+   6. Report Generation ..............................................11
+      6.1. Report Format .............................................11
+      6.2. Other Guidance ............................................11
+   7. IANA Considerations ............................................11
+      7.1. DKIM Signature Tag Registration ...........................11
+      7.2. DKIM ADSP Tag Registration ................................12
+      7.3. DKIM Reporting Tag Registry ...............................12
+   8. Security Considerations ........................................13
+      8.1. Inherited Considerations ..................................13
+      8.2. Report Volume .............................................13
+      8.3. Deliberate Misuse .........................................13
+      8.4. Unreported Fraud ..........................................14
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................15
+   Appendix A. Acknowledgements ......................................16
+   Appendix B. Examples ..............................................16
+      B.1. Example Use of DKIM Signature Extension Tag ...............16
+      B.2. Example DKIM Reporting TXT Record .........................17
+      B.3. Example Use of DKIM ADSP Extension Tags ...................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 2]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+1.  Introduction
+
+   DomainKeys Identified Mail [DKIM] introduced a mechanism for message
+   signing and authentication.  It uses digital signing to associate a
+   domain name with a message in a reliable manner.  The verified domain
+   name can then be evaluated (e.g., checking advertised sender policy,
+   comparison to a known-good list, submission to a reputation service,
+   etc.).
+
+   Deployers of message authentication technologies are increasingly
+   seeking visibility into DKIM verification failures and conformance
+   failures involving the published signing practices (e.g., Author
+   Domain Signing Practices [ADSP]) of an ADministrative Management
+   Domain (ADMD; see [EMAIL-ARCH]).
+
+   This document extends [DKIM] and [ADSP] to add an optional reporting
+   address and some reporting parameters.  Reports are generated using
+   the format defined in [ARF-AUTHFAIL].
+
+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.  Notation
+
+   Certain properties of email messages described in this document are
+   referenced using notation found in [EMAIL-ARCH] (e.g.,
+   "RFC5322.From").
+
+2.3.  Imported Definitions
+
+   Numerous DKIM-specific terms used here are defined in [DKIM].
+   The definitions of the [ABNF] tokens "domain-name" and
+   "dkim-quoted-printable" can also be found there.
+
+2.4.  Other Definitions
+
+   report generator:  A report generator is an entity that generates and
+      sends reports.  For the scope of this document, the term refers to
+      Verifiers, as defined in Section 2.2 of [DKIM], with the added
+      capability to generate authentication failure reports according to
+      this specification.
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 3]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+3.  Optional Reporting for DKIM
+
+   A domain name owner employing [DKIM] for email signing and
+   authentication might want to know when signatures that ought to be
+   verifiable are not successfully verifying.  Currently, there is no
+   such mechanism defined.
+
+   This section adds optional "tags" (as defined in [DKIM]) to the
+   DKIM-Signature header field and the DKIM key record in the DNS, using
+   the formats defined in that specification.
+
+3.1.  Extension DKIM Signature Tag
+
+   The following tag is added to DKIM-Signature header fields when a
+   Signer wishes to request that reports of failed verifications be
+   generated by a Verifier:
+
+   r=  Reporting Requested (plain-text; OPTIONAL; no default).  If
+       present, this tag indicates that the Signer requests that
+       Verifiers generate a report when verification of the DKIM
+       signature fails.  At present, the only legal value is the single
+       character "y".  A complete description and illustration of how
+       this is applied can be found in Section 3.3.
+
+      ABNF:
+
+      sig-r-tag = %x72 *WSP "=" *WSP %x79
+                ; "r=y" (lower-case only)
+
+3.2.  DKIM Reporting TXT Record
+
+   When a Signer wishes to advertise that it wants to receive failed
+   verification reports, it places in the DNS a TXT Resource Record
+   (RR).  The RR contains a sequence of tag-value objects in a format
+   similar to DKIM key records (see Section 3.6.1 of [DKIM]), but it is
+   entirely independent of those key records and is found at a different
+   name.  The tag-value objects in this case comprise the parameters to
+   be used when generating the reports.  A report generator will request
+   the content of this record when it sees an "r=" tag in a
+   DKIM-Signature header field.
+
+   Section 3.6.2.2 of [DKIM] provides guidance with respect to the
+   handling of a TXT RR that comprises multiple distinct strings
+   ("character-strings" in the parlance of [DNS]).  The same process
+   MUST be applied here.
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 4]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   Implementations MUST support all tags defined in this document, and
+   any other tag found in the content of the record that is not
+   recognized by an implementation MUST be ignored.  See Section 7.3 for
+   details about finding or registering extension tags.
+
+   The initial list of tags supported for the reporting TXT record is as
+   follows:
+
+   ra=  Reporting Address (plain-text; OPTIONAL).  A
+        dkim-quoted-printable string (see Section 2.11 of [DKIM])
+        containing the local-part of an email address to which a report
+        SHOULD be sent when mail fails DKIM verification for one of the
+        reasons enumerated below.  The value MUST be interpreted as a
+        local-part only.  To construct the actual address to which the
+        report is sent, the Verifier simply appends to this value an "@"
+        followed by the domain name found in the "d=" tag of the
+        DKIM-Signature header field.  Therefore, a Signer making use of
+        this specification MUST ensure that an email address thus
+        constructed can receive reports generated as described in
+        Section 6.
+
+      ABNF:
+
+      rep-ra-tag = %x72.61 *WSP "=" *WSP dkim-quoted-printable
+                 ; "ra=..." (lower-case only for the tag name)
+
+   rp=  Requested Report Percentage (plain-text; OPTIONAL; default is
+        "100").  The value is an integer from 0 to 100 inclusive that
+        indicates what percentage of incidents of signature
+        authentication failures, selected at random, are to cause
+        reports to be generated.  The report generator SHOULD NOT issue
+        reports for more than the requested percentage of incidents.
+        Report generators MAY make use of the "Incidents:" field in
+        [ARF] to indicate that there are more reportable incidents than
+        there are reports.
+
+      ABNF:
+
+      rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
+                 ; "rp=..." (lower-case only)
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 5]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   rr=  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 5.1 for a list of valid tokens.
+
+      ABNF:
+
+      rep-rr-type = ( "all" / "d" / "o" / "p" / "s" / "u" / "v" / "x" )
+      rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
+                   *WSP *( ":" *WSP rep-rr-type )
+                 ; "rr=..." (lower-case only for the tag name)
+
+   rs=  Requested SMTP Error String (plain-text; OPTIONAL; no default).
+        The value is a dkim-quoted-printable string that the publishing
+        ADMD requests be included in [SMTP] error strings if messages
+        are rejected during the delivery SMTP session.
+
+      ABNF:
+
+      rep-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
+                 ; "rs=..." (lower-case only for the tag name)
+
+   In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be
+   ignored, and the report generator MUST NOT issue a report.
+
+3.3.  DKIM Reporting Algorithm
+
+   Report generators MUST apply the following algorithm, or one
+   semantically equivalent to it, for each DKIM-Signature header field
+   whose verification fails for some reason.  Note that this processing
+   is done as a reporting extension only; the outcome of the specified
+   DKIM evaluation MUST be otherwise unaffected.
+
+   1.  If the DKIM-Signature field did not contain a valid "r=" tag,
+       terminate.
+
+   2.  Issue a [DNS] TXT query to the name that results from appending
+       the value of the "d=" tag in the DKIM-Signature field to the
+       string "_report._domainkey.".  For example, if the DKIM-Signature
+       header field contains "d=example.com", issue a DNS TXT query to
+       "_report._domainkey.example.com".
+
+   3.  If the DNS query returns anything other than RCODE 0 (NOERROR),
+       or if multiple TXT records are returned, terminate.
+
+   4.  If the resultant TXT is in several string fragments, concatenate
+       them as described in Section 3.6.2.2 of [DKIM].
+
+
+
+
+Kucherawy                    Standards Track                    [Page 6]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   5.  If the TXT content is syntactically invalid (see Section 3.2),
+       terminate.
+
+   6.  If the reason for the signature evaluation failure does not match
+       one of the report requests found in the "rr=" tag (or its default
+       value), terminate.
+
+   7.  If a report percentage ("rp=") tag was present, select a random
+       number between 0 and 99, inclusive; if the selected number is not
+       lower than the tag's value, terminate.
+
+   8.  If no "ra=" tag was present, skip this step and the next one.
+       Otherwise, determine the reporting address by extracting the
+       value of the "ra=" tag and appending to it an "@" followed by the
+       domain name found in the "d=" tag of the DKIM-Signature header
+       field.
+
+   9.  Construct and send a report in compliance with Section 6 of this
+       document that includes as its intended recipient the address
+       constructed in the previous step.
+
+   10. If the [SMTP] session during which the DKIM signature was
+       evaluated is still active and the SMTP server has not already
+       given its response to the DATA command that relayed the message,
+       and an "rs=" tag was present in the TXT record, the SMTP server
+       SHOULD include the decoded string found in the "rs=" tag in its
+       SMTP reply to the DATA command.
+
+   In order to thwart attacks that seek to convert report generators
+   into unwitting denial-of-service attack participants, a report
+   generator SHOULD NOT issue more than one report to any given domain
+   as a result of a single message.  Further, a report generator SHOULD
+   establish an upper bound on the number of reports a single message
+   can generate overall.  For example, a message with three invalid
+   signatures, two from example.com and one from example.net, would
+   generate at most one report to each of those domains.
+
+   This algorithm has the following advantages over previous
+   pre-standardization implementations, such as early versions of
+   [OPENDKIM]:
+
+   a.  If the DKIM signature fails to verify, no additional DNS check is
+       made to see if reporting is requested; the request is active in
+       that it is included in the DKIM-Signature header field.
+       (Previous implementations included the reporting address in the
+       DKIM key record, which is not queried for certain failure cases.
+       This meant, for full reporting, that the key record had to be
+       retrieved even when it was not otherwise necessary.)
+
+
+
+Kucherawy                    Standards Track                    [Page 7]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   b.  The request is confirmed by the presence of a corresponding TXT
+       record in the DNS, since the Signer thus provides the parameters
+       required to construct and send the report.  This means a
+       malicious Signer cannot falsely assert that someone else wants
+       failure reports and cause unwanted mail to be generated.  It can
+       cause additional DNS traffic against the domain listed in the
+       "d=" signature tag, but negative caching of the requested DNS
+       record will help to mitigate this issue.
+
+   c.  It is not possible for a Signer to direct reports to an email
+       address outside of its own domain, preventing distributed email-
+       based denial-of-service attacks.
+
+   See Section 8.4 for some considerations regarding limitations of this
+   mechanism.
+
+4.  Optional Reporting Address for DKIM ADSP
+
+   A domain name owner employing Author Domain Signing Practices [ADSP]
+   may also want to know when messages are received without valid author
+   domain signatures.  Currently, there is no such mechanism defined.
+
+   This section adds the following optional "tags" (as defined in
+   [ADSP]) to the DKIM ADSP records, using the form defined in that
+   specification:
+
+   ra=  Reporting Address (plain-text; OPTIONAL; no default).  The value
+        MUST be a dkim-quoted-printable string containing the local-part
+        of an email 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 value MUST be interpreted as a
+        local-part only.  To construct the actual 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, i.e., the RFC5322.From domain of the
+        message under evaluation.  Therefore, a Signer making use of
+        this extension tag MUST ensure that an email address thus
+        constructed can receive reports generated as described in
+        Section 6.
+
+      ABNF:
+
+      adsp-ra-tag = %x72.61 *WSP "=" dkim-quoted-printable
+                  ; "ra=..." (lower-case only for the tag name)
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 8]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   rp=  Requested Report Percentage (plain-text; OPTIONAL; default is
+        "100").  The value is a single integer from 0 to 100 inclusive
+        that indicates what percentage of incidents of ADSP evaluation
+        failures, selected at random, are to cause reports to be
+        generated.  The report generator SHOULD NOT issue reports for
+        more than the requested percentage of incidents.  An exception
+        to this might be some out-of-band arrangement between two
+        parties to override it with some mutually agreed value.  Report
+        generators MAY make use of the "Incidents:" field in [ARF] to
+        indicate that there are more reportable incidents than there are
+        reports.
+
+      ABNF:
+
+      adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
+                  ; "rp=..." (lower-case only)
+
+   rr=  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 5.2 for a list of valid tokens.
+
+      ABNF:
+
+      adsp-rr-type = ( "all" / "o" / "p" / "s" / "u" )
+      adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type
+                    *WSP *( ":" *WSP adsp-rr-type )
+                  ; "rr=..." (lower-case only for the tag name)
+
+   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 during a single
+        SMTP session.
+
+      ABNF:
+
+      adsp-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
+                  ; "rs=..." (lower-case only for the tag name)
+
+   In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be
+   ignored, and the report generator MUST NOT issue a report.
+
+5.  Requested Reports
+
+   The "rr" tags defined above allow a Signer to specify the types of
+   errors about which it is interested in receiving reports.  This
+   section defines the error types and corresponding token values.
+
+
+
+
+Kucherawy                    Standards Track                    [Page 9]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   Verifiers MUST NOT generate reports for incidents that do not match a
+   requested report and MUST ignore requests for reports not included in
+   this list.
+
+5.1.  Requested Reports for DKIM Failures
+
+   The following report requests are defined for DKIM keys:
+
+   all  All reports are requested.
+
+   d    Reports are requested for signature evaluation errors that
+        resulted from DNS issues (e.g., key retrieval problems).
+
+   o    Reports are requested for any reason related to DKIM signature
+        evaluation not covered by other report requests listed here.
+
+   p    Reports are requested for signatures that are rejected for local
+        policy reasons at the Verifier that are related to DKIM
+        signature evaluation.
+
+   s    Reports are requested for signature or key syntax errors.
+
+   u    Reports are requested for signatures that include unknown tags
+        in the signature field.
+
+   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.
+
+5.2.  Requested Reports for DKIM ADSP Failures
+
+   The following report requests are defined for ADSP records:
+
+   all  All reports are requested.
+
+   o    Reports are requested for any [ADSP]-related failure reason not
+        covered by other report requests listed here.
+
+   p    Reports are requested for messages that are rejected for local
+        policy reasons at the Verifier that are related to [ADSP].
+
+   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 and do not match the published [ADSP] policy.
+
+
+
+Kucherawy                    Standards Track                   [Page 10]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+6.  Report Generation
+
+   This section describes the process for generating and sending reports
+   in accordance with the request of the Signer and/or sender as
+   described above.
+
+6.1.  Report Format
+
+   All reports generated as a result of requests contained in these
+   extension parameters MUST be generated in compliance with [ARF] and
+   its extension specific to this work, [ARF-AUTHFAIL].  Moreover,
+   because abuse reports from unverified sources might be handled with
+   some skepticism, report generators are strongly advised to use [DKIM]
+   to sign reports they generate.
+
+6.2.  Other Guidance
+
+   Additional guidance about the generation of these reports can be
+   found in [ARF-AS], especially in Section 6.
+
+7.  IANA Considerations
+
+   As required by [IANA-CONS], this section contains registry
+   information for the new [DKIM] signature tags and for the new [ADSP]
+   tags.  It also creates a DKIM reporting tag registry.
+
+7.1.  DKIM Signature Tag Registration
+
+   IANA has added the following item to the DKIM Signature Tag
+   Specifications registry:
+
+                 +------+-----------------+--------+
+                 | TYPE | REFERENCE       | STATUS |
+                 +------+-----------------+--------+
+                 | r    | (this document) | active |
+                 +------+-----------------+--------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 11]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+7.2.  DKIM ADSP Tag Registration
+
+   IANA has added the following items to the DKIM ADSP Specification
+   Tags registry:
+
+                 +------+-----------------+
+                 | TYPE | REFERENCE       |
+                 +------+-----------------+
+                 | ra   | (this document) |
+                 | rp   | (this document) |
+                 | rr   | (this document) |
+                 | rs   | (this document) |
+                 +------+-----------------+
+
+7.3.  DKIM Reporting Tag Registry
+
+   IANA has created a sub-registry of the DKIM Parameters registry
+   called "DKIM Reporting Tag Registry".  Additions to this registry
+   follow the "Specification Required" rules, with the following columns
+   required for all registrations:
+
+   Tag:  The name of the tag being used in reporting records
+
+   Reference:  The document that specifies the tag being defined
+
+   Status:  The status of the tag's current use -- either "active"
+      indicating active use, or "historic" indicating discontinued or
+      deprecated use
+
+   The initial registry entries are as follows:
+
+                 +-----+-----------------+--------+
+                 | TAG | REFERENCE       | STATUS |
+                 +-----+-----------------+--------+
+                 | ra  | (this document) | active |
+                 | rp  | (this document) | active |
+                 | rr  | (this document) | active |
+                 | rs  | (this document) | active |
+                 +-----+-----------------+--------+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 12]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+8.  Security Considerations
+
+   Security issues with respect to these reports are similar to those
+   found in [DSN].
+
+8.1.  Inherited Considerations
+
+   Implementers are advised to consider the Security Considerations
+   sections of [DKIM], [ADSP], [ARF-AS], and [ARF-AUTHFAIL].  Many
+   security issues related to this document are already covered in those
+   documents.
+
+8.2.  Report Volume
+
+   It is impossible to predict the volume of reports this facility will
+   generate when enabled by a report receiver.  An implementer ought to
+   anticipate substantial volume, since the amount of abuse occurring at
+   receivers cannot be known ahead of time, and may vary rapidly and
+   unpredictably.
+
+8.3.  Deliberate Misuse
+
+   Some threats caused by deliberate misuse of this error-reporting
+   mechanism are discussed in Section 3.3, but they warrant further
+   discussion here.
+
+   The presence of the DNS record that indicates willingness to accept
+   reports opens the recipient to abuse.  In particular, it is possible
+   for an attacker to attempt to cause a flood of reports toward the
+   domain identified in a signature's "d=" tag in one of these ways:
+
+   1.  Alter existing DKIM-Signature header fields by adding an "r=y"
+       tag (and possibly altering the "d=" tag to point at the target
+       domain);
+
+   2.  Add a new but bogus signature bearing an "r=y" tag and a "d=" tag
+       pointing at the target domain;
+
+   3.  Generate a completely new message bearing an "r=y" tag and a "d="
+       tag pointing at the target domain.
+
+   Consider, for example, the situation where an attacker sends out a
+   multi-million-message spam run and includes in the messages a fake
+   DKIM signature containing "d=example.com; r=y".  It won't matter that
+   those signatures couldn't possibly be real: each will fail
+   verification, and any implementations that support this specification
+   will report those failures, in the millions and in short order, to
+   example.com.
+
+
+
+Kucherawy                    Standards Track                   [Page 13]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   Implementers are therefore strongly advised not to advertise the DNS
+   record specified in this document except when failure reports are
+   desired.  Upon doing so, unexpected traffic volumes and attacks
+   should be anticipated.
+
+   Negative caching offers some protection against this pattern of
+   abuse, although it will work only as long as the negative time-to-
+   live on the relevant SOA record in the DNS.
+
+   Positive caching of this DNS reply also means that turning off the
+   flow of reports by removing the record is not likely to have an
+   immediate effect.  A low time-to-live on the record needs to be
+   considered.
+
+8.4.  Unreported Fraud
+
+   An attacker can craft fraudulent DKIM-Signature fields on messages,
+   without using "r=" tags, and avoid having these reported.  The
+   procedure described in Section 3.3 does not permit the detection and
+   reporting of such cases.
+
+   It might be useful to some Signers to receive such reports, but the
+   mechanism does not support it.  To offer such support, a Verifier
+   would have to violate the first step in the procedure and continue
+   even in the absence of an "r=" tag.  Although that would enable the
+   desired report, it would also create a possible denial-of-service
+   attack: such Verifiers would always look for the reporting TXT
+   record, so a generator of fraudulent messages could simply send a
+   large volume of messages without an "r=" tag to a number of
+   destinations.  To avoid that outcome, reports of fraudulent
+   DKIM-Signature header fields are not possible using the published
+   mechanism.
+
+9.  References
+
+9.1.  Normative References
+
+   [ABNF]     Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", 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.
+
+
+
+
+Kucherawy                    Standards Track                   [Page 14]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+   [ARF-AS]   Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email
+              Feedback Reports: An Applicability Statement for the Abuse
+              Reporting Format (ARF)", RFC 6650, June 2012.
+
+   [ARF-AUTHFAIL]
+              Fontana, H., "Authentication Failure Reporting Using the
+              Abuse Reporting Format", RFC 6591, April 2012.
+
+   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+              September 2011.
+
+   [DNS]      Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [EMAIL-ARCH]
+              Crocker, D., "Internet Mail Architecture", RFC 5598,
+              July 2009.
+
+   [IANA-CONS]
+              Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              October 2008.
+
+9.2.  Informative References
+
+   [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
+              for Delivery Status Notifications", RFC 3464,
+              January 2003.
+
+   [OPENDKIM] Kucherawy, M., "OpenDKIM -- Open Source DKIM Library and
+              Filter", August 2009, <http://www.opendkim.org>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 15]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+Appendix A.  Acknowledgements
+
+   The author wishes to acknowledge the following for their review and
+   constructive criticism of this proposal: Steve Atkins, Monica Chew,
+   Dave Crocker, Tim Draegen, Frank Ellermann, J.D. Falk, John Levine,
+   Scott Kitterman, and Andrew Sullivan.
+
+Appendix B.  Examples
+
+   This section contains examples of the use of each of the extensions
+   defined by this document.
+
+B.1.  Example Use of DKIM Signature Extension Tag
+
+   This example shows a DKIM-Signature field using the extension tag
+   defined by this document:
+
+       DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
+               d=example.com; s=jan2012; r=y;
+               h=from:to:subject:date:message-id;
+               bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=;
+               b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ
+                 IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ
+                 R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8
+
+           Example 1: DKIM-Signature Field Using This Extension
+
+   This example DKIM-Signature field contains the "r=" tag that
+   indicates reports are requested on verification failure.
+
+   Assuming the public key retrieved from the DNS and processed
+   according to [DKIM] would determine that the signature is invalid, a
+   TXT query will be sent to "_report._domainkey.example.com" to
+   retrieve a reporting address and other report parameters as described
+   in Section 3.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 16]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+B.2.  Example DKIM Reporting TXT Record
+
+   An example DKIM Reporting TXT record as defined by this document is
+   as follows:
+
+       ra=dkim-errors; rp=100; rr=v:x
+
+              Example 2: Example DKIM Reporting TXT Record
+
+   This example, continuing from the previous one, shows a message that
+   might be found at "_report._domainkey.example.com" in a TXT record.
+   It makes the following requests:
+
+   o  Reports about signature evaluation failures should be sent to the
+      address "dkim-errors" at the Signer's domain;
+
+   o  All incidents (100%) should be reported;
+
+   o  Only reports about signature verification failures and expired
+      signatures should be generated.
+
+B.3.  Example Use of DKIM ADSP Extension Tags
+
+   This example shows a DKIM ADSP record using the extensions defined by
+   this document:
+
+       dkim=all; ra=dkim-adsp-errors; rr=u
+
+            Example 3: 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 sent to the
+      address "dkim-adsp-errors" at the Author's domain;
+
+   o  Only reports about unsigned messages should be generated.
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 17]
+
+RFC 6651                DKIM Reporting Extensions              June 2012
+
+
+Author's Address
+
+   Murray S. Kucherawy
+   Cloudmark
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 946 3800
+   EMail: superuser@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                   [Page 18]
+