RFC 5965

An Extensible Format for Email Feedback Reports

📅 published August 2010, from ietf

RFC 5965: An Extensible Format for Email Feedback Reports 💌✨

(part 1 of 4)

Okay bestie, here's the title block tea ☕. It's RFC 5965, and it's an Internet Standards Track doc, so it's official official. 💅

  • Authors: Y. Shafranovich (ShafTek Enterprises), J. Levine (Taughannock Networks), and M. Kucherawy (Cloudmark) 🫶
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: August 2010
  • Obsoletes/Updates: the title block doesn't list any, so this doc isn't obsoleting or updating anything in the header 🤷‍♀️

Abstract 💌

Okay so this doc defines an extensible format and a MIME type that mail operators can use to report feedback about received email to other parties. It's giving machine-readable replacement energy for the bunch of different report formats already floating around Internet email. 🧚

Status of This Memo 📋

This is an Internet Standards Track document. ⭐

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741. 🌸

Want the current status, any errata, or a way to give feedback? Head to http://www.rfc-editor.org/info/rfc5965. 🔗

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🧾

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Purpose ....................................................3
      1.2. Requirements ...............................................4
      1.3. Definitions ................................................4
           1.3.1. General .............................................4
           1.3.2. Email Specific ......................................4
   2. Format of Email Feedback Reports ................................4
   3. The 'message/feedback-report' Content Type ......................5
      3.1. Required Fields ............................................6
      3.2. Optional Fields Appearing Once .............................6
      3.3. Optional Fields Appearing Multiple Times ...................7
      3.4. Notes about URIs ...........................................8
      3.5. Formal Definition ..........................................8
   4. Handling Malformed Reports .....................................10
   5. Transport Considerations .......................................10
   6. Extensibility ..................................................10
   7. IANA Considerations ............................................11
      7.1. MIME Type Registration of 'message/feedback-report' .......11
      7.2. Feedback Report Header Fields .............................12
      7.3. Feedback Report Type Values ...............................15
   8. Security Considerations ........................................17
      8.1. Inherited from RFC 3462 ...................................17
      8.2. Interpretation ............................................17
      8.3. Attacks against Authentication Methods ....................17
      8.4. Intentionally Malformed Reports ...........................18
      8.5. Omitting Data from ARF Reports ............................18
      8.6. Automatically Generated ARF Reports .......................18
      8.7. Attached Malware ..........................................18
      8.8. The User-Agent Field ......................................18
      8.9. Malformed Messages ........................................19
   9. References .....................................................19
      9.1. Normative References ......................................19
      9.2. Informative References ....................................20
   Appendix A.  Acknowledgements .....................................22
   Appendix B.  Sample Feedback Reports ..............................22
      B.1.  Simple Report for Email Abuse without Optional Headers ...22
      B.2.  Full Report for Email Abuse with All Headers .............23

1. Introduction 🌈

Okay so spam keeps expanding and the solutions keep evolving, which means mail operators are trading abuse reports with each other and with other parties more and more. The problem? Every operator made up its own format, so receivers have to write custom software to read each one. 😩 Plus, lots of operators use other report formats to share non-abuse feedback about processed email. This memo uses the "multipart/report" content type defined in [REPORT], and within that context it creates a standard extensible format, the "message/feedback-report" [MIME] type, for these reports. 💖

There's been previous work here (e.g., [STRADS-BCP] and [ASRG-ABUSE]), but none of it has actually succeeded yet. 💀 Fingers crossed this doc gets a better fate. 🤞

This format is mainly meant to be an Abuse Reporting Format (ARF) for reporting email abuse, but it also supports direct feedback from end user mail clients, reports of some types of virus activity, and some similar issues. ✨ It also has room for extensions, in case other types of reports become desirable down the road. 🦋

This document only defines the format and the [MIME] content type used for these reports. Deciding where the reports should go, validating what's in them, and establishing trust between report generators and report recipients are all outside the scope of this doc. It's assumed that best practices will evolve over time and get codified in future documents. 📚

1.1. Purpose 🎯

The reports defined here are meant to inform mail operators about:

  • email abuse originating from their networks; 🚨
  • potential issues with the perceived quality of outbound mail, such as email service providers sending mail that catches the attention of automated abuse detection systems. 👀

