idnits 2.17.1 draft-ietf-marf-dkim-reporting-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2012) is 4449 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 5617 (ref. 'ADSP') ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'EMAIL-ARCH') ** Obsolete normative reference: RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARF Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Standards Track February 12, 2012 5 Expires: August 15, 2012 7 Extensions to DKIM for Failure Reporting 8 draft-ietf-marf-dkim-reporting-10 10 Abstract 12 This memo presents extensions to the DomainKeys Identified Mail 13 (DKIM) specification to allow for detailed reporting of message 14 authentication failures in an on-demand fashion. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 15, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Imported Definitions . . . . . . . . . . . . . . . . . . . 4 54 2.3. Other Definitions . . . . . . . . . . . . . . . . . . . . 4 55 3. Optional Reporting for DKIM . . . . . . . . . . . . . . . . . 5 56 3.1. Extension DKIM Signature Tag . . . . . . . . . . . . . . . 5 57 3.2. DKIM Reporting TXT Record . . . . . . . . . . . . . . . . 5 58 3.3. DKIM Reporting Algorithm . . . . . . . . . . . . . . . . . 6 59 4. Optional Reporting Address for DKIM-ADSP . . . . . . . . . . . 9 60 5. Requested Reports . . . . . . . . . . . . . . . . . . . . . . 11 61 5.1. Requested Reports for DKIM Failures . . . . . . . . . . . 11 62 5.2. Requested Reports for DKIM ADSP Failures . . . . . . . . . 11 63 6. Report Generation . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. Report Format . . . . . . . . . . . . . . . . . . . . . . 13 65 6.2. Other Guidance . . . . . . . . . . . . . . . . . . . . . . 13 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7.1. DKIM Signature Tag Registration . . . . . . . . . . . . . 14 68 7.2. DKIM ADSP Tag Registration . . . . . . . . . . . . . . . . 14 69 7.3. DKIM Reporting Tag Registry . . . . . . . . . . . . . . . 14 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8.1. Inherited Considerations . . . . . . . . . . . . . . . . . 16 72 8.2. Deliberate Misuse . . . . . . . . . . . . . . . . . . . . 16 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 77 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 78 B.1. Example Use of DKIM Signature Extension Tag . . . . . . . 20 79 B.2. Example DKIM Reporting TXT Record . . . . . . . . . . . . 20 80 B.3. Example Use of DKIM ADSP Extension Tags . . . . . . . . . 21 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 1. Introduction 85 [DKIM] introduced a mechanism for message signing and authentication. 86 It uses digital signing to associate a domain name with a message in 87 a reliable (i.e. not forgeable) manner. The output is a verified 88 domain name that can then be subjected to some sort of evaluation 89 process (e.g., advertised sender policy, comparison to a known-good 90 list, submission to a reputation service, etc.). 92 Deployers of message authentication technologies are increasingly 93 seeking visibility into DKIM verification failures and conformance 94 failures involving the published signing practices (e.g., [ADSP]) of 95 an Administrative Management Domain (ADMD; see [EMAIL-ARCH]). 97 This document extends [DKIM] and [ADSP] to add an optional reporting 98 address and some reporting parameters. Reports are generated using 99 the format defined in [I-D.IETF-MARF-AUTHFAILURE-REPORT]. 101 2. Definitions 103 2.1. Keywords 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORDS]. 109 2.2. Imported Definitions 111 The ABNF token "qp-section" is imported from [MIME]. 113 Numerous DKIM-specific terms used here are defined in [DKIM]. The 114 definition of the ABNF token "domain-name" can also be found there. 116 2.3. Other Definitions 118 report generator: A report generator is an entitiy that generates 119 and sends reports. For the scope of this memo, the term refers to 120 Verifiers, as defined in Section 2.2 of [DKIM], designed also to 121 generate authentication failure reports according to this 122 specification. 124 3. Optional Reporting for DKIM 126 A domain name owner employing [DKIM] for email signing and 127 authentication might want to know when signatures in use by specific 128 keys are not successfully verifying. Currently there is no such 129 mechanism defined. 131 This document adds optional "tags" (as defined in [DKIM]) to the 132 DKIM-Signature header field and the DKIM key record in the DNS, using 133 the formats defined in that specification. 135 3.1. Extension DKIM Signature Tag 137 The following tag is added to DKIM-Signature header fields when a 138 Signer wishes to request that reports of failed verifications be 139 generated by a Verifier: 141 r= Reporting Requested (plain-text; OPTIONAL; no default). If 142 present, this tag indicates that the Signer requests that 143 Verifiers generate a report when verification of the DKIM 144 signature fails. At present, the only legal value is the single 145 character "y" (in either upper or lower case). A complete 146 description and illustration of how this is applied can be found 147 in Section 3.3. 149 ABNF: 151 sig-r-tag = %x72 *WSP "=" *WSP "y" 153 3.2. DKIM Reporting TXT Record 155 When a Signer wishes to advertise that it wants to receive failed 156 verification reports, it also places in the DNS a TXT resource record 157 (RR) whose content follows the same general syntax as DKIM key 158 records, as defined in Section 3.6.1 of [DKIM], in that it is made up 159 of a sequence of tag-value objects. In this case, the tags and 160 values comprise the parameters to be used when generating the 161 reports. A report generator will request the content of this record 162 when it sees an "r=" tag in a DKIM-Signature header field. 164 The reassembly rules of Section 3.6.2.2 of [DKIM] also apply here if 165 the reporting TXT record consists of several string fragments. 167 Any tag found in the content of this record that is not registered 168 with IANA as described in Section 7.3 MUST be ignored. 170 The initial list of tags supported for the reporting TXT record is as 171 follows: 173 ra= Reporting Address (plain-text; OPTIONAL). A dkim-quoted- 174 printable string (see Section 2.11 of [DKIM]) containing the 175 local-part of an email address to which a report SHOULD be sent 176 when mail fails DKIM verification for one of the reasons 177 enumerated below. The value MUST be interpreted as a local-part 178 only. To construct the actual address to which the report is 179 sent, the Verifier simply appends to this value an "@" followed by 180 the domain name found in the "d=" tag of the DKIM-Signature header 181 field. Therefore, an ADMD making use of this specification MUST 182 ensure that an email address thus constructed can receive reports 183 generated as described in Section 6. ABNF: 185 rep-ra-tag = %x72.61 *WSP "=" *WSP qp-section 187 rp= Requested Report Percentage (plain-text; OPTIONAL; default is 188 "100"). The value is an integer from 0 to 100 inclusive that 189 indicates what percentage of incidents of signature authentication 190 failures, selected at random, are to cause reports to be 191 generated. The report generator SHOULD NOT issue reports for more 192 than the requested percentage of incidents. Report generators MAY 193 make use of the "Incidents:" field in [ARF] to indicate that there 194 are more reportable incidents than there are reports. ABNF: 196 rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT 198 rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The 199 value MUST be a colon-separated list of tokens representing those 200 conditions under which a report is desired. See Section 5.1 for a 201 list of valid tags. ABNF: 203 rep-rr-type = ( "all" / "d" / "o" / "p"/ "s" / "v" / "x" ) 204 rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type 205 *WSP 0* ( ":" *WSP rep-rr-type ) 207 rs= Requested SMTP Error String (text; OPTIONAL; no default). The 208 value is a dkim-quoted-printable string that the publishing ADMD 209 requests be included in [SMTP] error strings if messages are 210 rejected during the delivery SMTP session. ABNF: 212 rep-rs-tag = %x72.73 *WSP "=" qp-section 214 In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be 215 ignored, and the report generator MUST NOT issue a report. 217 3.3. DKIM Reporting Algorithm 219 Report generators MUST apply the following algorithm, or one 220 semantically equivalent to it, for each DKIM-Signature header field 221 whose verification fails for some reason. Note that this processing 222 is done as a reporting extension only; the outcome of the specified 223 DKIM evaluation MUST be otherwise unaffected. 225 1. If the DKIM-Signature field did not contain a valid "r=" tag, 226 terminate. 228 2. Issue a [DNS] TXT query to the name that results from appending 229 the value of the "d=" tag in the DKIM-Signature field to the 230 string "_report._domainkey.". For example, if the DKIM- 231 Signature header field contains "d=example.com", issue a DNS TXT 232 query to "_report._domainkey.example.com". 234 3. If the DNS query returns anything other than a success status 235 code (0), also known as NOERROR, or if multiple TXT records are 236 returned, terminate. 238 4. If the resultant TXT is in several string fragments, reassemble 239 it as described in Section 3.6.2.2 of [DKIM]. 241 5. If the TXT content is syntactically invalid, the implementation, 242 terminate. 244 6. If the reason for the signature evaluation failure does not 245 match one of the report requests found in the "rr=" tag (or its 246 default value), terminate. 248 7. If a report percentage ("rp=") tag was present, select a random 249 number between 0 and 99, inclusive; if the selected number is 250 higher than the tag's value, terminate. 252 8. If no "ra=" tag was present, skip this step and the next one. 253 Otherwise, determine the reporting address by extracting the 254 value of the "ra=" tag and appending to it "@" followed by the 255 domain name found in the "d=" tag of the DKIM-Signature header 256 field. 258 9. Construct and send a report in compliance with Section 6 of this 259 memo that includes as its intended recipient the address 260 constructed in the previous step. 262 10. If the [SMTP] session during which the DKIM signautre was 263 evaluated is still active and the SMTP server has not already 264 given its response to the DATA command that relayed the message, 265 and an "rs=" tag was present in the TXT record, the SMTP server 266 SHOULD include the decoded string found in the "rs=" tag in its 267 SMTP reply to the DATA command. 269 This algorithm has the following advantages over previous 270 implementations: 272 a. If the DKIM signature fails to verify, no additional DNS check is 273 made to see if reporting is requested; the request is active in 274 that it is included in the DKIM-Signature header field. 275 (Previous implementations included the reporting address in the 276 DKIM key record, which is not queried for certain failure cases. 277 This meant, for full reporting, that the key record had to be 278 retrieved even when it was not otherwise necessary.) 280 b. The request is confirmed by the presence of a corresponding TXT 281 record in the DNS, since the Signer thus provides the parameters 282 required to construct and send the report. This means a 283 malicious Signer cannot falsely assert that someone else wants 284 failure reports and cause unwanted mail to be generated. It can 285 cause additional DNS traffic against the domain listed in the 286 "d=" signature tag, but negative caching of the requested DNS 287 record will help to mitigate this issue. 289 c. It is not possible for a Signer to direct reports to an email 290 address outside of its own domain, preventing distributed email- 291 based denial-of-service attacks. 293 The above procedure does not permit the detection and reporting of 294 messages including a fraudulent DKIM-Signature header field, where 295 such signature did not include an "r=" tag. It might be useful to 296 some Signers to receive such reports, but this use case is not 297 supported. To support this, a Verifier would have to violate the 298 first step above and continue even in the absence of an "r=" tag. 299 Although this satisfies this reporting requirement (which is expected 300 to be unusual), it also creates a possible denial-of-service attack 301 as such Verifiers will always look for the reporting TXT record, so 302 the generator of fraudulent messages could simply send a large volume 303 of such messages to a number of destinations. Thus, the specified 304 algorithm does not accommodate this case. 306 4. Optional Reporting Address for DKIM-ADSP 308 There also exist cases in which a domain name owner employing [ADSP] 309 for announcing signing practises with DKIM may want to know when 310 messages are received without valid author domain signatures. 311 Currently there is no such mechanism defined. 313 This document adds the following optional "tags" (as defined in 314 [ADSP]) to the DKIM ADSP records, using the form defined in that 315 specification: 317 ra= Reporting Address (plain-text; OPTIONAL; no default). The value 318 MUST be a dkim-quoted-printable string containing the local-part 319 of an email address to which a report SHOULD be sent when mail 320 claiming to be from this domain failed the verification algorithm 321 described in [ADSP], in particular because a message arrived 322 without a signature that validates, which contradicts what the 323 ADSP record claims. The value MUST be interpreted as a local-part 324 only. To construct the actual address to which the report is 325 sent, the Verifier simply appends to this value an "@" followed by 326 the domain whose policy was queried in order to evaluate the 327 sender's ADSP, i.e., the one taken from the RFC5322.From domain of 328 the message under evaluation. Therefore, a signer making use of 329 this extension tag MUST ensure that an email address thus 330 constructed can receive reports generated as described in 331 Section 6. ABNF: 333 adsp-ra-tag = %x72.61 *WSP "=" qp-section 335 rp= Requested Report Percentage (plain-text; OPTIONAL; default is 336 "100"). The value is a single integer from 0 to 100 inclusive 337 that indicates what percentage of incidents of ADSP evaluation 338 failures, selected at random, should cause reports to be 339 generated. The report generator SHOULD NOT issue reports for more 340 than the requested percentage of incidents. Report generators MAY 341 make use of the "Incidents:" field in [ARF] to indicate that there 342 are more reportable incidents than there are reports. ABNF: 344 adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT 346 rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The 347 value MUST be a colon-separated list of tokens representing those 348 conditions under which a report is desired. See Section 5.2 for a 349 list of valid tags. ABNF: 351 adsp-rr-type = ( "all" / "d" / "o" / "p" / "s" / "u" ) 352 adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type 353 *WSP 0* ( ":" *WSP adsp-rr-type ) 355 rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). 356 The value is a string the signing domain requests be included in 357 [SMTP] error strings when messages are rejected during a single 358 SMTP session. ABNF: 360 adsp-rs-tag = %x72.73 *WSP "=" qp-section 362 In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be 363 ignored, and the report generator MUST NOT issue a report. 365 5. Requested Reports 367 This memo also includes, as the "ro" tags defined above, the means by 368 which the signer can request reports for specific circumstances of 369 interest. Verifiers MUST NOT generate reports for incidents that do 370 not match a requested report, and MUST ignore requests for reports 371 not included in this list. 373 5.1. Requested Reports for DKIM Failures 375 The following report requests are defined for DKIM keys: 377 all All reports are requested. 379 d Reports are requested for signature evaluation errors that 380 resulted from DNS issues (e.g., key retrieval problems). 382 o Reports are requested for any reason related to DKIM signature 383 evaluation not covered by other report requests listed here. 385 p Reports are requested for signatures that are rejected for local 386 policy reasons at the Verifier that are related to DKIM signature 387 evaluation. 389 s Reports are requested for signature or key syntax errors. 391 v Reports are requested for signature verification failures or body 392 hash mismatches. 394 x Reports are requested for signatures rejected by the Verifier 395 because the expiration time has passed. 397 5.2. Requested Reports for DKIM ADSP Failures 399 The following report requests are defined for ADSP records: 401 all All reports are requested. 403 d Reports are requested for messages that could not have [ADSP] 404 evaluated due to DNS (policy retrieval) issues. 406 o Reports are requested for any [ADSP]-related failure reason not 407 covered by other report requests listed here. 409 p Reports are requested for messages that are rejected for local 410 policy reasons at the Verifier that are related to [ADSP]. 412 s Reports are requested for messages that have a valid [DKIM] 413 signature but do not match the published [ADSP] policy. 415 u Reports are requested for messages that have no valid [DKIM] 416 signature and do not match the published [ADSP] policy. 418 6. Report Generation 420 This section describes the process for generating and sending reports 421 in accordance with the request of the signer and/or sender as 422 described above. 424 6.1. Report Format 426 All reports generated as a result of requests contained in these 427 extension parameters MUST be generated in compliance with [ARF] and 428 its extension specific to this work, 429 [I-D.IETF-MARF-AUTHFAILURE-REPORT]. 431 6.2. Other Guidance 433 Additional guidance about the generation of these reports can be 434 found in [I-D.IETF-MARF-AS], especially Section 9. 436 7. IANA Considerations 438 As required by [IANA-CONSIDERATIONS], this section contains registry 439 information for the new [DKIM] signature tags, and the new [ADSP] 440 tags. It also creates a DKIM reporting tag registry. 442 7.1. DKIM Signature Tag Registration 444 IANA is requested to update the DKIM Signature Tag Specification 445 Registry to include the following new items: 447 +------+-----------------+--------+ 448 | TYPE | REFERENCE | STATUS | 449 +------+-----------------+--------+ 450 | r | (this document) | active | 451 +------+-----------------+--------+ 453 7.2. DKIM ADSP Tag Registration 455 IANA is requested to update the DKIM ADSP Specification Tag Registry 456 to include the following new items: 458 +------+-----------------+ 459 | TYPE | REFERENCE | 460 +------+-----------------+ 461 | ra | (this document) | 462 | rp | (this document) | 463 | rr | (this document) | 464 | rs | (this document) | 465 +------+-----------------+ 467 7.3. DKIM Reporting Tag Registry 469 IANA is requested to create a sub-registry of the DKIM Parameters 470 registry called "DKIM Reporting Tags". Additions to this registry 471 follow the "Specification Required" rules, with the following columns 472 required for all registrations: 474 Type: The name of the tag being used in reporting records 476 Reference: The document that specifies the tag being defined 478 Status: The status of the tag's current use, either "active" 479 indicating active use, or "historic" indicating discontinued or 480 deprecated use 482 The initial registry entries are as follows: 484 +------+-----------------+--------+ 485 | TYPE | REFERENCE | STATUS | 486 +------+-----------------+--------+ 487 | ra | (this document) | active | 488 | rp | (this document) | active | 489 | rr | (this document) | active | 490 | rs | (this document) | active | 491 +------+-----------------+--------+ 493 8. Security Considerations 495 Security issues with respect to these reports are similar to those 496 found in [DSN]. 498 8.1. Inherited Considerations 500 Implementers are advised to consider the Security Considerations 501 sections of [DKIM], [ADSP], [I-D.IETF-MARF-AS], and 502 [I-D.IETF-MARF-AUTHFAILURE-REPORT]. Many security issues related to 503 this draft are already covered in those documents. 505 8.2. Deliberate Misuse 507 Some threats caused by deliberate misuse of this mechanism are 508 discussed in Section 3.3. 510 9. References 512 9.1. Normative References 514 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 515 Sender Signing Practises", RFC 5617, August 2009. 517 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 518 Extensible Format for Email Feedback Reports", RFC 5965, 519 August 2010. 521 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 522 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 523 September 2011. 525 [DNS] Mockapetris, P., "Domain names - implementation and 526 specification", STD 13, RFC 1035, November 1987. 528 [EMAIL-ARCH] 529 Crocker, D., "Internet Mail Architecture", RFC 5598, 530 October 2008. 532 [I-D.IETF-MARF-AS] 533 Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email 534 Feedback Reports: An Applicability Statement for the Abuse 535 Reporting Format (ARF)", I-D draft-ietf-marf-as, 536 January 2012. 538 [I-D.IETF-MARF-AUTHFAILURE-REPORT] 539 Fontana, H., "Authentication Failure Reporting using the 540 Abuse Report Format", 541 I-D draft-ietf-marf-authfailure-report, January 2012. 543 [IANA-CONSIDERATIONS] 544 Alvestrand, H. and T. Narten, "Guidelines for Writing an 545 IANA Considerations Section in RFCs", RFC 5226, May 2008. 547 [KEYWORDS] 548 Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", RFC 2119, March 1997. 551 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 552 Extensions (MIME) Part One: Format of Internet Message 553 Bodies", RFC 2045, November 1996. 555 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 556 October 2008. 558 9.2. Informative References 560 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 561 for Delivery Status Notifications", RFC 3464, 562 January 2003. 564 Appendix A. Acknowledgements 566 The authors wish to acknowledge the following for their review and 567 constructive criticism of this proposal: Steve Atkins, Monica Chew, 568 Dave Crocker, Tim Draegen, Frank Ellermann, JD Falk, John Levine, and 569 Scott Kitterman. 571 Appendix B. Examples 573 This section contains examples of the use of each of the extensions 574 defined by this memo. 576 B.1. Example Use of DKIM Signature Extension Tag 578 A DKIM-Signature field including use of the extension tag defined by 579 this memo: 581 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; 582 d=example.com; s=jan2012; r=y; 583 h=from:to:subject:date:message-id; 584 bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=; 585 b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ 586 IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ 587 R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8 589 Example 1: DKIM-Signature field using this extension 591 This example DKIM-Signature field contains the "r=" tag that 592 indicates reports are requested on verification failure. 594 If this signature fails to verify, a TXT query will be sent to 595 "_report._domainkey.example.com" to retrieve a reporting address and 596 other report parameters. 598 B.2. Example DKIM Reporting TXT Record 600 An example DKIM Reporting TXT Record as defined by this memo: 602 ra=dkim-errors; rp=100; rr=v:x 604 Example 2: Example DKIM Reporting TXT Record 606 This example, continuing from the previous one, shows a message that 607 might be found at "_report._domainkey.example.com" in a TXT record. 608 It makes the following requests: 610 o Reports about signature evaluation failures should be send to the 611 address "dkim-errors" at the signer's domain; 613 o All (100%) incidents should be reported; 615 o Only reports about signature verification failures and expired 616 signatures should be generated. 618 B.3. Example Use of DKIM ADSP Extension Tags 620 A DKIM ADSP record including use of the extensions defined by this 621 memo: 623 dkim=all; ra=dkim-adsp-errors; rr=u 625 Example 3: DKIM ADSP record using these extensions 627 This example ADSP record makes the following assertions: 629 o The sending domain (i.e. the one that is advertising this policy) 630 signs all mail it sends; 632 o Reports about ADSP evaluation failures should be send to the 633 address "dkim-adsp-errors" at the Author's domain; 635 o Only reports about unsigned messages should be generated. 637 Author's Address 639 Murray S. Kucherawy 640 Cloudmark 641 128 King St., 2nd Floor 642 San Francisco, CA 94107 643 US 645 Phone: +1 415 946 3800 646 Email: msk@cloudmark.com