idnits 2.17.1 draft-ietf-marf-base-06.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 : ---------------------------------------------------------------------------- -- 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 date (May 21, 2010) is 5086 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) == Missing Reference: 'CFWS' is mentioned on line 370, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4288 (ref. 'MIME-REG') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3462 (ref. 'REPORT') (Obsoleted by RFC 6522) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARF Working Group Y. Shafranovich 3 Internet-Draft ShafTek Enterprises 4 Intended status: Standards Track J. Levine 5 Expires: November 22, 2010 Taughannock Networks 6 M. Kucherawy 7 Cloudmark 8 May 21, 2010 10 An Extensible Format for Email Feedback Reports 11 draft-ietf-marf-base-06 13 Abstract 15 This document defines an extensible format and MIME type that may be 16 used by mail operators to report feedback about received email to 17 other parties. This format is intended as a machine-readable 18 replacement for various existing report formats currently used in 19 Internet email. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 22, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3.2. E-mail Specific . . . . . . . . . . . . . . . . . . . 4 61 2. Format of Email Feedback Reports . . . . . . . . . . . . . . . 5 62 3. The 'message/feedback-report' Content Type . . . . . . . . . . 7 63 3.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Optional Fields Appearing Once . . . . . . . . . . . . . . 8 65 3.3. Optional Fields Appearing Multiple Times . . . . . . . . . 8 66 3.4. Notes About URIs . . . . . . . . . . . . . . . . . . . . . 9 67 3.5. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 68 4. Handling Malformed Reports . . . . . . . . . . . . . . . . . . 12 69 5. Transport Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 7.1. MIME Type Registration of 'message/feedback-report' . . . 15 73 7.2. Feedback Report Header Fields . . . . . . . . . . . . . . 16 74 7.3. Feedback Report Type Values . . . . . . . . . . . . . . . 19 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 8.1. Inherited from RFC3462 . . . . . . . . . . . . . . . . . . 21 77 8.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 21 78 8.3. Attacks Against Authentication Methods . . . . . . . . . . 21 79 8.4. Intentionally Malformed Reports . . . . . . . . . . . . . 22 80 8.5. Omitting Data from ARF Reports . . . . . . . . . . . . . . 22 81 8.6. Automatically Generated ARF Reports . . . . . . . . . . . 22 82 8.7. Attached Malware . . . . . . . . . . . . . . . . . . . . . 22 83 8.8. The User-Agent Field . . . . . . . . . . . . . . . . . . . 22 84 8.9. Malformed Messages . . . . . . . . . . . . . . . . . . . . 23 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 89 Appendix B. Sample Feedback Reports . . . . . . . . . . . . . . . 27 90 B.1. Simple Report for Email Abuse without Optional Headers . . 27 91 B.2. Full Report for Email Abuse with All Headers . . . . . . . 29 92 Appendix C. Public Discussion, History and Support . . . . . . . 31 93 Appendix D. Document History . . . . . . . . . . . . . . . . . . 32 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 96 1. Introduction 98 As the spam problem continues to expand and potential solutions 99 evolve, mail operators are increasingly exchanging abuse reports 100 among themselves and other parties. However, different operators 101 have defined their own formats, and thus the receivers of these 102 reports are forced to write custom software to interpret each. In 103 addition, many operators use various other report formats to provide 104 non-abuse-related feedback about processed email. This memo uses the 105 "multipart/report" content type defined in [REPORT], and in that 106 context defines a standard extensible format by creating the 107 "message/feedback-report" [MIME] type for these reports. 109 While there has been previous work in this area (e.g. [STRADS-BCP] 110 and [ASRG-ABUSE]), none of them have yet been successful. It is 111 hoped that this document will have a better fate. 113 This format is intended primarily as an Abuse Reporting Format (ARF) 114 for reporting email abuse but also includes support for direct 115 feedback via end user mail clients, reports of some types of virus 116 activity, and some similar issues. This memo also contains provision 117 for extensions should other specific types of reports be desirable in 118 the future. 120 This document only defines the format and [MIME] content type to be 121 used for these reports. Determination of where these reports should 122 be sent, validation of their contents and how trust among report 123 generators and report recipients is established are outside the scope 124 of this document. It is assumed that best practices will evolve over 125 time, and will be codified in future documents. 127 1.1. Purpose 129 The reports defined in this document are intended to inform mail 130 operators about: 132 o email abuse originating from their networks; 134 o potential issues with the perceived quality of outbound mail, such 135 as email service providers sending mail that attracts the 136 attention of automated abuse detection systems. 138 Please note that while the parent "multipart/report" content type 139 defined in [REPORT] is used for all kinds of administrative messages, 140 this format is intended specifically for communications among 141 providers regarding email abuse and related issues, and SHOULD NOT be 142 used for other reports. 144 1.2. Requirements 146 The following requirements are necessary for feedback reports (the 147 actual specification is defined later in this document): 149 o They must be both human and machine readable; 151 o A copy of the original email message (both body and header) or the 152 message header must be enclosed in order to allow the receiver to 153 handle the report properly; 155 o The machine readable section must provide ability for the report 156 generators to share meta-data with receivers; 158 o The format must be extensible. 160 1.3. Definitions 162 This section defines various terms used throughout this document. 164 1.3.1. General 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [KEYWORDS]. 170 1.3.2. E-mail Specific 172 [EMAIL-ARCH] introduces several terms and concepts that are used in 173 this memo, and thus readers are advised to become familiar with it as 174 well. 176 2. Format of Email Feedback Reports 178 To satisfy the requirements, an email feedback report is defined as a 179 [MIME] message with a top-level MIME content type of "multipart/ 180 report" (as defined in [REPORT]). The following apply: 182 a. The "report-type" parameter of the "multipart/report" type is set 183 to "feedback-report"; 185 b. The first MIME part of the message contains a human readable 186 description of the report and MUST be included. 188 c. The second MIME part of the message is a machine-readable section 189 with the content type of "message/feedback-report" (defined later 190 in this memo) and MUST be included. This section is intended to 191 convey meta-data about the report in question that may not be 192 readily available from the included email message itself. 194 d. The third MIME part of the message is either of type "message/ 195 rfc822" (as defined in [MIME-TYPES] and contains the original 196 message in its entirety, OR is of type "text/rfc822-headers" (as 197 defined in [REPORT] and contains a copy of the entire header 198 block from the original message. This part MUST be included 199 (contrary to [REPORT]). While some operators may choose to 200 modify or redact this portion for privacy or legal reasons, it is 201 RECOMMENDED that the entire original email message be included 202 without any modification as such modifications can impede 203 forensic work by the recipient of this report. See Section 8 for 204 further discussion. 206 e. Except as discussed below, each feedback report MUST be related 207 to only a single email message. Summary and aggregate formats 208 are outside of the scope of this specification. 210 f. The Subject header field of the feedback report SHOULD be the 211 same as the included email message about which the report is 212 being generated. If it differs, the difference MUST be limited 213 to only a typical forwarding prefix used by MUAs such as "FW:". 214 (Many smaller operators using MUAs for abuse handling rely on the 215 subject lines for processing.) 217 g. The primary evidence of the abuse being reported is found in the 218 third part of the report, which contains the original message. 219 The second part contains additional derived data that may help 220 the receiver, but in terms of selecting actionable report data, 221 report recipients SHOULD use the content of the third part first, 222 then data from the second part. The first part is meant to 223 contain explanantory text for human use but is not itself a part 224 of the report, and SHOULD NOT be used if it is in conflict with 225 the other parts. 227 3. The 'message/feedback-report' Content Type 229 A new [MIME] content type called "message/feedback-report" is 230 defined. This content type provides a machine-readable section 231 intended to let the report generator convey meta-data to the report 232 receiver. The intent of this section is to convey information that 233 may not be obvious or may not be easily extracted from the original 234 email message body or header. 236 The body of this content type consists of multiple "fields" formatted 237 according to the ABNF of [MAIL] header fields. This section defines 238 the initial set of fields provided by this specification. Additional 239 fields may be registered according to the procedure described later 240 in this memo. Although these fields have a syntax similar to those 241 of mail message header fields, they are semantically distinct; hence 242 they SHOULD NOT be repeated as header fields of the message 243 containing the report. Note that these fields represent information 244 that the receiver is asserting about the report in question, but are 245 not necessarily verifiable. Report receivers MUST NOT assume that 246 these assertions are always accurate. 248 Note that the above limitation in no way restricts the use of message 249 header fields that are registered in the IANA header field registry 250 with the same field names. 252 3.1. Required Fields 254 The following report header fields MUST appear exactly once: 256 o "Feedback-Type" contains the type of feedback report (as defined 257 in the corresponding IANA registry and later in this memo). This 258 is intended to let report parsers distinguish among different 259 types of reports. 261 o "User-Agent" indicates the name and version of the software 262 program that generated the report. The format of this field MUST 263 follow section 14.43 of [HTTP]. This field is for documentation 264 only; there is no registry of user agent names or versions, and 265 report receivers SHOULD NOT expect user agent names to belong to a 266 known set. 268 o "Version" indicates the version of specification that the report 269 generator is using to generate the report. The version number in 270 this specification is set to "0.1". [NOTE TO RFC EDITOR: This 271 should be changed to "1" at time of publication.] 273 3.2. Optional Fields Appearing Once 275 The following header fields are optional and MUST NOT appear more 276 than once: 278 o "Original-Envelope-Id" contains the envelope ID string used in the 279 original [SMTP] transaction (see section 2.2.1 of [DSN]). 281 o "Original-Mail-From" contains a copy of the email address used in 282 the MAIL FROM portion of the original SMTP transaction. The 283 format of this field is defined in section 4.1.2 of [SMTP] as 284 "Reverse-path". 286 o "Arrival-Date" indicates the date and time at which the original 287 message was received by the MTA of the generating ADMD 288 (Administrative Management Domain). This field MUST be formatted 289 as per section 3.3 of [MAIL]. 291 o "Reporting-MTA" indicates the name of the MTA generating this 292 feedback report. This field is defined in section 2.2.2 of [DSN], 293 except that it is an optional field in this report. 295 o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which 296 the original message was received. Addresses MUST be formatted as 297 per section 4.1.3 of [SMTP]. 299 o "Incidents" contains an unsigned 32-bit integer indicating the 300 number of incidents this report represents. The absence of this 301 field implies the report covers a single incident. 303 The historic field "Received-Date" SHOULD also be accepted and 304 interpreted identically to "Arrival-Date". However, if both are 305 present, the report is malformed and SHOULD be treated as described 306 in Section 4. 308 3.3. Optional Fields Appearing Multiple Times 310 The following set of header fields are optional and may appear any 311 number of times as appropriate: 313 o "Authentication-Results" indicates the result of one or more 314 authentication checks run by the report generator. The format of 315 this field is is defined in [AUTH-RESULTS]. Report receivers 316 should note that this field only indicates an assertion made by 317 the report generator. 319 o "Original-Rcpt-To" includes a copy of the email address used in 320 the RCPT TO portion of the original [SMTP] transaction. The 321 format of this field is a "Reverse-path" defined in section 4.1.2 322 of that memo. This field SHOULD be repeated for every SMTP 323 recipient seen by the report generator. 325 o "Reported-Domain" includes a domain name that the report generator 326 believes to be relevant to the report, e.g. the domain whose 327 apparent actions provoked the generation of the report. It is 328 unspecified how the report generator determines this information, 329 and thus the report receiver cannot be certain how it was chosen. 330 It is often used as a means of suggesting to the report receiver 331 how this report might be handled. In cases where the derivation 332 is not obvious, the report generator is encouraged to clarify in 333 the text section of the report. Domain format is defined in 334 section 2.3.1 of [DNS]. 336 o "Reported-URI" indicates a URI that the report generator believes 337 to be relevant to the report, e.g. a suspect URI that was found in 338 the message that caused the report to be generated. The same 339 caveats about the origin of the value of "Reported-Domain" apply 340 to this field. URI format is defined in [URI]. 342 3.4. Notes About URIs 344 Implementors should be aware that the Reported-URI field can carry 345 many different types of data depending on the URI scheme used. For 346 more information, please consult the URI Schemes registry maintained 347 by IANA. 349 Furthermore, it is outside the scope of this standard whether the 350 data carried in this field implies any additional information. 351 Implementors may negotiate their own agreements surrounding the 352 interpretation of this data. 354 3.5. Formal Definition 356 The formal definition of the contents of a "message/feedback-report" 357 media type using [ABNF] is as follows: 359 feedback-report = *( feedback-type / user-agent / version ) 360 opt-fields-once 361 *( opt-fields-many ) 362 *( ext-field ) 364 feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF 365 ; the "token" must be a registered feedback type as 366 ; described elsewhere in this document 368 user-agent = "User-Agent:" [CFWS] product *( CFWS product ) 370 [CFWS] CRLF 372 version = "Version:" [CFWS] %x31-%x39 *DIGIT [CFWS] CRLF 373 ; as described above 375 opt-fields-once = [ arrival-date ] 376 [ incidents ] 377 [ original-envelope-id ] 378 [ original-mail-from ] 379 [ reporting-mta ] 380 [ source-ip ] 382 arrival-date = "Arrival-Date:" [CFWS] date-time CRLF 384 incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF 385 ; must be a 32-bit unsigned integer 387 original-envelope-id = "Original-Envelope-Id:" [CFWS] 388 envelope-id [CFWS] CRLF 390 original-mail-from = "Original-Mail-From:" [CFWS] 391 reverse-path [CFWS] CRLF 393 reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";" 394 [CFWS] mta-name [CFWS] CRLF 396 source-ip = "Source-IP:" [CFWS] 397 ( IPv4-address-literal / 398 IPv6-address-literal ) [CFWS] CRLF 400 opt-fields-many = [ authres-header ] 401 [ original-rcpt-to ] 402 [ reported-domain ] 403 [ reported-uri ] 405 original-rcpt-to = "Original-Rcpt-To:" [CFWS] 406 forward-path [CFWS] CRLF 408 reported-domain = "Reported-Domain:" [CFWS] 409 domain [CFWS] CRLF 411 reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF 413 ext-field = field-name ":" unstructured 415 A set of fields satisfying this ABNF may appear in the transmitted 416 message in any order. 418 "CRLF" and "DIGIT" are imported from [ABNF]. 420 "token" is imported from [MIME]. 422 "product" is imported from [HTTP]. 424 "field-name", "unstructured", "CFWS", "date-time" and "domain" are 425 imported from [MAIL]. 427 "envelope-id", "mta-name-type" and "mta-name" are imported from 428 [DSN]. 430 "reverse-path", "forward-path", "local-part", "IPv4-address-literal" 431 and "IPv6-address-literal" are imported from [SMTP]. 433 "URI" is imported from [URI]. 435 "authres-header" is imported from [AUTH-RESULTS]. 437 "ext-field" refers to extension fields, which are discussed in 438 Section 6. 440 4. Handling Malformed Reports 442 When an agent that accepts and handles ARF messages receives a 443 message that purports (by MIME type) to be an ARF message but 444 syntactically deviates from this specification, that agent SHOULD 445 ignore or reject the message. Where rejection is performed, the 446 rejection notice (either via an [SMTP] reply or generation of a 447 [DSN]) SHOULD identify the specific cause for the rejection. 449 See Section 8.9 for further discussion. 451 5. Transport Considerations 453 [DSN] requires that its reports be sent with the empty [SMTP] 454 envelope sender to avoid bounce loops. A similar requirement was 455 considered for this specification, but it seems unlikely that an ARF 456 report would be generated in response to receipt of an ARF report, 457 and furthermore such a requirement would prevent an ARF generator 458 from ever determining that an ARF report was not actually received. 460 On the other hand, if an ARF report is generated without the empty 461 envelope sender and is sent to an address that actually does not 462 work, then the generating address can also be overwhelmed by DSNs as 463 a denial of service attack (see Section 8.6). 465 This specification therefore makes no requirement related to the 466 envelope sender of a generated report. Operators will have to 467 consider what envelope sender to use within the context of their own 468 installations. 470 6. Extensibility 472 Like many other formats and protocols, this format may need to be 473 extended over time to fit the ever changing landscape of the 474 Internet. Therefore, extensibility is provided via two IANA 475 registries: one for feedback types and a second for report header 476 fields. The feedback type registry is to be used in conjunction with 477 the "Feedback-Type" field above. The header name registry is 478 intended for registration of new meta-data fields to be used in the 479 machine readable portion (part 2) of this format. Please note that 480 version numbers do not change with new field registrations unless a 481 new specification of this format is published. Also note that all 482 new field registrations may only be registered as optional fields. 483 Any new required fields REQUIRE a new version of this specification 484 to be published. 486 In order to encourage extensibility and interoperability of this 487 format, implementors MUST ignore any fields or report types they do 488 not explicitly support. 490 Additional report types (extension report types) or report header 491 fields might be defined in the future by later revisions to this 492 specification, or by registrations as described above. Such types 493 and fields MUST be registered as described above and published in an 494 Open Specification such as an RFC. 496 Experimental report types and report header fields MUST only be used 497 between ADMDs that have explicitly consented to use them. These 498 names and the parameters associated with them are not documented in 499 RFCs. Therefore, they are subject to change at any time and not 500 suitable for general use. 502 7. IANA Considerations 504 IANA is requested to register a new [MIME] type and create three new 505 registries, as described below. 507 7.1. MIME Type Registration of 'message/feedback-report' 509 This section provides the media type registration application from 510 [MIME-REG] for processing by IANA: 512 To: ietf-types@iana.org 514 Subject: Registration of media type message/feedback-report 516 Type name: message 518 Subtype name: feedback-report 520 Required parameters: none 522 Optional parameters: none 524 Encoding considerations: "7bit" encoding is sufficient and MUST be 525 used to maintain readability when viewed by non-MIME mail readers. 527 Security considerations: See Section 8 of [this document]. 529 Interoperability considerations: Implementors MUST ignore any fields 530 they do not support. 532 Published specification: [this document] 534 Applications that use this media type: Abuse helpdesk software for 535 ISPs, mail service bureaus, mail certifiers, and similar 536 organizations 538 Additional information: none 540 Person and email address to contact for further information: 542 Yakov Shafranovich 544 Murray S. Kucherawy 546 Intended usage: COMMON 548 Author: 550 Yakov Shafranovich 552 John Levine 554 Murray S. Kucherawy 556 Change controller: IESG 558 7.2. Feedback Report Header Fields 560 IANA is requested to create the "Feedback Report Header Fields" 561 registry. This registry will contain header fields for use in 562 feedback reports, as defined by this memo. 564 New registrations or updates MUST be published in accordance with the 565 "Specification Required" guidelines as described in 566 [IANA-CONSIDERATIONS]. Any new field thus registered is considered 567 optional by this specification unless a new version of this memo is 568 published. 570 New registrations and updates MUST contain the following information: 572 1. Name of the field being registered or updated 574 2. Short description of the field 576 3. Whether the field can appear more than once 578 4. To which feedback type(s) this field applies (or "any") 580 5. The document in which the specification of the field is published 582 6. New or updated status, which MUST be one of: 584 current: The field is in current use 586 deprecated: The field is in current use but its use is 587 discouraged 589 historic: The field is no longer in current use 591 An update may make a notation on an existing registration indicating 592 that a registered field is historic or deprecated if appropriate. 594 The initial registry should contain these values: 596 Field Name: Arrival-Date 597 Description: date/time the original message was received 598 Multiple Appearances: No 599 Related "Feedback-Type": any 600 Published in: [this document] 601 Status: current 603 Field Name: Authentication-Results 604 Description: results of authentication check(s) 605 Multiple Appearances: Yes 606 Related "Feedback-Type": any 607 Published in: [this document] 608 Status: current 610 Field Name: Feedback-Type 611 Description: registered feedback report type 612 Multiple Appearances: No 613 Related "Feedback-Type": N/A 614 Published in: [this document] 615 Status: current 617 Field Name: Incidents 618 Description: expression of how many similar incidents are 619 represented by this report 620 Multiple Appearances: No 621 Related "Feedback-Type": any 622 Published in: [this document] 623 Status: current 625 Field Name: Original-Mail-From 626 Description: email address used in the MAIL FROM portion of the 627 original SMTP transaction 628 Multiple Appearances: No 629 Related "Feedback-Type": any 630 Published in: [this document] 631 Status: current 632 Field Name: Original-Rcpt-To 633 Description: email address used in the RCPT TO portion of the 634 original SMTP transaction 635 Multiple Appearances: Yes 636 Related "Feedback-Type": any 637 Published in: [this document] 638 Status: current 640 Field Name: Received-Date 641 Description: date/time the original message was received 642 (replaced by "Arrival-Date") 643 Multiple Appearances: No 644 Related "Feedback-Type": any 645 Published in: [this document] 646 Status: historic 648 Field Name: Reported-Domain 649 Description: a domain name the report generator considers to 650 be key to the message about which a report is 651 being generated 652 Multiple Appearances: Yes 653 Related "Feedback-Type": any 654 Published in: [this document] 655 Status: current 657 Field Name: Reported-URI 658 Description: a URI the report generator considers to be key 659 to the message about which a report is being 660 generated 661 Multiple Appearances: Yes 662 Related "Feedback-Type": any 663 Published in: [this document] 664 Status: current 666 Field Name: Reporting-MTA 667 Description: MTA generating this report 668 Multiple Appearances: No 669 Related "Feedback-Type": any 670 Published in: [this document] 671 Status: current 672 Field Name: Source-IP 673 Description: IPv4 or IPv6 address from which the original message 674 was received 675 Multiple Appearances: No 676 Related "Feedback-Type": any 677 Published in: [this document] 678 Status: current 680 Field Name: User-Agent 681 Description: name and version of the program generating the 682 report 683 Multiple Appearances: No 684 Related "Feedback-Type": any 685 Published in: [this document] 686 Status: current 688 Field Name: Version 689 Description: version of specification used 690 Multiple Appearances: No 691 Related "Feedback-Type": any 692 Published in: [this document] 693 Status: current 695 7.3. Feedback Report Type Values 697 IANA is requested to create the "Feedback Report Type Values" 698 registry. This registry will contain feedback types for use in 699 feedback reports, defined by this memo. 701 New registrations or updates MUST be published in accordance with the 702 "Specification Required" guidelines as described in 703 [IANA-CONSIDERATIONS]. Any new field thus registered is considered 704 optional by this specification unless a new version of this memo is 705 published. 707 New registrations MUST contain the following information: 709 1. Name of the feedback type being registered 711 2. Short description of the feedback type 713 3. The document in which the specification of the field is published 715 4. New or updated status, which MUST be one of: 717 current: The field is in current use 719 deprecated: The field is in current use but its use is 720 discouraged 722 historic: The field is no longer in current use 724 The initial registry should contain these values: 726 Feedback Type Name: abuse 727 Description: unsolicited email or some other kind of email abuse 728 Published in: [this document] 729 Status: current 731 Feedback Type Name: fraud 732 Description: indicates some kind of fraud or phishing activity 733 Published in: [this document] 734 Status: current 736 Feedback Type Name: other 737 Description: any other feedback that does not fit into other 738 registered types 739 Published in: [this document] 740 Status: current 742 Feedback Type Name: virus 743 Description: report of a virus found in the originating message 744 Published in: [this document] 745 Status: current 747 8. Security Considerations 749 The following security considerations apply when generating or 750 processing a feedback report: 752 8.1. Inherited from RFC3462 754 All of the Security Considerations from [REPORT] are inherited here. 756 8.2. Interpretation 758 This specification describes a report format. The authentication and 759 validity of the content of the report SHOULD be established through 760 other means. The content of an unvetted report could be wrong, 761 incomplete or deliberately false, including the alleged abuse 762 incident in the third part, derived data in the second part or the 763 human readable first part. 765 There will be some desire to perform some actions in an automated 766 fashion in order to enact timely responses to common feedback 767 reports. Caution must be taken, however, as there is no substantial 768 security around the content of these reports. An attacker could 769 craft a report meant to generate undesirable actions on the part of a 770 report recipient. 772 It is suggested that the origin of an ARF report be vetted, such as 773 by using common message authentication schemes like [SMIME], [DKIM], 774 [SPF] or [SENDERID], prior to the undertaking of any kind of 775 automated action in response to receipt of the report. In 776 particular, S/MIME offers the strongest authentication and the cost 777 of key exchange is assumed in the process of establishing a bi- 778 lateral reporting relationship that uses this specification; however, 779 it is not as transparent as the others and thus will interfere with 780 the parsing capabilities of code that is designed specifically to 781 handle multipart/report messages. 783 The details of the required validation to achieve this are a matter 784 of local policy and are thus outside the scope of this specification. 786 8.3. Attacks Against Authentication Methods 788 If an attack becomes known against an authentication method, clearly 789 then the agent verifying that method can be fooled into thinking an 790 inauthentic message is authentic, and thus the value of this header 791 field can be misleading. It follows that any attack against an 792 authentication method that might be used to protect the authenticity 793 of an abuse report is also a security consideration here. 795 8.4. Intentionally Malformed Reports 797 It is possible for an attacker to generate an ARF message field that 798 is extraordinarily large or otherwise malformed in an attempt to 799 discover or exploit weaknesses in recipient parsing code. 800 Implementors SHOULD thoroughly verify all such messages and be robust 801 against intentionally as well as unintentionally malformed messages. 803 8.5. Omitting Data from ARF Reports 805 The sending of these reports can reveal possibly private information 806 about the person sending the report. For example, such a report sent 807 in response to a mailing list posting will reveal to the report 808 recipient a valid email address on the list that might otherwise have 809 remained hidden. 811 For this reason, report generators might wish to redact portions of 812 the report to conceal private information. Doing so could be 813 necessary where privacy trumps operational necessity, but as 814 mentioned in Section 2 it might impede a timely or meaningful 815 response from the report recipient. 817 8.6. Automatically Generated ARF Reports 819 Systems have been implemented that generate ARF reports automatically 820 in response to an event. For example, software monitoring a honeypot 821 email address might generate an ARF report immediately upon delivery 822 of any message to it. An attacker that becomes aware of such a 823 configuration can exploit it to attack an ARF recipient with 824 automatically generated ARF reports. 826 8.7. Attached Malware 828 As this format is sometimes used to automatically report malware, ARF 829 processors (human or otherwise) SHOULD ensure that attachments are 830 processed in a manner appropriate for unverified and potentially 831 hostile data. 833 8.8. The User-Agent Field 835 Further to Section 8.2, the User-Agent field is an assertion of the 836 generating software and is neither specified in this memo nor derived 837 from the message represented in the third part of the report. It is 838 intended for documentation and debugging, and since it is trivially 839 forged by a malicious agent, it SHOULD NOT be interpreted by 840 recipients. 842 8.9. Malformed Messages 844 Further to the discussion in Section 4, there might be cases where an 845 ARF processing agent elects to accept messages not consistent with 846 this specification, such as during transition periods where some 847 fields are moving toward "historic" or "deprecated" status, or the 848 introduction of new non-standard extension or experimental fields. 849 Such choices need to be implemented with extreme caution; where two 850 different fields have related meaning (e.g. "Received-Date", which 851 is historic, and "Arrival-Date", which is current), an attacker could 852 craft a report that makes a confusing claim in an attempt to exploit 853 such liberal parsing logic. 855 9. References 857 9.1. Normative References 859 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 860 Specifications: ABNF", RFC 5234, January 2008. 862 [AUTH-RESULTS] 863 Kucherawy, M., "Message Header Field for Indicating 864 Message Authentication Status", RFC 5451, April 2009. 866 [DNS] Mockapetris, P., "Domain Names -- Implementation and 867 Specification", RFC 1035, November 1987. 869 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 870 for Delivery Status Notifications", RFC 3464, 871 January 2003. 873 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 874 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 875 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 877 [KEYWORDS] 878 Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", RFC 2119, March 1997. 881 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 882 October 2008. 884 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 885 Extensions (MIME) Part One: Format of Internet Message 886 Bodies", RFC 2045, November 1996. 888 [MIME-REG] 889 Freed, N. and J. Klensin, "Media Type Specifications and 890 Registration Procedures", RFC 4288, December 2005. 892 [MIME-TYPES] 893 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 894 Extensions (MIME) Part Two: Media Types", RFC 2046, 895 November 1996. 897 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 898 Reporting of Mail System Administrative Messages", 899 RFC 3462, January 2003. 901 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 902 October 2008. 904 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 905 Resource Identifier (URI): Generic Syntax", RFC 3986, 906 January 2005. 908 9.2. Informative References 910 [ASRG-ABUSE] 911 Anti-Spam Research Group (ASRG) of the Internet Research 912 Task Force (IRTF), "Abuse Reporting Standards Subgroup of 913 the ASRG", May 2005. 915 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 916 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 917 Signatures", RFC 4871, May 2007. 919 [EMAIL-ARCH] 920 Crocker, D., "Internet Mail Architecture", RFC 5598, 921 July 2009. 923 [IANA-CONSIDERATIONS] 924 Narten, T. and H. Alvestrand, "Guidelines for Writing an 925 IANA Considerations Section in RFCs", RFC 5226, May 2008. 927 [SENDERID] 928 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 929 RFC 4406, April 2006. 931 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 932 Mail Extensions (S/MIME) Version 3.2 Message 933 Specification", RFC 5751, January 2010. 935 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 936 for Authorizing Use of Domains in E-Mail, Version 1", 937 RFC 4408, April 2006. 939 [STRADS-BCP] 940 Crissman, G., "Proposed Spam Reporting BCP Document", 941 May 2005. 943 Appendix A. Acknowledgements 945 The authors would like to thank many of the members of the email 946 community who provided helpful comments and suggestions for this 947 document including many of the participants in ASRG, IETF and MAAWG 948 activities, and all of the members of the abuse-feedback-report 949 public mailing list. 951 Appendix B. Sample Feedback Reports 953 This section presents some examples of the use of this message format 954 to report feedback about an arriving message. 956 B.1. Simple Report for Email Abuse without Optional Headers 958 Simple report: 960 From: 961 Date: Thu, 8 Mar 2005 17:40:36 EDT 962 Subject: FW: Earn money 963 To: 964 MIME-Version: 1.0 965 Content-Type: multipart/report; report-type=feedback-report; 966 boundary="part1_13d.2e68ed54_boundary" 968 --part1_13d.2e68ed54_boundary 969 Content-Type: text/plain; charset="US-ASCII" 970 Content-Transfer-Encoding: 7bit 972 This is an email abuse report for an email message received from IP 973 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information 974 about this format please see http://www.mipassoc.org/arf/. 976 --part1_13d.2e68ed54_boundary 977 Content-Type: message/feedback-report 979 Feedback-Type: abuse 980 User-Agent: SomeGenerator/1.0 981 Version: 0.1 [NOTE TO RFC EDITOR: CHANGE TO "1" FOR PUBLICATION] 983 --part1_13d.2e68ed54_boundary 984 Content-Type: message/rfc822 985 Content-Disposition: inline 987 Received: from mailserver.example.net 988 (mailserver.example.net [192.0.2.1]) 989 by example.com with ESMTP id M63d4137594e46; 990 Thu, 08 Mar 2005 14:00:00 -0400 991 From: 992 To: 993 Subject: Earn money 994 MIME-Version: 1.0 995 Content-type: text/plain 996 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 997 Date: Thu, 02 Sep 2004 12:31:03 -0500 999 Spam Spam Spam 1000 Spam Spam Spam 1001 Spam Spam Spam 1002 Spam Spam Spam 1003 --part1_13d.2e68ed54_boundary-- 1005 Example 1: Required fields only 1007 Illustration of a feedback report generated according to this 1008 specification. Only the required fields are used. 1010 B.2. Full Report for Email Abuse with All Headers 1012 A full email abuse report: 1014 From: 1015 Date: Thu, 8 Mar 2005 17:40:36 EDT 1016 Subject: FW: Earn money 1017 To: 1018 MIME-Version: 1.0 1019 Content-Type: multipart/report; report-type=feedback-report; 1020 boundary="part1_13d.2e68ed54_boundary" 1022 --part1_13d.2e68ed54_boundary 1023 Content-Type: text/plain; charset="US-ASCII" 1024 Content-Transfer-Encoding: 7bit 1026 This is an email abuse report for an email message received from IP 1027 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information 1028 about this format please see http://www.mipassoc.org/arf/. 1030 --part1_13d.2e68ed54_boundary 1031 Content-Type: message/feedback-report 1033 Feedback-Type: abuse 1034 User-Agent: SomeGenerator/1.0 1035 Version: 0.1 1036 Original-Mail-From: 1037 Original-Rcpt-To: 1038 Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT 1039 Reporting-MTA: dns; mail.example.com 1040 Source-IP: 192.0.2.1 1041 Authentication-Results: mail.example.com; 1042 spf=fail smtp.mail=somespammer@example.com 1043 Reported-Domain: example.net 1044 Reported-Uri: http://example.net/earn_money.html 1045 Reported-Uri: mailto:user@example.com 1046 Removal-Recipient: user@example.com 1048 --part1_13d.2e68ed54_boundary 1049 Content-Type: message/rfc822 1050 Content-Disposition: inline 1052 From: 1053 Received: from mailserver.example.net (mailserver.example.net 1054 [192.0.2.1]) by example.com with ESMTP id M63d4137594e46; 1055 Thu, 08 Mar 2005 14:00:00 -0400 1057 To: 1058 Subject: Earn money 1059 MIME-Version: 1.0 1060 Content-type: text/plain 1061 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 1062 Date: Thu, 02 Sep 2004 12:31:03 -0500 1064 Spam Spam Spam 1065 Spam Spam Spam 1066 Spam Spam Spam 1067 Spam Spam Spam 1068 --part1_13d.2e68ed54_boundary-- 1070 Example 1: Generic abuse report with maximum returned information 1072 A contrived example in which the report generator has returned all 1073 possible information about an abuse incident. 1075 Appendix C. Public Discussion, History and Support 1077 [REMOVE BEFORE PUBLICATION] 1079 Public discussion of this proposed specification is handled via the 1080 abuse-feedback-report@mipassoc.org mailing list. The list is open. 1081 Access to subscription forms and to list archives can be found at 1082 http://mipassoc.org/mailman/listinfo/abuse-feedback-report. Active 1083 participation has included such sectors as messaging software 1084 vendors, messaging service providers, messaging consultants, anti- 1085 spam vendors, large Internet service providers, etc. 1087 Copies of this and earlier versions including multiple formats can be 1088 found at . 1089 A public website regarding this draft and related efforts is located 1090 at . 1092 (impetus for the work should be discussed here) 1094 (MAAWG activity should be discussed here) 1096 Several companies have already adopted use of this proposal, 1097 including large-scale e-mail hosting providers and Internet service 1098 providers. For a list of these, see the PROTO document supporting 1099 this draft. 1101 Appendix D. Document History 1103 Changes from draft-shafranovich-feedback-report-01-pre1 to 1104 draft-shafranovich-feedback-report-01: 1106 o Added an "Outstanding Issues" section. 1108 o Minor spelling mistakes and clarifications. 1110 o Added links to previous work and more examples. 1112 o Added three new types: "fraud" for phishing, "opt-out-list" for a 1113 single list opt out, and "other" as a catch-all. 1115 Changes from draft-shafranovich-feedback-report-00 to 1116 draft-shafranovich-feedback-report-01-pre1: 1118 o Changed the introduction section to clarify specific points that 1119 are out of scope for this document. 1121 o Added pointers to a public mailing list for discussion and public 1122 web page. 1124 o Clarified the intent section and added some extra points to it. 1126 o Made it clear that the requirements section is not the one 1127 defining the standard. 1129 o Clarified the main format section to make all three parts 1130 mandatory. 1132 o Changed section 4f regarding subject lines to mandate that subject 1133 lines should be left intact. Removed the convention for subject 1134 lines that was defined in the previous version. 1136 o Added text to the the machine readable section clarifying its 1137 intent. Also added RFC2119 references, reorganized fields, 1138 indicated whether specific header fields can appear more than once 1139 and provided references as to how they should be formatted. 1141 o Removed "Original-Message-ID", "Authenticated-Domain" and 1142 "Authenticated-Domain-Method" from the draft including related 1143 IANA registries. Added "Version", "User-Agent", Original-Mail- 1144 From", "Original-Rcpt-To", "Reported-URI", "Reported-Domain" and 1145 "Authentication-Results". 1147 o Example has been updated to reflect new fields. 1149 o Added a new section on extensibility and changed the IANA section 1150 to reflect that. 1152 Changes from draft-shafranovich-abuse-report-00 to 1153 draft-shafranovich-feedback-report-00: 1155 o Name of the format and report changed to 'feedback-report' 1157 o Minor spelling corrections 1159 o Added authentication headers and registry 1161 o Added feedback-type header and registry 1163 Changes from draft-shafranovich-feedback-report-00 to 1164 draft-shafranovich-feedback-report-01: 1166 o None significant (just a freshening) 1168 Changes from draft-shafranovich-feedback-report-01 to 1169 draft-shafranovich-feedback-report-02: 1171 o Much editorial cleanup 1173 o Added John Levine and Paul Hoffman as co-authors 1175 o Made the line lengths in Appendix A appropriate for RFCs 1177 o Switched to symbolic names for references 1179 o Reduced duplication of reference calls 1181 o Removed text that specified the type of RFC and approval type that 1182 is expected 1184 o Removed the requirement for an RFC to update the IANA registries; 1185 both are now designated expert approval only 1187 o Added two new categories to the initial values for the "Feedback- 1188 Type" registry: "miscategorized" and "not-spam" 1190 Changes from draft-shafranovich-feedback-report-02 to 1191 draft-shafranovich-feedback-report-03: 1193 o Added a bit to the Security Considerations section 1195 o Updated obsolete references 1196 o Resolved all items in the outstanding issues list and therefore 1197 removed it 1199 Changes from draft-shafranovich-feedback-report-03 to 1200 draft-shafranovich-feedback-report-04: 1202 o Added Murray Kucherawy as co-author 1204 o Added support for DKIM reporting 1206 o Cleaned up XML a lot 1208 Changes from draft-shafranovich-feedback-report-04 to 1209 draft-shafranovich-feedback-report-05: 1211 o Add "Incidents" header 1213 o RFC3464 replaces RFC1894 1215 o RFC5226 replaces RFC2434 1217 Changes from draft-shafranovich-feedback-report-05 to 1218 draft-shafranovich-feedback-report-06: 1220 o Remove Paul Hoffman as co-author, per his request 1222 o Add ABNF section 1224 o Move MIME registration stuff from the earlier sections to the IANA 1225 Considerations section 1227 o Some other minor re-organization 1229 o Add more stuff to Security Considerations 1231 o Add more project history 1233 o Overhaul the XML 1235 o Add and update several references; use symbolic references instead 1236 of numbered ones 1238 o Use RFC3330 "TEST-NET" addresses in examples 1240 o Fix some typos 1242 Changes from draft-shafranovich-feedback-report-06 to 1243 draft-shafranovich-feedback-report-07: 1245 o I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER published as RFC5451 1247 Changes from draft-shafranovich-feedback-report-07 to 1248 draft-shafranovich-feedback-report-08: 1250 o None. 1252 Changes from draft-shafranovich-feedback-report-08 to 1253 draft-ietf-marf-base-00: 1255 o Renamed given the formation of the working group. 1257 o Remove all report types apart from the basic ones known to be in 1258 use today. The rest can be added back via extension memos. 1260 o I-D.DRAFT-CROCKER-EMAIL-ARCH published as RFC5598. 1262 o Copy extensibility language from RFC5451. 1264 o Other minor copy editing. 1266 Changes from draft-ietf-marf-base-00 to draft-ietf-marf-base-01: 1268 o Reword Security Considerations segment about redacted data. 1270 o Add "Notes about URIs". 1272 o Add "Transport Considerations". 1274 o Add notes about auto-generated ARFs under Security Considerations. 1276 o Make some references normative. 1278 o Update STRADS URL reference. 1280 o Various wordsmithing. 1282 o Extend about "Reported-Domain". 1284 Changes from draft-ietf-marf-base-01 to draft-ietf-marf-base-02: 1286 o Correct ABNF for "reported-uri". 1288 Changes from draft-ietf-marf-base-02 to draft-ietf-marf-base-03: 1290 o Remove "Envelope Sender Selection" section. 1292 o Fix "Authentication-Results" and "From" fields in example. 1294 o Tighten up definition of "Reported-URI". 1296 o Discuss registration updates that declare report as either 1297 historic or deprecated. 1299 o Add "Attached Malware" section. 1301 o Several edits in "Extensions" section. 1303 o Reword "Purpose". 1305 o Minor grammar nits. 1307 Changes from draft-ietf-marf-base-03 to draft-ietf-marf-base-04: 1309 o Fix references to RFC5321 ABNF 1311 o Fix ABNF for user-agent, version, arrival-date, domain 1313 o Change registrations from Designated Expert to Specification 1314 Required 1316 o Add a "status" field to both registries 1318 o Add "Incidents" to the registry 1320 o Add better descriptions for "abuse", "Reporting-Domain" and 1321 "Reporting-URI" in the registries 1323 o Make some references normative 1325 Changes from draft-ietf-marf-base-04 to draft-ietf-marf-base-05: 1327 o Another change to version ABNF 1329 o Remove "x-" prefix stuff in Extensibility 1331 o Update John Levine's contact info 1333 o Add an example use of "Reporting-MTA" 1335 o Add "ext-field" ABNF 1337 o Add guidance about intepreting the various MIME parts 1338 o Add reference to S/MIME 1340 o Add commentary on User-Agent forgery in Security Considerations 1342 o Slight fix to Introduction regarding scope 1344 Changes from draft-ietf-marf-base-05 to draft-ietf-marf-base-06: 1346 o Add discussion of malformed message handling 1348 o Example should use Arrival-Date 1350 o Registry should show Received-Date as historic 1352 Authors' Addresses 1354 Yakov Shafranovich 1355 ShafTek Enterprises 1356 4014 Labyrinth Rd. 1357 Baltimore, MD 21215 1359 Email: ietf@shaftek.org 1360 URI: http://www.shaftek.org 1362 John Levine 1363 Taughannock Networks 1364 PO Box 727 1365 Trumansburg, NY 14886 1367 Phone: +1 831 480 2300 1368 Email: standards@taugh.com 1370 Murray S. Kucherawy 1371 Cloudmark 1372 128 King St., 2nd Floor 1373 San Francisco, CA 94107 1374 US 1376 Phone: +1 415 946 3800 1377 Email: msk@cloudmark.com