Home / Blogs

ARF is Now an IETF Standard

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!

By John Levine, Author, Consultant & Speaker

Filed Under


It is actually a proposed standard Jaap Akkerhuis  –  Sep 1, 2010 9:48 PM

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 Jothan Frakes  –  Sep 4, 2010 4:07 AM

Congratulations, John.  And I love the new ackronym.

Deployment? The Famous Brett Watson  –  Sep 10, 2010 5:56 AM

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?

The downside of standardizing existing practice Alessandro Vesely  –  Sep 12, 2010 10:01 AM

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 John Levine  –  Sep 10, 2010 2:43 PM

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.

"Arrival-Date" and "Received-Date" Anthony Edwards  –  Oct 5, 2010 6:33 PM

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.

It's in the RFC The Famous Brett Watson  –  Oct 5, 2010 11:14 PM

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.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API