Please note that even though the parent "multipart/report" content type defined in [REPORT] is used for all kinds of administrative messages, this format is intended specifically for communications among providers about email abuse and related issues. It SHOULD NOT be used for other reports. 🙅‍♀️

1.2. Requirements 📝

The following requirements are necessary for feedback reports (the actual specification comes later in this document):

  • they must be both human and machine readable; 🧠
  • a copy of the original email message (both body and header) or the message header must be enclosed so the receiver can handle the report properly; 📎
  • the machine-readable section must provide the ability for report generators to share meta-data with receivers; 🤖
  • the format must be extensible. 🧩

1.3. Definitions 📖

This section defines various terms used throughout this document. 💅

1.3.1. General 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 🔑✨

1.3.2. Email Specific 💌

[EMAIL-ARCH] introduces several terms and concepts used in this memo, so readers are advised to get familiar with it too. 🤓

2. Format of Email Feedback Reports 🎀

Okay here's the main event. To satisfy the requirements, an email feedback report is defined as a [MIME] message with a top-level MIME content type of "multipart/report" (as defined in [REPORT]). The following apply:

a. The "report-type" parameter of the "multipart/report" type is set to "feedback-report". 🏷️

b. The first MIME part of the message contains a human-readable description of the report and MUST be included. 👩‍💻

c. The second MIME part of the message is a machine-readable section with the content type "message/feedback-report" (defined later in this memo), and it MUST be included. This section conveys meta-data about the report in question that may not be readily available from the included email message itself. 🤖💜

d. The third MIME part of the message is either of type "message/rfc822" (as defined in [MIME-TYPES]) and contains the original message in its entirety, OR it is of type "text/rfc822-headers" (as defined in [REPORT]) and contains a copy of the entire header block from the original message. This part MUST be included (contrary to [REPORT]). Some operators may choose to modify or redact this portion for privacy or legal reasons, but it is RECOMMENDED that the entire original email message be included without any modification, because modifications can impede forensic work by the recipient of the report. See Section 8 for further discussion. 🔍

e. Except as discussed below, each feedback report MUST be related to only a single email message. Summary and aggregate formats are outside the scope of this specification. 📭

f. The Subject header field of the feedback report SHOULD be the same as the included email message the report is generated about. If it differs, the difference MUST be limited to only a typical forwarding prefix used by Mail User Agents (MUAs), such as "FW:". (Many smaller operators using MUAs for abuse handling rely on subject lines for processing, so this matters! 🥹)

g. The primary evidence of the abuse being reported is found in the third part of the report, which contains the original message. The second part contains additional derived data that may help the receiver, but when it comes to selecting actionable report data, report recipients SHOULD use the content of the third part first, then data from the second part. The first part is meant to contain explanatory text for human use. It is not itself a part of the report, and it SHOULD NOT be used if it conflicts with the other parts. 🕵️‍♀️💅

3. The 'message/feedback-report' Content Type ✨

okay so bestie 🎀 a brand new [MIME] content type called "message/feedback-report" is defined here. it's giving machine-readable section, and its whole job is letting the report generator spill meta-data to the report receiver 💅. the point is to share stuff that isn't obvious or easy to pull out of the original email body or header 🔍

the body is a bunch of "fields" formatted according to the ABNF of [MAIL] header fields. this section sets up the first batch of fields, and more can be registered later through the process described further down in this memo 🦋. these fields look a lot like mail header fields, but they mean something totally different, so they SHOULD NOT be repeated as header fields of the message containing the report 🙈. also, these fields are the receiver's way of asserting stuff about the report, and they aren't necessarily verifiable. so report receivers MUST NOT assume these assertions are always accurate. trust but verify, periodt 💀

quick note: that limitation does NOT stop you from using message header fields that are registered in the IANA header field registry with the same field names ✨

3.1. Required Fields

these report header fields MUST appear exactly once 👑:

  • Feedback-Type tells you the type of feedback report (as defined in the matching IANA registry and later in this memo). this is how report parsers tell different report types apart 🧚
  • User-Agent shows the name and version of the software program that made the report 💖. the format MUST follow section 14.43 of [HTTP]. this field is just for documentation, because there's no registry of user agent names or versions, so report receivers SHOULD NOT expect user agent names to belong to a known set 🌈
  • Version says which version of this specification the report generator used. in this spec, the version number is set to "1" 🌸

