From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6651.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc6651.txt (limited to 'doc/rfc/rfc6651.txt') 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, . + + + + + + + + + + + + + +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] + -- cgit v1.2.3