|
When a user of a large mail system such as AOL, Yahoo, or Hotmail reports a message as junk or spam, one of the things the system does is to look at the source of the message and see if the source is one that has a feedback loop (FBL) agreement with the mail system. If so, it sends a copy of the message back to the source, so they can take appropriate action, for some version of appropriate. For several years, ARF, Abuse Reporting Format, has been the de-facto standard form that large mail systems use to exchange FBL reports about user mail complaints.
Until now, the only documentation for ARF was a draft spec originally written Yakov Shafranovich (CircleID) in 2005, and occasionally updated originally by him and later by other people including myself. Earlier this year, the IETF chartered a working group called MARF which took that draft, brought the references up to date, stripped out a lot of options that seemed useful five years ago but in practice nobody ever used, and this week it was finally published as RFC 5965.
ARF (or now MARF) is quite simple, a version of the existing Multipart/Report message format that includes information about the report, such as the address of the recipient, descriptive text for a human reader, and a copy of the offending message. Having a standard format for reports, simple though it is, makes them much easier to process. For my tiny system, for example, nearly all of the trickle of reports are about mailing list messages. When a FBL report arrives, an automated script looks at the report and the message, and in the usual case that it’s from a mailing list, it creates an unsubscribe request to remove the person from the list. Otherwise, it passes the message along to the human manager so I can decide what, if anything, to do about it. Larger mail systems also use them to collect statistics about their mail-sending customers.
The IETF process works particularly well when it standardizes existing practice, and ARF/MARF is an excellent example of that. The differences between the earlier drafts and the final version make it clearer and more precise, and it’s now a proper standard we can cite:
Abuse Reporting Format! Ask for it by name: RFC 5965!
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byVerisign
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byWhoisXML API
Not all RFC’s are an IETF Standard. This one is indeed on the standard track but a proposed standard, see
. I admit, a lot RFCs on the standards track don’t get Draft or Full Standard status. For details, of the various statuses see RFC 2026.
Apart from these critical notes, congrats.
Congratulations, John. And I love the new ackronym.
For those of us considering the implementation of an automated report handling system, is there anything important we should know about the differences between ARF (the draft) and RFC 5965? Also, how widespread is deployment at this time? If I code up support for RFC 5965 reports, to which feedback loops can I subscribe for immediate benefit?
Nothing has really changed, only the definition of the format is now official. The FBLs are the same as they were before, and even their ambiguity has been standardized, e.g. in phrases like "Reported-Domain" includes a domain name that the report generator believes to be relevant to the report. The MAAWG's Complaint Feedback Loop Best Current Practices [PDF] still suggest to deploy different handlers, based on the report's originator, that know the semantics of each field from the relevant subscription agreement.
The differences between the draft and the RFC are tiny, bump the version number to 1 and take out some options that nobody uses.
As far as who uses it, just about everyone other than Hotmail. AOL, Comcast, Yahoo, and Roadrunner do. Note that most large ISPs will only set up an FBL if you have your own range of IP addresses from which you send mail. Yahoo keys on DKIM signatures.
The former ARF format draft specified "Received-Date" as the message/feedback-report MIME part field to contain date and timestamp information, in contrast RFC 5965 now specifies "Arrival-Date". At present, however, everyone with the exception of spam trap operator Abusix appears to be still using "Received-Date". As a result, recipients of ARF/MARF format reports using an automated complaint processing script which looks for date and timestamp information in a message/feedback-report "Received-Date" field need to amend that to look for either "Received-Date" *or* "Arrival-Date" for the time being.
Thanks for the heads up. I note, however, that this is mentioned in the RFC at the end of section 3.2. Hopefully implementers are paying close enough attention to it.