3.2. Optional Fields Appearing Once

these header fields are optional, and they MUST NOT appear more than once 🍓:

  • Original-Envelope-Id holds the envelope ID string from the original [SMTP] transaction (see section 2.2.1 of [DSN]) ✨
  • Original-Mail-From has a copy of the email address used in the MAIL FROM part of the original SMTP transaction. the format is the "Reverse-path" from section 4.1.2 of [SMTP] 💅
  • Arrival-Date is the date and time when the original message got received by the Mail Transfer Agent (MTA) of the generating ADMD (Administrative Management Domain) 🕰️. this field MUST be formatted as per section 3.3 of [MAIL] 🎀
  • Reporting-MTA is the name of the MTA that generated this feedback report. it's defined in section 2.2.2 of [DSN], except it's an optional field in this report 🦋
  • Source-IP contains an IPv4 or IPv6 address of the MTA the original message came from 🔥. addresses MUST be formatted as per section 4.1.3 of [SMTP] 💜
  • Incidents is an unsigned 32-bit integer for how many incidents the report represents 🔢. if this field is missing, the report is understood to cover a single incident 🫶

the historic field Received-Date SHOULD also be accepted, and it gets interpreted exactly like Arrival-Date 🕰️. BUT if both show up, the report is malformed, and it SHOULD be treated as described in Section 4. drama, but make it procedural 😭

3.3. Optional Fields Appearing Multiple Times

these header fields are optional, and they may show up any number of times as needed 🌟:

  • Authentication-Results shows the result of one or more authentication checks run by the report generator 🔐. the format is defined in [AUTH-RESULTS]. report receivers should note that this field is only the report generator making an assertion 🧐
  • Original-Rcpt-To includes a copy of the email address used in the RCPT TO part of the original [SMTP] transaction. the format is a "Reverse-path" from section 4.1.2 of that memo 💌. this field SHOULD be repeated for every SMTP recipient the report generator saw 🫶
  • Reported-Domain has a domain name the report generator thinks is relevant, like the domain whose apparent actions set off the report 👀. it's unspecified how the generator figures that out, so the receiver can't be certain how it got picked 🤷‍♀️. it's often used to hint at how the report should be handled 💅. when the reasoning isn't obvious, the generator is encouraged to explain it in the text section of the report 📝. domain format is defined in section 2.3.1 of [DNS] 🌸
  • Reported-URI is a URI the report generator thinks matters, like a sus URI found in the message that caused the report 🚩. the same caveats about where Reported-Domain came from apply to this field too ✨. the URI format is defined in [URI] 🦋

3.4. Notes about URIs

implementors should be aware that Reported-URI can carry a bunch of different kinds of data, depending on the URI scheme 🌈. for more info, check out the "URI Schemes" registry that IANA maintains 💜.

also, it's outside the scope of this standard whether the data in this field implies any extra information 🙃. implementors may negotiate their own agreements about how to interpret this data 🤝.

3.5. Formal Definition

the formal definition of what goes inside a "message/feedback-report" media type, written in [ABNF], looks like this 🧚:

feedback-report = *( feedback-type / user-agent / version )
                  opt-fields-once
                  *( opt-fields-many )
                  *( ext-field )

feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF
    ; the "token" must be a registered feedback type as
    ; described elsewhere in this document

user-agent = "User-Agent:" [CFWS] product *( CFWS product )
             [CFWS] CRLF

version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
    ; as described above

opt-fields-once = [ arrival-date ]
                  [ incidents ]
                  [ original-envelope-id ]
                  [ original-mail-from ]
                  [ reporting-mta ]
                  [ source-ip ]

arrival-date = "Arrival-Date:" [CFWS] date-time CRLF

incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
          ; must be a 32-bit unsigned integer

original-envelope-id = "Original-Envelope-Id:" [CFWS]
                       envelope-id [CFWS] CRLF

original-mail-from = "Original-Mail-From:" [CFWS]
                     reverse-path [CFWS] CRLF

reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";"
                [CFWS] mta-name [CFWS] CRLF

