Technical Summary
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.
Working Group Summary
The primary contention point in the development of this document involved
what and how much to include, striking a balance between an Applicability
Statement and an "implementation cookbook". Because we have limited
recent experience with Applicability Statements, the participants were not
sure what belongs in them, and what constitutes "too much detail" that's
best left for other forms of documentation.
In the end, the working group produced a version that most of the
participants could be happy with, and the document as presented has the
broad support of the MARF working group.
Document Quality
This document reflects the current MARF implementations in the field,
of which there are many. That said, we do expect that it might be
modified over time, as the MARF base specification itself matures along
the Standards Track.
Personnel
Barry Leiba is the document shepherd; Pete Resnick is the
responsible AD.
RFC Editor Notes
Please make the following changes to -16:
OLD (Section 1):
Further introduction to this topic may be found in [RFC6449], which
is effectively an Applicability Statement written outside of the IETF
and thus never achieved IETF consensus. Much of the content for that
document was input to this one.
NEW:
Further introduction to this topic may be found in [RFC6449], which
has more information about the general topic of abuse reporting. Many
of the specific ARF guidelines in this document were taken from the
principles presented in [RFC6449].
OLD (Section 5.1):
2. Message authentication is generally a good idea, but it is
especially important to encourage credibility of and thus
response to unsolicited reports. Therefore, as with any other
message, Feedback Providers sending unsolicited reports SHOULD
send reports that they believe will pass Sender Policy Framework
([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.
NEW:
2. Message authentication is generally a good idea, but it is
especially important to encourage credibility of and thus
response to unsolicited reports. Therefore, as with any other
message, Feedback Providers sending unsolicited reports SHOULD
send reports that they expect will pass Sender Policy Framework
([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.