Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
draft-ietf-marf-as-01

Abstract

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes one common method for utilizing this format for reporting at scale between large mailbox providers, and from large mailbox providers to other mail sending entities.

[NOTE TO EDITOR: Murray Kucherawy is listed as an author only to enable him to complete the publication process on behalf of J.D. Falk. Please remove Murray from the author list prior to publication.]

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Copyright Notice

Copyright (c) 2011 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

The Abuse Reporting Format (ARF) was initially developed for two very specific use cases. Initially, it was intended to be used for reporting feedback between large email operators, or from large email operators to end user network access operators, any of whom could be presumed to have automated abuse-handling systems. Secondarily, it is used by those same large mail operators to send those same reports to other entities, including those involved in sending bulk email for commercial purposes. In either case, the reports would be triggered by direct end user action such as clicking on a "report spam" button in their email client.

Though other uses for the format defined in [RFC5965] have been discussed (and may be documented similarly in the future), those were (and remain) the primary applications.

Further introduction to this topic may be found in [RFC6449].

2. Definitions

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 [RFC2119], and are intended to replace the Requirement Levels described in Section 3.3 of [RFC2026].

Some of the terminology used in this document is taken from [RFC5598].

"Mailbox Provider" refers to an organization that accepts, stores, and offers access to [RFC5322] messages ("email messages") for end users. Such an organization has typically implemented SMTP ([RFC5321]), and might provide access to messages through IMAP ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for HTTP ([RFC2616]), or a proprietary protocol.

3. Applicability Statement?

[RFC Editor: please remove this section prior to publication.]

This document is part of the experiment to reintroduce Applicability Statements, as defined in Section 3.2 of [RFC2026], to the Applications Area.

4. Discussion

[RFC Editor: please remove this section prior to publication.]

This document is being discussed within the IETF MARF Working Group, on the marf@ietf.org mailing list.

5. Creating and Sending Complaint-Based Reports

1. A Mailbox Provider receives reports of abusive or unwanted mail from its users, most often by providing a "report spam" button (or similar nomenclature) in the MUA. The method of transferring this message and any associated metadata from the MUA to the Mailbox Provider's ARF processing system is not defined by any standards document, but is discussed further in Section 3.2 of [RFC6449]. Policy concerns related to the collection of this data are discussed in Section 3.4 of that document.
2. The Mailbox Provider SHOULD process the reports to improve its spam filtering systems. The design of these systems is discussed in [RFC2505] and elsewhere.
3. The Mailbox Provider SHOULD send reports to relevant parties who have requested to receive such reports. The reports MUST be formatted per [RFC5965], and transmitted as an email message ([RFC5322]), typically using SMTP ([RFC5321]). The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449].
4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other types as appropriate. However, the Mailbox Provider generating the reports SHOULD NOT assume that the operator receiving the reports will treat different Feedback-Types differently.
5. The reports SHOULD include the following optional fields whenever practical: Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. Other optional fields MAY be included, as the implementer feels is appropriate.
6. Ongoing maintenance of an ARF processing system is discussed in Section 3.6 of [RFC6449].

6. Receiving and Processing Complaint-Based Reports

1. At the time this document is being written, for the use cases described here, mail operators need to proactively request a stream of ARF reports from Mailbox Providers. Recommendations for preparing to make that request are discussed in Section 4.1 of [RFC6449].
2. Mail operators MUST be prepared to receive reports formatted per [RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]). These and other types of email messages that may be received are discussed in Section 4.2 of [RFC6449].
3. Mail operators SHOULD utilize an automated system to receive and process these reports, as discussed in Section 4.4 of [RFC6449].
4. That system MUST accept all Feedback-Types defined in [RFC5965] or extensions to it, but implementors SHOULD NOT assume that Mailbox Providers will make use of any Feedback-Type other than "abuse". Additional logic may be required to separate different types of abuse reports after receipt.
5. Implementors SHOULD NOT expect all Mailbox Providers to include the same optional fields.
6. Actions that mail operators might take upon receiving a report (or multiple reports) are discussed in Section 4.3 of [RFC6449].

7. Other Applications

What is described here is the most common application of [RFC5965], and provides a starting point for additional applications, but it is certainly not the only possible application. Other uses for ARF could include direct complaint submissions from MUAs, reports triggered by mail sent to "spam trap" or "honeypot" addresses without human involvement, reports of authentication failures, virus reports, and so forth. These applications might be described in future IETF documents.

8. IANA Considerations

[RFC Editor: please remove this section prior to publication.]

This document has no IANA actions.

9. Security Considerations

Implementers are strongly urged to review, at a minimum, the Security Considerations sections of [RFC5965] and [RFC6449].

10. Acknowledgements

All of the Best Practices referenced by this document are found in [RFC6449], written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG) -- which is described further in [RFC6449].

Finally, I must thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what they do.

11. References

11.1. Normative References

11.2. Informative References

Authors' Addresses

Table of Contents

• 1. Introduction
• 2. Definitions
• 3. Applicability Statement?
• 4. Discussion
• 5. Creating and Sending Complaint-Based Reports
• 6. Receiving and Processing Complaint-Based Reports
• 7. Other Applications
• 8. IANA Considerations
• 9. Security Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses