ARF

This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for Message Originators and Mailbox Providers.

The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFC Stream and was not subject to the IETF's approval process.

This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]

This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.

This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]

This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]