source-ip = "Source-IP:" [CFWS]
            ( IPv4-address-literal /
              IPv6-address-literal ) [CFWS] CRLF

opt-fields-many = [ authres-header ]
                  [ original-rcpt-to ]
                  [ reported-domain ]
                  [ reported-uri ]

original-rcpt-to = "Original-Rcpt-To:" [CFWS]
                   forward-path [CFWS] CRLF

reported-domain = "Reported-Domain:" [CFWS]
                  domain [CFWS] CRLF

reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF

ext-field = field-name ":" unstructured

a set of fields that satisfies this ABNF can show up in the transmitted message in any order 🌀.

"CRLF" and "DIGIT" are imported from [ABNF] 🫧.

"token" is imported from [MIME] 🎀.

"product" is imported from [HTTP] 💅.

"field-name", "unstructured", "CFWS", "date-time", and "domain" are imported from [MAIL] ✨.

"envelope-id", "mta-name-type", and "mta-name" are imported from [DSN] 🦋.

"reverse-path", "forward-path", "local-part", "IPv4-address-literal", and "IPv6-address-literal" are imported from [SMTP] 💌.

"URI" is imported from [URI] 🌸.

"authres-header" is imported from [AUTH-RESULTS] 🔐.

"ext-field" refers to extension fields, which get covered in Section 6 🧚.

4. Handling Malformed Reports 🚨

when an agent that accepts and handles ARF messages gets a message that claims (by MIME type) to be an ARF message but doesn't follow this spec syntactically, that agent SHOULD ignore or reject the message 🙅‍♀️. if it rejects it, the rejection notice (either through an [SMTP] reply or a generated [DSN]) SHOULD identify the specific reason for the rejection 📝.

see Section 8.9 for more discussion 💜.

5. Transport Considerations 🚚

[DSN] requires that its reports get sent with the empty [SMTP] envelope sender, so you don't get bounce loops 🔁. a similar requirement was considered for this spec, but it's pretty unlikely that an ARF report gets generated in response to receiving an ARF report 🙃. also, that kind of requirement would stop an ARF generator from ever figuring out that an ARF report was never actually received 😭.

BUT, if an ARF report gets generated without the empty envelope sender and gets sent to an address that doesn't actually work, the generating address can get buried under DSNs as a denial-of-service attack (see Section 8.6) 🌪️. yikes.

so this specification makes no requirement about the envelope sender of a generated report 🫶. operators have to figure out what envelope sender to use for their own installations 🛠️.

6. Extensibility 🧩

like lots of other formats and protocols, this format may need to be extended over time to keep up with the ever-changing Internet 🌍. so extensibility comes through two IANA registries: one for feedback types, and one for report header fields 🎀. the feedback type registry gets used together with the "Feedback-Type" field above 💅. the header name registry is for registering new meta-data fields to use in the machine-readable part (part 2) of this format ✨. heads up: version numbers don't change with new field registrations unless a new spec for this format gets published 🌸. also, all new field registrations may only be registered as optional fields. any new required fields REQUIRE a new version of this specification to be published 🚫.

to keep this format extensible and interoperable, implementors MUST ignore any fields or report types they don't explicitly support 🫧.

extension report types or report header fields might get defined in the future, either by later revisions of this spec or through the registrations described above 🔮. those types and fields MUST be registered as described above and published in an Open Specification, like an RFC 📜.

experimental report types and report header fields MUST only be used between ADMDs that have explicitly consented to use them 🚧. these names, and the parameters attached to them, aren't documented in RFCs. so they can change at any time and are NOT suitable for general use 💀.

7. IANA Considerations 📚

okay, IANA has registered a new [MIME] type and created two new registries, as described below 🦋.

7.1. MIME Type Registration of 'message/feedback-report' 📮

okay bestie, this is the paperwork that goes to IANA so they can register the media type 💅 it's giving official form energy, so I kept every line exactly as written:

To:  ietf-types@iana.org

Subject:  Registration of media type message/feedback-report

Type name:  message

Subtype name:  feedback-report

Required parameters:  none

Optional parameters:  none

Encoding considerations:  "7bit" encoding is sufficient and MUST be
   used to maintain readability when viewed by non-MIME mail readers.

Security considerations:  See Section 8 of [RFC5965].

Interoperability considerations:  Implementors MUST ignore any fields
   they do not support.

