idnits 2.17.1 draft-kucherawy-dkim-reporting-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2010) is 5087 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') ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- No information found for draft-DRAFT-IETF-MARF-BASE - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.DRAFT-IETF-MARF-BASE' ** Obsolete normative reference: RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2822 (ref. 'MAIL') (Obsoleted by RFC 5322) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Standards Track April 15, 2010 5 Expires: October 17, 2010 7 Reporting of DKIM Verification Failures 8 draft-kucherawy-dkim-reporting-07 10 Abstract 12 This memo presents an extension to the DomainKeys Identified Mail 13 (DKIM) specifications to allow public keys for verification to 14 include a reporting address to be used to report message verification 15 issues, and extends an Internet Message reporting format to be 16 followed when generating such reports. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 17, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Imported Definitions . . . . . . . . . . . . . . . . . . . 4 62 3. Optional Key Reporting Address for DKIM . . . . . . . . . . . 5 63 4. Optional Key Reporting Address for DKIM-ADSP . . . . . . . . . 7 64 5. Requested Reports . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Requested Reports for DKIM Failures . . . . . . . . . . . 9 66 5.2. Requested Reports for DKIM ADSP Failures . . . . . . . . . 9 67 6. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Extension ARF Fields for DKIM Reporting . . . . . . . . . . . 11 69 7.1. New ARF Feedback Type . . . . . . . . . . . . . . . . . . 11 70 7.2. New ARF Header Names . . . . . . . . . . . . . . . . . . . 11 71 7.3. DKIM Failure Types . . . . . . . . . . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. DKIM Key Tag Registration . . . . . . . . . . . . . . . . 13 74 8.2. DKIM ADSP Tag Registration . . . . . . . . . . . . . . . . 13 75 8.3. Updates to ARF Feedback Types . . . . . . . . . . . . . . 13 76 8.4. Updates to ARF Header Names . . . . . . . . . . . . . . . 14 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 9.1. Inherited Considerations . . . . . . . . . . . . . . . . . 16 79 9.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.3. Automatic Generation . . . . . . . . . . . . . . . . . . . 16 81 9.4. Envelope Sender Selection . . . . . . . . . . . . . . . . 16 82 9.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 17 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 87 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 88 B.1. Example Use of DKIM Key Extension Tags . . . . . . . . . . 20 89 B.2. Example Use of DKIM ADSP Extension Tags . . . . . . . . . 20 90 B.3. Example Use of ARF Extension Headers . . . . . . . . . . . 21 91 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 23 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 96 [DKIM] introduced a standard for digital signing of messages for the 97 purposes of sender authentication. There exist cases in which a 98 domain name owner might want to receive reports from verifiers that 99 determine DKIM-signed mail apparently from its domain is failing to 100 verify according to [DKIM] or fails to conform to the domain's 101 published signing practices according to [ADSP]. 103 This document extends [DKIM] and [ADSP] to add an optional reporting 104 address to selector records, an optional means of specifying a 105 desired report format, and furthermore extends 106 [I-D.DRAFT-IETF-MARF-BASE] to add features required for DKIM 107 reporting. 109 This memo presumes those specifications thus modified will issue as 110 RFCs without these modifications. If the modifications are adopted 111 prior to their publicatons, clearly those sections of this memo can 112 be removed. 114 2. Definitions 116 2.1. Keywords 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [KEYWORDS]. 122 2.2. Imported Definitions 124 The ABNF token "qp-section" is imported from [MIME]. 126 base64 is defined in [MIME]. 128 3. Optional Key Reporting Address for DKIM 130 There exist cases in which a domain name owner employing [DKIM] for 131 e-mail signing and authentication may want to know when signatures in 132 use by specific keys are not successfully verifying. Currently there 133 is no such mechanism defined. 135 This document adds the following two optional "tags" (as defined in 136 [DKIM]) to the DKIM key records, using the form defined in that 137 specification: 139 r= Reporting Address (plain-text; OPTIONAL; no default). The value 140 MUST be a dkim-quoted-printable string containing the local-part 141 of an e-mail address to which a report SHOULD be sent when mail 142 signed with this key fails verification because either (a) the 143 signature verification itself failed, or (b) the body hash test 144 failed. The format of this reply is selected by the value of the 145 "rf=" tag, defined below. To generate a complete address to which 146 the report is sent, the verifier simply appends to this value an 147 "@" followed by the domain found in the "d=" tag of the signature 148 whose validation failed. 150 ABNF: 152 key-r-tag = %x72 *WSP "=" *WSP qp-section 154 rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The 155 value MUST be a colon-separated list of tokens representing 156 desired reporting formats in order of preference. Each element of 157 the list MUST be a token that is taken from the registered list of 158 DKIM report formats. See Section 8 for a description of the 159 registry and Section 6 for a description of recognized formats. 160 The verifier generating reports MUST generate a report using the 161 first token in the list that represents a report format it is 162 capable of generating. 164 ABNF: 166 rep-format = ( "arf" / "smtp" ) 168 key-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP 169 rep-format ) 171 ri= Requested Report Interval (plain-text; OPTIONAL; default is 172 "0"). The value is an integer that specifies an interval during 173 which no more than one report about a given type of incident 174 should be generated. A value of "0" requests a report for every 175 incident. Where the requested interval is not zero, the agent 176 generating a report SHOULD include an "Incidents:" field in the 177 generated report so the receiving agent has some indication of how 178 many reports were suppressed. 180 ABNF: 182 key-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT 184 ro= Requested Reports (plain-text; OPTIONAL; default is "all"). The 185 value MUST be a colon-separated list of tokens representing those 186 conditions under which a report is desired. See Section 5.1 for a 187 list of valid tags. 189 ABNF: 191 key-ro-type = ( "all" / "s" / "v" / "x" ) 193 key-ro-tag = %x72 %x6f *WSP "=" *WSP key-ro-type *WSP 0* ( ":" 194 *WSP key-ro-type ) 196 rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). 197 The value is a string the signing domain requests be included in 198 SMTP error strings when messages are rejected. 200 ABNF: 202 key-rs-tag = %x72 %x73 *WSP "=" qp-section 204 4. Optional Key Reporting Address for DKIM-ADSP 206 There also exist cases in which a domain name owner employing [ADSP] 207 for announcing signing practises with DKIM may want to know when 208 messages are received without valid author domain signatures. 209 Currently there is no such mechanism defined. 211 This document adds the following two optional "tags" (as defined in 212 [ADSP]) to the DKIM ADSP records, using the form defined in that 213 specification: 215 r= Reporting Address (plain-text; OPTIONAL; no default). The value 216 MUST be a dkim-quoted-printable string containing the local-part 217 of an e-mail address to which a report SHOULD be sent when mail 218 claiming to be from this domain failed the verification algorithm 219 described in [ADSP], in particular because a message arrived 220 without a signature that validates, which contradicts what the 221 ADSP record claims, The format of this reply MUST be in the format 222 specified by the "rf=" tag defined below. To generate a complete 223 address to which the report is sent, the verifier simply appends 224 to this value an "@" followed by the domain whose policy was 225 queried in order to evaluate the sender's ADSP. 227 ABNF: 229 adsp-r-tag = %x72 *WSP "=" qp-section 231 ABNF: 233 key-r-tag = %x72 *WSP "=" qp-section 235 rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The 236 value MUST be a colon-separated list of tokens representing 237 desired reporting formats in decreasing order of preference. Each 238 element of the list MUST be a token that is taken from the 239 registered list of DKIM report formats. See Section 8 for a 240 description of the registry and Section 6 for a description of 241 recognized formats. The verifier generating reports MUST generate 242 a report using the first token in the list that represents a 243 report format it is capable of generating. 245 ABNF: 247 adsp-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP 248 rep-format ) 250 ri= Requested Report Interval (plain-text; OPTIONAL; default is 251 "0"). The value is an integer that specifies an interval during 252 which no more than one report about a given type of incident 253 should be generated. A value of "0" requests a report for every 254 incident. Where the requested interval is not zero, the agent 255 generating a report SHOULD include an "Incidents:" field in the 256 generated report so the receiving agent has some indication of how 257 many reports were suppressed. 259 ABNF: 261 adsp-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT 263 ro= Requested Reports (plain-text; OPTIONAL; default is "all"). The 264 value MUST be a colon-separated list of tokens representing those 265 conditions under which a report is desired. See Section 5.2 for a 266 list of valid tags. 268 ABNF: 270 adsp-ro-type = ( "all" / "s" / "u" ) 272 adsp-ro-tag = %x72 %x6f *WSP "=" *WSP adsp-ro-type *WSP 0* ( ":" 273 *WSP adsp-ro-type ) 275 rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). 276 The value is a string the signing domain requests be included in 277 SMTP error strings when messages are rejected. 279 ABNF: 281 adsp-rs-tag = %x72 %x73 *WSP "=" qp-section 283 5. Requested Reports 285 This memo also includes, as the "ro" tags defined above, the means by 286 which the sender can request reports for specific circumstances of 287 interest. Verifiers MUST NOT generate reports for incidents that do 288 not match a requested report, and MUST ignore requests for reports 289 not included in this these lists. 291 5.1. Requested Reports for DKIM Failures 293 The following report requests are defined for DKIM keys: 295 all All reports are requested. 297 s Reports are requested for signature or key syntax errors. 299 v Reports are requested for signature verification failures or body 300 hash mismatches. 302 x Reports are requested for signatures rejected by the verifier 303 because the expiration time has passed. 305 5.2. Requested Reports for DKIM ADSP Failures 307 The following report requests are defined for DKIM keys: 309 all All reports are requested. 311 s Reports are requested for messages that have a valid [DKIM] 312 signature but do not match the published [ADSP] policy. 314 u Reports are requested for messages that have no valid [DKIM] 315 signature but do not match the published [ADSP] policy. 317 6. Reporting Formats 319 This section lists reporting formats supported by this DKIM reporting 320 mechanism. Currently only two formats are supported: 322 arf: Abuse Reporting Format, as defined in 323 [I-D.DRAFT-IETF-MARF-BASE], and as extended in Section 7. 325 smtp: An SMTP error with a string descriptive of the problem that 326 caused the DKIM verification to fail. This explicitly requests 327 evaluation of DKIM concurrent with the SMTP session, and rejection 328 (if appropriate) whenever possible rather than acceptance of the 329 message and later generation of a feedback report of some kind 330 (e.g. "arf" above) when verification fails. The presence of an 331 "rs" tag (see Section 3 and Section 4) further requests a specific 332 substring be included in the reply to ease automatic handling of 333 such errors by sending or relaying MTAs. 335 7. Extension ARF Fields for DKIM Reporting 337 The current ARF format defined in [I-D.DRAFT-IETF-MARF-BASE] lacks 338 some specific features required to do effective DKIM reporting. This 339 section describes the extensions required to do so and thus required 340 to conform to this specification. 342 7.1. New ARF Feedback Type 344 A new feedback type of "dkim" is defined as an extension to Section 345 8.2 of [I-D.DRAFT-IETF-MARF-BASE]. See Section 8.3 for details. 347 The field names listed in that draft which may appear for this new 348 feedback type include all shown in the draft except "Reported-URI" 349 and "Removal-Recipient" as they have no semantics relating to DKIM. 351 7.2. New ARF Header Names 353 The following new ARF header names are defined as extensions to 354 Section 6.2 of [I-D.DRAFT-IETF-MARF-BASE]: 356 DKIM-ADSP-DNS: The contents of the DNS TXT record retrieved when 357 trying to determine the author domain's signing practices via the 358 protocol defined in [ADSP]. 360 DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body 361 of the message as generated by the verifier. This header and 362 value MUST be present for reports using feedback type "dkim" when 363 reporting a "bodyhash" failure. 365 DKIM-Canonicalized-Headers: A base64 encoding of the canonicalized 366 header of the message as generated by the verifier. This header 367 and value MUST be present for reports using feedback type "dkim". 369 DKIM-Domain: The domain that signed the message, taken from the "d=" 370 tag of the signature. This field value SHOULD be included to ease 371 processing in those cases where reports for multiple domains may 372 be funneled into a single tool. 374 DKIM-Failure: Indicates the type of DKIM failure that is being 375 reported. The list of valid values is enumerated below. This 376 header and value MUST be present for reports using feedback type 377 "dkim". 379 DKIM-Identity: The identity of the signature that failed 380 verification, taken from the "i=" tag of the signature. This 381 header and value MUST be present for reports using feedback type 382 "dkim" when reporting anything other than an "asp" failure. 384 DKIM-Selector: The selector of the signature that failed 385 verification, taken from the "s=" tag of the signature. This 386 header and value MUST be present for reports using feedback type 387 "dkim" when reporting anything other than an "asp" failure. 389 DKIM-Selector-DNS: The contents of the DNS TXT record retrieved when 390 trying to evaluate the DKIM signature (i.e. a TXT record whose 391 name is assembled from the signature's "s=" and "d=" tags). 393 The values that are base64 encodings may contain FWS for formatting 394 purposes as per the usual header field wrapping defined in [MAIL]. 395 During decoding, any characters not in the base64 alphabet are 396 ignored so that such line wrapping does not harm the value. The ABNF 397 token "FWS" is defined in [DKIM]. 399 7.3. DKIM Failure Types 401 The list of defined DKIM failure types, used in the "DKIM-Failure:" 402 header (defined above), is as follows: 404 adsp: The message did not conform to the sender's published [ADSP] 405 signing practises. 407 bodyhash: The body hash in the signature and the body hash computed 408 by the verifier did not match. 410 granularity: The key referenced by the signature on the message was 411 not authorized for use by the sender. 413 revoked: The key referenced by the signature on the message has been 414 revoked. 416 signature: The signature on the message did not successfully verify 417 against the header hash and public key. 419 Supplementary data may be included in the form of [MAIL]-compliant 420 comments. For example, "Failure: asp" could be augmented by a 421 comment to indicate that the failed message was rejected because it 422 was not signed when it should have been. See Appendix B for 423 examples. 425 8. IANA Considerations 427 As required by [IANA-CONSIDERATIONS], this section contains registry 428 information for the new [DKIM] key tags, the new [ADSP] tags, and the 429 extensions to [I-D.DRAFT-IETF-MARF-BASE]. 431 8.1. DKIM Key Tag Registration 433 IANA is requested to update the DKIM Key Tag Specification Registry 434 to include the following new items: 436 +------+-----------------+ 437 | TYPE | REFERENCE | 438 +------+-----------------+ 439 | r | (this document) | 440 | rf | (this document) | 441 | ri | (this document) | 442 | ro | (this document) | 443 | rs | (this document) | 444 +------+-----------------+ 446 8.2. DKIM ADSP Tag Registration 448 IANA is requested to update the DKIM ADSP Tag Specification Registry 449 to include the following new items: 451 +------+-----------------+ 452 | TYPE | REFERENCE | 453 +------+-----------------+ 454 | r | (this document) | 455 | rf | (this document) | 456 | ri | (this document) | 457 | ro | (this document) | 458 | rs | (this document) | 459 +------+-----------------+ 461 8.3. Updates to ARF Feedback Types 463 The following feedback type is added to the Feedback Report Feedback 464 Type Registry: 466 Feedback Type: dkim 467 Description: DKIM failure report 468 Registration: (this document) 470 8.4. Updates to ARF Header Names 472 The following headers are added to the Feedback Report Header Names 473 Registry: 475 Field Name: DKIM-ADSP-DNS 476 Description: Retrieved DKIM ADSP record 477 Multiple Appearances: No 478 Related "Feedback-Type": dkim 480 Field Name: DKIM-Canonicalized-Body 481 Description: Canonicalized body, per DKIM 482 Multiple Appearances: No 483 Related "Feedback-Type": dkim 485 Field Name: DKIM-Canonicalized-Headers 486 Description: Canonicalized headers, per DKIM 487 Multiple Appearances: No 488 Related "Feedback-Type": dkim 490 Field Name: DKIM-Domain 491 Description: DKIM signing domain from "d=" tag 492 Multiple Appearances: No 493 Related "Feedback-Type": dkim 495 Field Name: DKIM-Failure 496 Description: Type of DKIM failure 497 Multiple Appearances: No 498 Related "Feedback-Type": dkim 500 Field Name: DKIM-Identity 501 Description: Identity from DKIM signature 502 Multiple Appearances: No 503 Related "Feedback-Type": dkim 505 Field Name: DKIM-Selector 506 Description: Selector from DKIM signature 507 Multiple Appearances: No 508 Related "Feedback-Type": dkim 509 Field Name: DKIM-Selector-DNS 510 Description: Retrieved DKIM key record 511 Multiple Appearances: No 512 Related "Feedback-Type": dkim 514 9. Security Considerations 516 Security issues with respect to these DKIM reports are similar to 517 those found in [DSN]. 519 9.1. Inherited Considerations 521 Implementors are advised to consider the Security Considerations 522 sections of [DKIM], [ADSP] and [I-D.DRAFT-IETF-MARF-BASE]. 524 9.2. Forgeries 526 These reports may be forged as easily as ordinary Internet electronic 527 mail. User agents and automatic mail handling facilities (such as 528 mail distribution list exploders) that wish to make automatic use of 529 DSNs of any kind should take appropriate precautions to minimize the 530 potential damage from denial-of-service attacks. 532 Security threats related to forged DSNs include the sending of: 534 a. A falsified DKIM failure notification when the message was in 535 fact delivered to the indicated recipient; 537 b. Falsified signature information, such as selector, domain, etc. 539 Perhaps the simplest means of mitigating this threat is to assert 540 that DKIM reports should themselves be signed. On the other hand, if 541 there's a problem with the DKIM infrastructure at the verifier, 542 signing DKIM failure reports may produce reports that aren't trusted 543 or even accepted by their intended recipients. 545 9.3. Automatic Generation 547 Automatic generation of these reports by verifying agents can cause a 548 denial-of-service attack when a large volume of e-mail is sent that 549 causes DKIM verification failures for whatever reason. 551 It is unclear what a good solution for this issue is. Limiting the 552 rate of generation of these messages may be apropos but threatens to 553 inhibit the distribution of important and possibly time-sensitive 554 information. 556 9.4. Envelope Sender Selection 558 In the case of transmitted DKIM reports in the form of a new message, 559 it is necessary to construct the message so as to avoid amplification 560 attacks, deliberate or otherwise. Thus, per Section 2 of [DSN], the 561 envelope sender address of the DKIM report SHOULD be chosen to ensure 562 that no delivery status reports will be issued in response to the 563 DKIM report itself, and MUST be chosen so that these reports will not 564 generate mail loops. Whenever an SMTP transaction is used to send a 565 DKIM report, the MAIL FROM command MUST use a NULL return address, 566 i.e. "MAIL FROM:<>". 568 9.5. Reporting Multiple Incidents 570 If it is known that a particular host generates abuse reports upon 571 certain incidents, an attacker could forge a high volume of messages 572 that will trigger such a report. The recipient of the report could 573 then be innundated with reports. This could easily be extended to a 574 distributed denial-of-service attack by finding a number of report- 575 generating servers. 577 The incident count referenced in [I-D.DRAFT-IETF-MARF-BASE] provides 578 a limited form of mitigation. The host generating reports may elect 579 to send reports only periodically, with each report representing a 580 number of identical or near-identical incidents. One might even do 581 something inverse-exponentially, sending reports for each of the 582 first ten incidents, then every tenth incident up to 100, then every 583 100th incident up to 1000, etc. until some period of relative quiet 584 after which the limitation resets. 586 The use of this for "near-identical" incidents in particular causes a 587 degradation in reporting quality, however. If for example a large 588 number of pieces of spam arrive from one attacker, a reporting agent 589 may decide only to send a report about a fraction of those messages. 590 While this averts a flood of reports to a system administrator, the 591 precise details of each incident are similarly not sent. 593 10. References 595 10.1. Normative References 597 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 598 Sender Signing Practises", RFC 5617, August 2009. 600 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 601 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 602 Signatures", RFC 4871, May 2007. 604 [I-D.DRAFT-IETF-MARF-BASE] 605 Shafranovich, Y., Levine, J., Hoffman, P., and M. 606 Kucherawy, "An Extensible Format for Email Feedback 607 Reports", I-D DRAFT-IETF-MARF-BASE, April 2010. 609 [IANA-CONSIDERATIONS] 610 Alvestrand, H. and T. Narten, "Guidelines for Writing an 611 IANA Considerations Section in RFCs", RFC 5226, May 2008. 613 [KEYWORDS] 614 Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", RFC 2119, March 1997. 617 [MAIL] Resnick, P., "Internet Message Format", RFC 2822, 618 April 2001. 620 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 621 Extensions (MIME) Part One: Format of Internet Message 622 Bodies", RFC 2045, November 1996. 624 10.2. Informative References 626 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 627 for Delivery Status Notifications", RFC 3464, 628 January 2003. 630 Appendix A. Acknowledgements 632 The author wishes to acknowledge the following for their review and 633 constructive criticism of this proposal: JD Falk 635 Appendix B. Examples 637 This section contains examples of the use of each of the extensions 638 defined by this memo. 640 B.1. Example Use of DKIM Key Extension Tags 642 A DKIM key record including use of the extensions defined by this 643 memo: 645 v=DKIM1; k=rsa; t=y; r=dkim-errors; rf=arf; ro=v:x; p=MIGfMA0GCS 646 qGSIb3DQEBAQUAA4GNADCBiQKBgQDh2vbhJTijCs2qbyJcwRCa8WqDTxI+PisFJo 647 faPtoDJy0Qn41uNayCajfKADVcLqc87sXQS6GxfchPfzx7Vh9crYdxRbN/o/URCu 648 ZsKmym1i1IPTwRLcXSnuKS0XDs1eRW2WQHGYlXksUDqSHWOS3ZO1W5t/FLcZHpIl 649 l/80xs4QIDAQAB 651 Example 1: DKIM key record using these extensions 653 This example DKIM key record contains the following data in addition 654 to the basic DKIM key data: 656 o Reports about signature evaluation failures should be send to the 657 address "dkim-errors" at the sender's domain; 659 o The sender's domain requests reports in the "arf" format; 661 o Only reports about signature verification failures and expired 662 signatures should be generated. 664 B.2. Example Use of DKIM ADSP Extension Tags 666 A DKIM ADSP record including use of the extensions defined by this 667 memo: 669 dkim=all; r=dkim-adsp-errors; rf=arf; ro=u 671 Example 2: DKIM ADSP record using these extensions 673 This example ADSP record makes the following assertions: 675 o The sending domain (i.e. the one that is advertising this policy) 676 signs all mail it sends; 678 o Reports about ADSP evaluation failures should be send to the 679 address "dkim-adsp-errors" at the sender's domain; 681 o The sender's domain requests reports in the "arf" format; 682 o Only reports about unsigned messages should be generated. 684 B.3. Example Use of ARF Extension Headers 686 An ARF-formatted report using some of the proposed ARF extension 687 fields: 689 From: arf-daemon@example.com 690 To: recipient@example.net 691 Subject: This is a test 692 Date: Wed, 14 Apr 2010 12:17:45 -0700 (PDT) 693 MIME-Version: 1.0 694 Content-Type: multipart/report; report-type=feedback-report; 695 boundary="part1_13d.2e68ed54_boundary" 697 --part1_13d.2e68ed54_boundary 698 Content-Type: text/plain; charset="US-ASCII" 699 Content-Transfer-Encoding: 7bit 701 This is an email abuse report for an email message received 702 from IP 192.0.2.1 on Wed, 14 Apr 2010 12:15:31 PDT. For more 703 information about this format please see 704 http://www.mipassoc.org/arf/. 706 --part1_13d.2e68ed54_boundary 707 Content-Type: message/feedback-report 709 Feedback-Type: dkim 710 User-Agent: SomeDKIMFilter/1.0 711 Version: 1.0 712 Original-Mail-From: 713 Original-Rcpt-To: 714 Received-Date: Wed, 14 Apr 2010 12:15:31 -0700 (PDT) 715 Source-IP: 192.0.2.1 716 Authentication-Results: mail.example.com; dkim=fail 717 header.d=example.net 718 Reported-Domain: example.net 719 DKIM-Domain: example.net 720 DKIM-Failure: bodyhash 722 --part1_13d.2e68ed54_boundary 723 Content-Type: message/rfc822 725 DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256; 726 s=testkey; d=example.net; h=From:To:Subject:Date; 727 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 728 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 729 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 730 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 731 4bmp/YzhwvcubU4= 732 Received: from smtp-out.example.net by mail.example.com 733 with SMTP id o3F52gxO029144; 734 Wed, 14 Apr 2010 12:15:31 -0700 (PDT) 735 Received: from internal-client-001.example.com 736 by mail.example.com 737 with SMTP id o3F3BwdY028431; 738 Wed, 14 Apr 2010 12:12:09 -0700 (PDT) 739 From: randomuser@example.net 740 To: user@example.com 741 Date: Wed, 14 Apr 2010 12:12:09 -0700 (PDT) 742 Subject: This is a test 744 Hi, just making sure DKIM is working! 746 --part1_13d.2e68ed54_boundary-- 748 Example 3: Example ARF report using these extensions 750 This example ARF message is making the following assertion: 752 o DKIM verification of the signature added within "example.net" 753 failed when it was processed on arrival at "mail.example.com". 755 o The cause for the verification failure was a mismatch between the 756 body contents observed at the verifier and the body hash contained 757 in the signature. 759 Appendix C. Public Discussion 761 [REMOVE BEFORE PUBLICATION] 763 Public discussion of this proposed specification is handled via the 764 mail-vet-discuss@mipassoc.org mailing list. The list is open. 765 Access to subscription forms and to list archives can be found at 766 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 768 Author's Address 770 Murray S. Kucherawy 771 Cloudmark 772 128 King St., 2nd Floor 773 San Francisco, CA 94107 774 US 776 Phone: +1 415 946 3800 777 Email: msk@cloudmark.com