7Internet Engineering Task Force (IETF) Y. Shafranovich
8Request for Comments: 5965 ShafTek Enterprises
9Category: Standards Track J. Levine
10ISSN: 2070-1721 Taughannock Networks
16 An Extensible Format for Email Feedback Reports
20 This document defines an extensible format and MIME type that may be
21 used by mail operators to report feedback about received email to
22 other parties. This format is intended as a machine-readable
23 replacement for various existing report formats currently used in
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc5965.
42 Copyright (c) 2010 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Shafranovich, et al. Standards Track [Page 1]
60RFC 5965 Format for Feedback Reports August 2010
65 1. Introduction ....................................................3
66 1.1. Purpose ....................................................3
67 1.2. Requirements ...............................................4
68 1.3. Definitions ................................................4
69 1.3.1. General .............................................4
70 1.3.2. Email Specific ......................................4
71 2. Format of Email Feedback Reports ................................4
72 3. The 'message/feedback-report' Content Type ......................5
73 3.1. Required Fields ............................................6
74 3.2. Optional Fields Appearing Once .............................6
75 3.3. Optional Fields Appearing Multiple Times ...................7
76 3.4. Notes about URIs ...........................................8
77 3.5. Formal Definition ..........................................8
78 4. Handling Malformed Reports .....................................10
79 5. Transport Considerations .......................................10
80 6. Extensibility ..................................................10
81 7. IANA Considerations ............................................11
82 7.1. MIME Type Registration of 'message/feedback-report' .......11
83 7.2. Feedback Report Header Fields .............................12
84 7.3. Feedback Report Type Values ...............................15
85 8. Security Considerations ........................................17
86 8.1. Inherited from RFC 3462 ...................................17
87 8.2. Interpretation ............................................17
88 8.3. Attacks against Authentication Methods ....................17
89 8.4. Intentionally Malformed Reports ...........................18
90 8.5. Omitting Data from ARF Reports ............................18
91 8.6. Automatically Generated ARF Reports .......................18
92 8.7. Attached Malware ..........................................18
93 8.8. The User-Agent Field ......................................18
94 8.9. Malformed Messages ........................................19
95 9. References .....................................................19
96 9.1. Normative References ......................................19
97 9.2. Informative References ....................................20
98 Appendix A. Acknowledgements .....................................22
99 Appendix B. Sample Feedback Reports ..............................22
100 B.1. Simple Report for Email Abuse without Optional Headers ...22
101 B.2. Full Report for Email Abuse with All Headers .............23
114Shafranovich, et al. Standards Track [Page 2]
116RFC 5965 Format for Feedback Reports August 2010
121 As the spam problem continues to expand and potential solutions
122 evolve, mail operators are increasingly exchanging abuse reports
123 among themselves and other parties. However, different operators
124 have defined their own formats, and thus the receivers of these
125 reports are forced to write custom software to interpret each of
126 them. In addition, many operators use various other report formats
127 to provide non-abuse-related feedback about processed email. This
128 memo uses the "multipart/report" content type defined in [REPORT],
129 and in that context defines a standard extensible format by creating
130 the "message/feedback-report" [MIME] type for these reports.
132 While there has been previous work in this area (e.g., [STRADS-BCP]
133 and [ASRG-ABUSE]), none of it has yet been successful. It is hoped
134 that this document will have a better fate.
136 This format is intended primarily as an Abuse Reporting Format (ARF)
137 for reporting email abuse but also includes support for direct
138 feedback via end user mail clients, reports of some types of virus
139 activity, and some similar issues. This memo also contains provision
140 for extensions should other specific types of reports be desirable in
143 This document only defines the format and [MIME] content type to be
144 used for these reports. Determination of where these reports should
145 be sent, validation of their contents, and how trust among report
146 generators and report recipients is established are outside the scope
147 of this document. It is assumed that best practices will evolve over
148 time, and will be codified in future documents.
152 The reports defined in this document are intended to inform mail
155 o email abuse originating from their networks;
157 o potential issues with the perceived quality of outbound mail, such
158 as email service providers sending mail that attracts the
159 attention of automated abuse detection systems.
161 Please note that while the parent "multipart/report" content type
162 defined in [REPORT] is used for all kinds of administrative messages,
163 this format is intended specifically for communications among
164 providers regarding email abuse and related issues, and SHOULD NOT be
165 used for other reports.
170Shafranovich, et al. Standards Track [Page 3]
172RFC 5965 Format for Feedback Reports August 2010
177 The following requirements are necessary for feedback reports (the
178 actual specification is defined later in this document):
180 o They must be both human and machine readable;
182 o A copy of the original email message (both body and header) or the
183 message header must be enclosed in order to allow the receiver to
184 handle the report properly;
186 o The machine-readable section must provide ability for the report
187 generators to share meta-data with receivers;
189 o The format must be extensible.
193 This section defines various terms used throughout this document.
197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
199 document are to be interpreted as described in [KEYWORDS].
203 [EMAIL-ARCH] introduces several terms and concepts that are used in
204 this memo, and thus readers are advised to become familiar with it as
2072. Format of Email Feedback Reports
209 To satisfy the requirements, an email feedback report is defined as a
210 [MIME] message with a top-level MIME content type of "multipart/
211 report" (as defined in [REPORT]). The following apply:
213 a. The "report-type" parameter of the "multipart/report" type is set
214 to "feedback-report";
216 b. The first MIME part of the message contains a human-readable
217 description of the report and MUST be included.
226Shafranovich, et al. Standards Track [Page 4]
228RFC 5965 Format for Feedback Reports August 2010
231 c. The second MIME part of the message is a machine-readable section
232 with the content type of "message/feedback-report" (defined later
233 in this memo) and MUST be included. This section is intended to
234 convey meta-data about the report in question that may not be
235 readily available from the included email message itself.
237 d. The third MIME part of the message is either of type "message/
238 rfc822" (as defined in [MIME-TYPES]) and contains the original
239 message in its entirety OR is of type "text/rfc822-headers" (as
240 defined in [REPORT]) and contains a copy of the entire header
241 block from the original message. This part MUST be included
242 (contrary to [REPORT]). While some operators may choose to
243 modify or redact this portion for privacy or legal reasons, it is
244 RECOMMENDED that the entire original email message be included
245 without any modification as such modifications can impede
246 forensic work by the recipient of this report. See Section 8 for
249 e. Except as discussed below, each feedback report MUST be related
250 to only a single email message. Summary and aggregate formats
251 are outside of the scope of this specification.
253 f. The Subject header field of the feedback report SHOULD be the
254 same as the included email message about which the report is
255 being generated. If it differs, the difference MUST be limited
256 to only a typical forwarding prefix used by Mail User Agents
257 (MUAs) such as "FW:". (Many smaller operators using MUAs for
258 abuse handling rely on the subject lines for processing.)
260 g. The primary evidence of the abuse being reported is found in the
261 third part of the report, which contains the original message.
262 The second part contains additional derived data that may help
263 the receiver, but in terms of selecting actionable report data,
264 report recipients SHOULD use the content of the third part first,
265 then data from the second part. The first part is meant to
266 contain explanatory text for human use but is not itself a part
267 of the report, and SHOULD NOT be used if it is in conflict with
2703. The 'message/feedback-report' Content Type
272 A new [MIME] content type called "message/feedback-report" is
273 defined. This content type provides a machine-readable section
274 intended to let the report generator convey meta-data to the report
275 receiver. The intent of this section is to convey information that
276 may not be obvious or may not be easily extracted from the original
277 email message body or header.
282Shafranovich, et al. Standards Track [Page 5]
284RFC 5965 Format for Feedback Reports August 2010
287 The body of this content type consists of multiple "fields" formatted
288 according to the ABNF of [MAIL] header fields. This section defines
289 the initial set of fields provided by this specification. Additional
290 fields may be registered according to the procedure described later
291 in this memo. Although these fields have a syntax similar to those
292 of mail message header fields, they are semantically distinct; hence,
293 they SHOULD NOT be repeated as header fields of the message
294 containing the report. Note that these fields represent information
295 that the receiver is asserting about the report in question, but are
296 not necessarily verifiable. Report receivers MUST NOT assume that
297 these assertions are always accurate.
299 Note that the above limitation in no way restricts the use of message
300 header fields that are registered in the IANA header field registry
301 with the same field names.
305 The following report header fields MUST appear exactly once:
307 o "Feedback-Type" contains the type of feedback report (as defined
308 in the corresponding IANA registry and later in this memo). This
309 is intended to let report parsers distinguish among different
312 o "User-Agent" indicates the name and version of the software
313 program that generated the report. The format of this field MUST
314 follow section 14.43 of [HTTP]. This field is for documentation
315 only; there is no registry of user agent names or versions, and
316 report receivers SHOULD NOT expect user agent names to belong to a
319 o "Version" indicates the version of specification that the report
320 generator is using to generate the report. The version number in
321 this specification is set to "1".
3233.2. Optional Fields Appearing Once
325 The following header fields are optional and MUST NOT appear more
328 o "Original-Envelope-Id" contains the envelope ID string used in the
329 original [SMTP] transaction (see section 2.2.1 of [DSN]).
331 o "Original-Mail-From" contains a copy of the email address used in
332 the MAIL FROM portion of the original SMTP transaction. The
333 format of this field is defined in section 4.1.2 of [SMTP] as
338Shafranovich, et al. Standards Track [Page 6]
340RFC 5965 Format for Feedback Reports August 2010
343 o "Arrival-Date" indicates the date and time at which the original
344 message was received by the Mail Transfer Agent (MTA) of the
345 generating ADMD (Administrative Management Domain). This field
346 MUST be formatted as per section 3.3 of [MAIL].
348 o "Reporting-MTA" indicates the name of the MTA generating this
349 feedback report. This field is defined in section 2.2.2 of [DSN],
350 except that it is an optional field in this report.
352 o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which
353 the original message was received. Addresses MUST be formatted as
354 per section 4.1.3 of [SMTP].
356 o "Incidents" contains an unsigned 32-bit integer indicating the
357 number of incidents this report represents. The absence of this
358 field implies the report covers a single incident.
360 The historic field "Received-Date" SHOULD also be accepted and
361 interpreted identically to "Arrival-Date". However, if both are
362 present, the report is malformed and SHOULD be treated as described
3653.3. Optional Fields Appearing Multiple Times
367 The following set of header fields are optional and may appear any
368 number of times as appropriate:
370 o "Authentication-Results" indicates the result of one or more
371 authentication checks run by the report generator. The format of
372 this field is defined in [AUTH-RESULTS]. Report receivers should
373 note that this field only indicates an assertion made by the
376 o "Original-Rcpt-To" includes a copy of the email address used in
377 the RCPT TO portion of the original [SMTP] transaction. The
378 format of this field is a "Reverse-path" defined in section 4.1.2
379 of that memo. This field SHOULD be repeated for every SMTP
380 recipient seen by the report generator.
382 o "Reported-Domain" includes a domain name that the report generator
383 believes to be relevant to the report, e.g., the domain whose
384 apparent actions provoked the generation of the report. It is
385 unspecified how the report generator determines this information,
386 and thus the report receiver cannot be certain how it was chosen.
387 It is often used as a means of suggesting to the report receiver
388 how this report might be handled. In cases where the derivation
394Shafranovich, et al. Standards Track [Page 7]
396RFC 5965 Format for Feedback Reports August 2010
399 is not obvious, the report generator is encouraged to clarify in
400 the text section of the report. Domain format is defined in
401 section 2.3.1 of [DNS].
403 o "Reported-URI" indicates a URI that the report generator believes
404 to be relevant to the report, e.g., a suspect URI that was found
405 in the message that caused the report to be generated. The same
406 caveats about the origin of the value of "Reported-Domain" apply
407 to this field. The URI format is defined in [URI].
411 Implementors should be aware that the Reported-URI field can carry
412 many different types of data depending on the URI scheme used. For
413 more information, please consult the "URI Schemes" registry
416 Furthermore, it is outside the scope of this standard whether the
417 data carried in this field implies any additional information.
418 Implementors may negotiate their own agreements surrounding the
419 interpretation of this data.
4213.5. Formal Definition
423 The formal definition of the contents of a "message/feedback-report"
424 media type using [ABNF] is as follows:
426 feedback-report = *( feedback-type / user-agent / version )
431 feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF
432 ; the "token" must be a registered feedback type as
433 ; described elsewhere in this document
435 user-agent = "User-Agent:" [CFWS] product *( CFWS product )
438 version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
441 opt-fields-once = [ arrival-date ]
443 [ original-envelope-id ]
444 [ original-mail-from ]
450Shafranovich, et al. Standards Track [Page 8]
452RFC 5965 Format for Feedback Reports August 2010
455 arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
457 incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
458 ; must be a 32-bit unsigned integer
460 original-envelope-id = "Original-Envelope-Id:" [CFWS]
461 envelope-id [CFWS] CRLF
463 original-mail-from = "Original-Mail-From:" [CFWS]
464 reverse-path [CFWS] CRLF
466 reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";"
467 [CFWS] mta-name [CFWS] CRLF
469 source-ip = "Source-IP:" [CFWS]
470 ( IPv4-address-literal /
471 IPv6-address-literal ) [CFWS] CRLF
473 opt-fields-many = [ authres-header ]
478 original-rcpt-to = "Original-Rcpt-To:" [CFWS]
479 forward-path [CFWS] CRLF
481 reported-domain = "Reported-Domain:" [CFWS]
484 reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
486 ext-field = field-name ":" unstructured
488 A set of fields satisfying this ABNF may appear in the transmitted
489 message in any order.
491 "CRLF" and "DIGIT" are imported from [ABNF].
493 "token" is imported from [MIME].
495 "product" is imported from [HTTP].
497 "field-name", "unstructured", "CFWS", "date-time", and "domain" are
498 imported from [MAIL].
500 "envelope-id", "mta-name-type", and "mta-name" are imported from
506Shafranovich, et al. Standards Track [Page 9]
508RFC 5965 Format for Feedback Reports August 2010
511 "reverse-path", "forward-path", "local-part", "IPv4-address-literal",
512 and "IPv6-address-literal" are imported from [SMTP].
514 "URI" is imported from [URI].
516 "authres-header" is imported from [AUTH-RESULTS].
518 "ext-field" refers to extension fields, which are discussed in
5214. Handling Malformed Reports
523 When an agent that accepts and handles ARF messages receives a
524 message that purports (by MIME type) to be an ARF message but
525 syntactically deviates from this specification, that agent SHOULD
526 ignore or reject the message. Where rejection is performed, the
527 rejection notice (either via an [SMTP] reply or generation of a
528 [DSN]) SHOULD identify the specific cause for the rejection.
530 See Section 8.9 for further discussion.
5325. Transport Considerations
534 [DSN] requires that its reports be sent with the empty [SMTP]
535 envelope sender to avoid bounce loops. A similar requirement was
536 considered for this specification, but it seems unlikely that an ARF
537 report would be generated in response to receipt of an ARF report,
538 and furthermore such a requirement would prevent an ARF generator
539 from ever determining that an ARF report was not actually received.
541 On the other hand, if an ARF report is generated without the empty
542 envelope sender and is sent to an address that actually does not
543 work, then the generating address can also be overwhelmed by DSNs as
544 a denial-of-service attack (see Section 8.6).
546 This specification therefore makes no requirement related to the
547 envelope sender of a generated report. Operators will have to
548 consider what envelope sender to use within the context of their own
553 Like many other formats and protocols, this format may need to be
554 extended over time to fit the ever-changing landscape of the
555 Internet. Therefore, extensibility is provided via two IANA
556 registries: one for feedback types and a second for report header
557 fields. The feedback type registry is to be used in conjunction with
558 the "Feedback-Type" field above. The header name registry is
562Shafranovich, et al. Standards Track [Page 10]
564RFC 5965 Format for Feedback Reports August 2010
567 intended for registration of new meta-data fields to be used in the
568 machine-readable portion (part 2) of this format. Please note that
569 version numbers do not change with new field registrations unless a
570 new specification of this format is published. Also, note that all
571 new field registrations may only be registered as optional fields.
572 Any new required fields REQUIRE a new version of this specification
575 In order to encourage extensibility and interoperability of this
576 format, implementors MUST ignore any fields or report types they do
577 not explicitly support.
579 Additional report types (extension report types) or report header
580 fields might be defined in the future by later revisions to this
581 specification, or by registrations as described above. Such types
582 and fields MUST be registered as described above and published in an
583 Open Specification such as an RFC.
585 Experimental report types and report header fields MUST only be used
586 between ADMDs that have explicitly consented to use them. These
587 names and the parameters associated with them are not documented in
588 RFCs. Therefore, they are subject to change at any time and are not
589 suitable for general use.
5917. IANA Considerations
593 IANA has registered a new [MIME] type and created two new registries,
5967.1. MIME Type Registration of 'message/feedback-report'
598 This section provides the media type registration application from
599 [MIME-REG] for processing by IANA:
601 To: ietf-types@iana.org
603 Subject: Registration of media type message/feedback-report
607 Subtype name: feedback-report
609 Required parameters: none
611 Optional parameters: none
613 Encoding considerations: "7bit" encoding is sufficient and MUST be
614 used to maintain readability when viewed by non-MIME mail readers.
618Shafranovich, et al. Standards Track [Page 11]
620RFC 5965 Format for Feedback Reports August 2010
623 Security considerations: See Section 8 of [RFC5965].
625 Interoperability considerations: Implementors MUST ignore any fields
628 Published specification: [RFC5965]
630 Applications that use this media type: Abuse helpdesk software for
631 ISPs, mail service bureaus, mail certifiers, and similar
634 Additional information: none
636 Person and email address to contact for further information:
638 Yakov Shafranovich <ietf@shaftek.org>
640 Murray S. Kucherawy <msk@cloudmark.com>
642 Intended usage: COMMON
652 Change controller: IESG
6547.2. Feedback Report Header Fields
656 IANA has created the "Feedback Report Header Fields" registry. This
657 registry contains header fields for use in feedback reports, as
658 defined by this memo.
660 New registrations or updates MUST be published in accordance with the
661 "Specification Required" guidelines as described in [IANA]. Any new
662 field thus registered is considered optional by this specification
663 unless a new version of this memo is published.
665 New registrations and updates MUST contain the following information:
667 1. Name of the field being registered or updated
669 2. Short description of the field
674Shafranovich, et al. Standards Track [Page 12]
676RFC 5965 Format for Feedback Reports August 2010
679 3. Whether the field can appear more than once
681 4. To which feedback type(s) this field applies (or "any")
683 5. The document in which the specification of the field is published
685 6. New or updated status, which MUST be one of:
687 current: The field is in current use
689 deprecated: The field is in current use but its use is
692 historic: The field is no longer in current use
694 An update may make a notation on an existing registration indicating
695 that a registered field is historic or deprecated if appropriate.
697 The initial registry contains these values:
699 Field Name: Arrival-Date
700 Description: date/time the original message was received
701 Multiple Appearances: No
702 Related "Feedback-Type": any
703 Published in: [RFC5965]
707 Field Name: Authentication-Results
708 Description: results of authentication check(s)
709 Multiple Appearances: Yes
710 Related "Feedback-Type": any
711 Published in: [RFC5965]
715 Field Name: Feedback-Type
716 Description: registered feedback report type
717 Multiple Appearances: No
718 Related "Feedback-Type": N/A
719 Published in: [RFC5965]
730Shafranovich, et al. Standards Track [Page 13]
732RFC 5965 Format for Feedback Reports August 2010
735 Field Name: Incidents
736 Description: expression of how many similar incidents are
737 represented by this report
738 Multiple Appearances: No
739 Related "Feedback-Type": any
740 Published in: [RFC5965]
744 Field Name: Original-Mail-From
745 Description: email address used in the MAIL FROM portion of the
746 original SMTP transaction
747 Multiple Appearances: No
748 Related "Feedback-Type": any
749 Published in: [RFC5965]
753 Field Name: Original-Rcpt-To
754 Description: email address used in the RCPT TO portion of the
755 original SMTP transaction
756 Multiple Appearances: Yes
757 Related "Feedback-Type": any
758 Published in: [RFC5965]
762 Field Name: Received-Date
763 Description: date/time the original message was received
764 (replaced by "Arrival-Date")
765 Multiple Appearances: No
766 Related "Feedback-Type": any
767 Published in: [RFC5965]
771 Field Name: Reported-Domain
772 Description: a domain name the report generator considers to
773 be key to the message about which a report is
775 Multiple Appearances: Yes
776 Related "Feedback-Type": any
777 Published in: [RFC5965]
786Shafranovich, et al. Standards Track [Page 14]
788RFC 5965 Format for Feedback Reports August 2010
791 Field Name: Reported-URI
792 Description: a URI the report generator considers to be key
793 to the message about which a report is being
795 Multiple Appearances: Yes
796 Related "Feedback-Type": any
797 Published in: [RFC5965]
801 Field Name: Reporting-MTA
802 Description: MTA generating this report
803 Multiple Appearances: No
804 Related "Feedback-Type": any
805 Published in: [RFC5965]
809 Field Name: Source-IP
810 Description: IPv4 or IPv6 address from which the original message
812 Multiple Appearances: No
813 Related "Feedback-Type": any
814 Published in: [RFC5965]
818 Field Name: User-Agent
819 Description: name and version of the program generating the
821 Multiple Appearances: No
822 Related "Feedback-Type": any
823 Published in: [RFC5965]
828 Description: version of specification used
829 Multiple Appearances: No
830 Related "Feedback-Type": any
831 Published in: [RFC5965]
8347.3. Feedback Report Type Values
836 IANA has created the "Feedback Report Type Values" registry. This
837 registry contains feedback types for use in feedback reports, defined
842Shafranovich, et al. Standards Track [Page 15]
844RFC 5965 Format for Feedback Reports August 2010
847 New registrations or updates MUST be published in accordance with the
848 "Specification Required" guidelines as described in [IANA]. Any new
849 field thus registered is considered optional by this specification
850 unless a new version of this memo is published.
852 New registrations MUST contain the following information:
854 1. Name of the feedback type being registered
856 2. Short description of the feedback type
858 3. The document in which the specification of the field is published
860 4. New or updated status, which MUST be one of:
862 current: The field is in current use
864 deprecated: The field is in current use but its use is
867 historic: The field is no longer in current use
869 The initial registry contains these values:
871 Feedback Type Name: abuse
872 Description: unsolicited email or some other kind of email abuse
873 Published in: [RFC5965]
877 Feedback Type Name: fraud
878 Description: indicates some kind of fraud or phishing activity
879 Published in: [RFC5965]
883 Feedback Type Name: other
884 Description: any other feedback that does not fit into other
886 Published in: [RFC5965]
890 Feedback Type Name: virus
891 Description: report of a virus found in the originating message
892 Published in: [RFC5965]
898Shafranovich, et al. Standards Track [Page 16]
900RFC 5965 Format for Feedback Reports August 2010
9038. Security Considerations
905 The following security considerations apply when generating or
906 processing a feedback report:
9088.1. Inherited from RFC 3462
910 All of the Security Considerations from [REPORT] are inherited here.
914 This specification describes a report format. The authentication and
915 validity of the content of the report SHOULD be established through
916 other means. The content of an unvetted report could be wrong,
917 incomplete or deliberately false, including the alleged abuse
918 incident in the third part, derived data in the second part or the
919 human-readable first part.
921 There will be some desire to perform some actions in an automated
922 fashion in order to enact timely responses to common feedback
923 reports. Caution must be taken, however, as there is no substantial
924 security around the content of these reports. An attacker could
925 craft a report meant to generate undesirable actions on the part of a
928 It is suggested that the origin of an ARF report be vetted, such as
929 by using common message authentication schemes like [SMIME], [DKIM],
930 [SPF], or [SENDERID], prior to the undertaking of any kind of
931 automated action in response to receipt of the report. In
932 particular, S/MIME offers the strongest authentication and the cost
933 of key exchange is assumed in the process of establishing a bilateral
934 reporting relationship that uses this specification; however, it is
935 not as transparent as the others and thus will interfere with the
936 parsing capabilities of code that is designed specifically to handle
937 multipart/report messages.
939 The details of the required validation to achieve this are a matter
940 of local policy and are thus outside the scope of this specification.
9428.3. Attacks against Authentication Methods
944 If an attack becomes known against an authentication method, clearly
945 then the agent verifying that method can be fooled into thinking an
946 inauthentic message is authentic, and thus the value of this header
947 field can be misleading. It follows that any attack against an
948 authentication method that might be used to protect the authenticity
949 of an abuse report is also a security consideration here.
954Shafranovich, et al. Standards Track [Page 17]
956RFC 5965 Format for Feedback Reports August 2010
9598.4. Intentionally Malformed Reports
961 It is possible for an attacker to generate an ARF message field that
962 is extraordinarily large or otherwise malformed in an attempt to
963 discover or exploit weaknesses in recipient parsing code.
964 Implementors SHOULD thoroughly verify all such messages and be robust
965 against intentionally as well as unintentionally malformed messages.
9678.5. Omitting Data from ARF Reports
969 The sending of these reports can reveal possibly private information
970 about the person sending the report. For example, such a report sent
971 in response to a mailing list posting will reveal to the report
972 recipient a valid email address on the list that might otherwise have
975 For this reason, report generators might wish to redact portions of
976 the report to conceal private information. Doing so could be
977 necessary where privacy trumps operational necessity, but, as
978 mentioned in Section 2, it might impede a timely or meaningful
979 response from the report recipient.
9818.6. Automatically Generated ARF Reports
983 Systems have been implemented that generate ARF reports automatically
984 in response to an event. For example, software monitoring a honeypot
985 email address might generate an ARF report immediately upon delivery
986 of any message to it. An attacker that becomes aware of such a
987 configuration can exploit it to attack an ARF recipient with
988 automatically generated ARF reports.
992 As this format is sometimes used to automatically report malware, ARF
993 processors (human or otherwise) SHOULD ensure that attachments are
994 processed in a manner appropriate for unverified and potentially
9978.8. The User-Agent Field
999 Further to Section 8.2, the User-Agent field is an assertion of the
1000 generating software and is neither specified in this memo nor derived
1001 from the message represented in the third part of the report. It is
1002 intended for documentation and debugging, and since it is trivially
1003 forged by a malicious agent, it SHOULD NOT be interpreted by
1010Shafranovich, et al. Standards Track [Page 18]
1012RFC 5965 Format for Feedback Reports August 2010
10158.9. Malformed Messages
1017 Further to the discussion in Section 4, there might be cases where an
1018 ARF processing agent elects to accept messages not consistent with
1019 this specification, such as during transition periods where some
1020 fields are moving toward "historic" or "deprecated" status, or the
1021 introduction of new non-standard extension or experimental fields.
1022 Such choices need to be implemented with extreme caution; where two
1023 different fields have related meaning (e.g., "Received-Date", which
1024 is historic, and "Arrival-Date", which is current), an attacker could
1025 craft a report that makes a confusing claim in an attempt to exploit
1026 such liberal parsing logic.
10309.1. Normative References
1032 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1033 Specifications: ABNF", STD 68, RFC 5234,
1036 [AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating
1037 Message Authentication Status", RFC 5451, April 2009.
1039 [DNS] Mockapetris, P., "Domain names - implementation and
1040 specification", STD 13, RFC 1035, November 1987.
1042 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
1043 Format for Delivery Status Notifications", RFC 3464,
1046 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1047 Masinter, L., Leach, P., and T. Berners-Lee,
1048 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
1051 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1052 Requirement Levels", BCP 14, RFC 2119, March 1997.
1054 [MAIL] Resnick, P., Ed., "Internet Message Format",
1055 RFC 5322, October 2008.
1057 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
1058 Mail Extensions (MIME) Part One: Format of Internet
1059 Message Bodies", RFC 2045, November 1996.
1066Shafranovich, et al. Standards Track [Page 19]
1068RFC 5965 Format for Feedback Reports August 2010
1071 [MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications
1072 and Registration Procedures", BCP 13, RFC 4288,
1075 [MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet
1076 Mail Extensions (MIME) Part Two: Media Types",
1077 RFC 2046, November 1996.
1079 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for
1080 the Reporting of Mail System Administrative
1081 Messages", RFC 3462, January 2003.
1083 [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
1084 RFC 5321, October 2008.
1086 [URI] Berners-Lee, T., Fielding, R., and L. Masinter,
1087 "Uniform Resource Identifier (URI): Generic Syntax",
1088 STD 66, RFC 3986, January 2005.
10909.2. Informative References
1092 [ASRG-ABUSE] Anti-Spam Research Group (ASRG) of the Internet
1093 Research Task Force (IRTF), "Abuse Reporting
1094 Standards Subgroup of the ASRG", May 2005.
1096 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M.,
1097 Fenton, J., and M. Thomas, "DomainKeys Identified
1098 Mail (DKIM) Signatures", RFC 4871, May 2007.
1100 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
1103 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
1104 an IANA Considerations Section in RFCs", BCP 26,
1107 [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating
1108 E-Mail", RFC 4406, April 2006.
1110 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose
1111 Internet Mail Extensions (S/MIME) Version 3.2 Message
1112 Specification", RFC 5751, January 2010.
1114 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework
1115 (SPF) for Authorizing Use of Domains in E-Mail,
1116 Version 1", RFC 4408, April 2006.
1122Shafranovich, et al. Standards Track [Page 20]
1124RFC 5965 Format for Feedback Reports August 2010
1127 [STRADS-BCP] Crissman, G., "Proposed Spam Reporting BCP Document",
1178Shafranovich, et al. Standards Track [Page 21]
1180RFC 5965 Format for Feedback Reports August 2010
1183Appendix A. Acknowledgements
1185 The authors would like to thank many of the members of the email
1186 community who provided helpful comments and suggestions for this
1187 document including many of the participants in ASRG, IETF, and MAAWG
1188 activities, and all of the members of the abuse-feedback-report
1189 public mailing list.
1191Appendix B. Sample Feedback Reports
1193 This section presents some examples of the use of this message format
1194 to report feedback about an arriving message.
1196B.1. Simple Report for Email Abuse without Optional Headers
1200 From: <abusedesk@example.com>
1201 Date: Thu, 8 Mar 2005 17:40:36 EDT
1202 Subject: FW: Earn money
1203 To: <abuse@example.net>
1205 Content-Type: multipart/report; report-type=feedback-report;
1206 boundary="part1_13d.2e68ed54_boundary"
1208 --part1_13d.2e68ed54_boundary
1209 Content-Type: text/plain; charset="US-ASCII"
1210 Content-Transfer-Encoding: 7bit
1212 This is an email abuse report for an email message received from IP
1213 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
1214 about this format please see http://www.mipassoc.org/arf/.
1216 --part1_13d.2e68ed54_boundary
1217 Content-Type: message/feedback-report
1219 Feedback-Type: abuse
1220 User-Agent: SomeGenerator/1.0
1223 --part1_13d.2e68ed54_boundary
1224 Content-Type: message/rfc822
1225 Content-Disposition: inline
1227 Received: from mailserver.example.net
1228 (mailserver.example.net [192.0.2.1])
1229 by example.com with ESMTP id M63d4137594e46;
1230 Thu, 08 Mar 2005 14:00:00 -0400
1234Shafranovich, et al. Standards Track [Page 22]
1236RFC 5965 Format for Feedback Reports August 2010
1239 From: <somespammer@example.net>
1240 To: <Undisclosed Recipients>
1243 Content-type: text/plain
1244 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
1245 Date: Thu, 02 Sep 2004 12:31:03 -0500
1251 --part1_13d.2e68ed54_boundary--
1253 Example 1: Required fields only
1255 Illustration of a feedback report generated according to this
1256 specification. Only the required fields are used.
1258B.2. Full Report for Email Abuse with All Headers
1260 A full email abuse report:
1262 From: <abusedesk@example.com>
1263 Date: Thu, 8 Mar 2005 17:40:36 EDT
1264 Subject: FW: Earn money
1265 To: <abuse@example.net>
1267 Content-Type: multipart/report; report-type=feedback-report;
1268 boundary="part1_13d.2e68ed54_boundary"
1270 --part1_13d.2e68ed54_boundary
1271 Content-Type: text/plain; charset="US-ASCII"
1272 Content-Transfer-Encoding: 7bit
1274 This is an email abuse report for an email message received from IP
1275 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
1276 about this format please see http://www.mipassoc.org/arf/.
1278 --part1_13d.2e68ed54_boundary
1279 Content-Type: message/feedback-report
1281 Feedback-Type: abuse
1282 User-Agent: SomeGenerator/1.0
1284 Original-Mail-From: <somespammer@example.net>
1285 Original-Rcpt-To: <user@example.com>
1286 Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
1290Shafranovich, et al. Standards Track [Page 23]
1292RFC 5965 Format for Feedback Reports August 2010
1295 Reporting-MTA: dns; mail.example.com
1296 Source-IP: 192.0.2.1
1297 Authentication-Results: mail.example.com;
1298 spf=fail smtp.mail=somespammer@example.com
1299 Reported-Domain: example.net
1300 Reported-Uri: http://example.net/earn_money.html
1301 Reported-Uri: mailto:user@example.com
1302 Removal-Recipient: user@example.com
1304 --part1_13d.2e68ed54_boundary
1305 Content-Type: message/rfc822
1306 Content-Disposition: inline
1308 From: <somespammer@example.net>
1309 Received: from mailserver.example.net (mailserver.example.net
1310 [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
1311 Thu, 08 Mar 2005 14:00:00 -0400
1313 To: <Undisclosed Recipients>
1316 Content-type: text/plain
1317 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
1318 Date: Thu, 02 Sep 2004 12:31:03 -0500
1324 --part1_13d.2e68ed54_boundary--
1326 Example 1: Generic abuse report with maximum returned information
1328 A contrived example in which the report generator has returned all
1329 possible information about an abuse incident.
1346Shafranovich, et al. Standards Track [Page 24]
1348RFC 5965 Format for Feedback Reports August 2010
1359 EMail: ietf@shaftek.org
1360 URI: http://www.shaftek.org
1364 Taughannock Networks
1366 Trumansburg, NY 14886
1369 Phone: +1 831 480 2300
1370 EMail: standards@taugh.com
1375 128 King St., 2nd Floor
1376 San Francisco, CA 94107
1379 Phone: +1 415 946 3800
1380 EMail: msk@cloudmark.com
1402Shafranovich, et al. Standards Track [Page 25]