Published specification:  [RFC5965]

Applications that use this media type:  Abuse helpdesk software for
   ISPs, mail service bureaus, mail certifiers, and similar
   organizations

Additional information:  none

Person and email address to contact for further information:

      Yakov Shafranovich <ietf@shaftek.org>

      Murray S. Kucherawy <msk@cloudmark.com>

Intended usage:  COMMON

Author:

      Yakov Shafranovich

      John R. Levine

      Murray S. Kucherawy

Change controller:  IESG

7.2. Feedback Report Header Fields 🎀

okay so IANA made the "Feedback Report Header Fields" registry 🗂️ it holds the header fields you can use in feedback reports, as this memo defines them. two things to know:

  • New registrations or updates MUST be published under the "Specification Required" guidelines described in [IANA]. Any new field registered this way is considered optional by this specification unless a new version of this memo comes out. 💖
  • New registrations and updates MUST include the following info:
  1. The name of the field being registered or updated
  2. A short description of the field
  3. Whether the field can appear more than once
  4. Which feedback type(s) the field applies to (or "any")
  5. The document that publishes the specification of the field
  6. The new or updated status, which MUST be one of:
    • current: The field is in current use
    • deprecated: The field is in current use but its use is discouraged
    • historic: The field is no longer in current use

An update can add a note on an existing registration saying a registered field is historic or deprecated, if that fits. ✨ Here's the initial registry, verbatim:

Field Name: Arrival-Date
Description: date/time the original message was received
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Authentication-Results
Description: results of authentication check(s)
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Feedback-Type
Description: registered feedback report type
Multiple Appearances: No
Related "Feedback-Type": N/A
Published in: [RFC5965]
Status: current
Field Name: Incidents
Description: expression of how many similar incidents are
             represented by this report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Original-Mail-From
Description: email address used in the MAIL FROM portion of the
             original SMTP transaction
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Original-Rcpt-To
Description: email address used in the RCPT TO portion of the
             original SMTP transaction
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Received-Date
Description: date/time the original message was received
             (replaced by "Arrival-Date")
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: historic


Field Name: Reported-Domain
Description: a domain name the report generator considers to
             be key to the message about which a report is
             being generated
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current
Field Name: Reported-URI
Description: a URI the report generator considers to be key
             to the message about which a report is being
             generated
Multiple Appearances: Yes
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Reporting-MTA
Description: MTA generating this report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Source-IP
Description: IPv4 or IPv6 address from which the original message
             was received
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: User-Agent
Description: name and version of the program generating the
             report
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current


Field Name: Version
Description: version of specification used
Multiple Appearances: No
Related "Feedback-Type": any
Published in: [RFC5965]
Status: current

7.3. Feedback Report Type Values 🦋

same energy, different registry 🧚 this one is the "Feedback Report Type Values" registry, which holds the feedback types defined by this memo.

  • New registrations or updates MUST be published under the "Specification Required" guidelines described in [IANA]. Any new field registered this way is considered optional by this specification unless a new version of this memo comes out. 🌸
  • New registrations MUST include the following info:
  1. The name of the feedback type being registered
  2. A short description of the feedback type
  3. The document that publishes the specification of the field
  4. The new or updated status, which MUST be one of:
    • current: The field is in current use
    • deprecated: The field is in current use but its use is discouraged
    • historic: The field is no longer in current use

The initial registry looks like this 👇

Feedback Type Name: abuse
Description: unsolicited email or some other kind of email abuse
Published in: [RFC5965]
Status: current


Feedback Type Name: fraud
Description: indicates some kind of fraud or phishing activity
Published in: [RFC5965]
Status: current


Feedback Type Name: other
Description: any other feedback that does not fit into other
             registered types
Published in: [RFC5965]
Status: current


Feedback Type Name: virus
Description: report of a virus found in the originating message
Published in: [RFC5965]
Status: current

8. Security Considerations 🔒

okay this section is seriously important, so I'm keeping all the warnings intact 💀 the following security considerations apply when you generate or process a feedback report.

8.1. Inherited from RFC 3462 🧾

everything in the Security Considerations from [REPORT] gets inherited here, no exceptions 🫶

8.2. Interpretation 🕵️

this spec describes a report format, that's it. the authentication and validity of a report's content SHOULD be established through other means 🙈 an unvetted report could be wrong, incomplete, or deliberately false. that includes the alleged abuse incident in the third part, the derived data in the second part, and the human-readable first part.

there's going to be a big urge to automate actions so you can respond fast to common reports 🤖 caution must be taken though, because there's no real security around the content of these reports. an attacker could craft a report designed to trigger unwanted actions from a report recipient. ⚠️

it's suggested that you vet where an ARF report came from before doing any automated action, using common message authentication schemes like [SMIME], [DKIM], [SPF], or [SENDERID]. S/MIME gives the strongest authentication, and the cost of key exchange is assumed when you set up a bilateral reporting relationship that uses this spec. it's not as transparent as the others, though, so it will get in the way of code built specifically to handle multipart/report messages. 🔐

how exactly you validate all this is a matter of local policy, so it's outside the scope of this spec 🌈

8.3. Attacks against Authentication Methods 🎭

if an attack becomes known against an authentication method, the agent checking that method can be tricked into believing an inauthentic message is authentic. so the value of this header field can be misleading 😭 it follows that any attack against an authentication method that might protect the authenticity of an abuse report is also a security consideration here.

8.4. Intentionally Malformed Reports 💣

an attacker can generate an ARF message field that's extraordinarily large or otherwise malformed, trying to find or exploit weaknesses in recipient parsing code 👀 implementors SHOULD thoroughly verify all such messages and be robust against messages that are malformed on purpose as well as by accident. 🛡️

8.5. Omitting Data from ARF Reports 🙊

sending these reports can reveal private information about the person who sends them. for example, a report sent in response to a mailing list posting will reveal to the report recipient a valid email address on the list that might otherwise have stayed hidden 😳

so report generators might want to redact parts of the report to hide private info. that could be necessary where privacy outweighs operational need. but, as mentioned in Section 2, it might get in the way of a timely or meaningful response from the report recipient. 🫠

8.6. Automatically Generated ARF Reports 🤖

some systems automatically generate ARF reports in response to an event. for example, software watching a honeypot email address might generate an ARF report right when any message is delivered to it 🍯 an attacker who knows about a setup like this can use it to flood an ARF recipient with automatically generated reports. 🚨

8.7. Attached Malware 🦠

this format is sometimes used to automatically report malware, so ARF processors (human or otherwise) SHOULD make sure attachments get handled in a way that's right for unverified and potentially hostile data 🧯

8.8. The User-Agent Field 🙅‍♀️

building on Section 8.2, the User-Agent field is just a claim by the software that generated it. the memo doesn't specify it, and it isn't derived from the message in the third part of the report 💅 it's meant for documentation and debugging. since a malicious agent can forge it trivially, it SHOULD NOT be interpreted by recipients. 💜

8.9. Malformed Messages 🙈

okay so this one is about the times an ARF processing agent decides to be extra chill and accept messages that don't follow this spec 😬 Like, during transition periods where some fields are heading toward "historic" or "deprecated" status, or when someone adds new non-standard extension or experimental fields. Remember the discussion in Section 4? This is that, but make it spicy. 🌶️

Those choices need to be implemented with extreme caution ⚠️ Here's why: if two fields have related meaning, like "Received-Date" (historic) and "Arrival-Date" (current), an attacker could craft a report that makes a confusing claim and try to exploit that super liberal parsing logic. Not cute 💀

9. References 📚

9.1. Normative References

[ABNF]          Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", STD 68, RFC 5234,
                 January 2008.

[AUTH-RESULTS]  Kucherawy, M., "Message Header Field for Indicating
                 Message Authentication Status", RFC 5451, April 2009.

[DNS]           Mockapetris, P., "Domain names - implementation and
                 specification", STD 13, RFC 1035, November 1987.

[DSN]           Moore, K. and G. Vaudreuil, "An Extensible Message
                 Format for Delivery Status Notifications", RFC 3464,
                 January 2003.

[HTTP]          Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee,
                 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                 June 1999.

[KEYWORDS]      Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[MAIL]          Resnick, P., Ed., "Internet Message Format",
                 RFC 5322, October 2008.

[MIME]          Freed, N. and N. Borenstein, "Multipurpose Internet
                 Mail Extensions (MIME) Part One: Format of Internet
                 Message Bodies", RFC 2045, November 1996.

[MIME-REG]      Freed, N. and J. Klensin, "Media Type Specifications
                 and Registration Procedures", BCP 13, RFC 4288,
                 December 2005.

[MIME-TYPES]    Freed, N. and N. Borenstein, "Multipurpose Internet
                 Mail Extensions (MIME) Part Two: Media Types",
                 RFC 2046, November 1996.

[REPORT]        Vaudreuil, G., "The Multipart/Report Content Type for
                 the Reporting of Mail System Administrative
                 Messages", RFC 3462, January 2003.

[SMTP]          Klensin, J., "Simple Mail Transfer Protocol",
                 RFC 5321, October 2008.

[URI]           Berners-Lee, T., Fielding, R., and L. Masinter,
                 "Uniform Resource Identifier (URI): Generic Syntax",
                 STD 66, RFC 3986, January 2005.

9.2. Informative References 🧠

[ASRG-ABUSE]    Anti-Spam Research Group (ASRG) of the Internet
                 Research Task Force (IRTF), "Abuse Reporting
                 Standards Subgroup of the ASRG", May 2005.

[DKIM]          Allman, E., Callas, J., Delany, M., Libbey, M.,
                 Fenton, J., and M. Thomas, "DomainKeys Identified
                 Mail (DKIM) Signatures", RFC 4871, May 2007.

[EMAIL-ARCH]    Crocker, D., "Internet Mail Architecture", RFC 5598,
                 July 2009.

[IANA]          Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26,
                 RFC 5226, May 2008.

[SENDERID]      Lyon, J. and M. Wong, "Sender ID: Authenticating
                 E-Mail", RFC 4406, April 2006.

[SMIME]         Ramsdell, B. and S. Turner, "Secure/Multipurpose
                 Internet Mail Extensions (S/MIME) Version 3.2 Message
                 Specification", RFC 5751, January 2010.

[SPF]           Wong, M. and W. Schlitt, "Sender Policy Framework
                 (SPF) for Authorizing Use of Domains in E-Mail,
                 Version 1", RFC 4408, April 2006.

[STRADS-BCP]    Crissman, G., "Proposed Spam Reporting BCP Document",
                 May 2005.

Appendix A. Acknowledgements 🫶

Huge thank-you to the authors, who gave shoutouts to the many people in the email community who sent helpful comments and suggestions for this document 💖 That includes lots of folks from ASRG, IETF, and MAAWG activities, plus everyone on the abuse-feedback-report public mailing list. Iconic teamwork ✨

Appendix B. Sample Feedback Reports 🎀

This section shows some examples of using this message format to report feedback about an arriving message. Let's see the vibes 👀

B.1. Simple Report for Email Abuse without Optional Headers 💌

Simple report:

From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
     boundary="part1_13d.2e68ed54_boundary"

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP
192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.  For more information
about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mailserver.example.net
     (mailserver.example.net [192.0.2.1])
     by example.com with ESMTP id M63d4137594e46;
     Thu, 08 Mar 2005 14:00:00 -0400

From: <somespammer@example.net>
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

Example 1: Required fields only

Illustration of a feedback report generated according to this specification. Only the required fields are used. Clean and minimal, love that for us 🧚

B.2. Full Report for Email Abuse with All Headers 🌈

A full email abuse report 🔥

From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
     boundary="part1_13d.2e68ed54_boundary"

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP
192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.  For more information
about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
               spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
     [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
     Thu, 08 Mar 2005 14:00:00 -0400

To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

Example 1: Generic abuse report with maximum returned information

A contrived example in which the report generator has returned all possible information about an abuse incident. Everything, all at once 💅

Authors' Addresses 💌

Yakov Shafranovich
ShafTek Enterprises
4014 Labyrinth Rd.
Baltimore, MD  21215
US

EMail: ietf@shaftek.org
URI:   http://www.shaftek.org


John R. Levine
Taughannock Networks
PO Box 727
Trumansburg, NY  14886
US

Phone: +1 831 480 2300
EMail: standards@taugh.com


Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA  94107
US

Phone: +1 415 946 3800
EMail: msk@cloudmark.com
📦 where this page comes from