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

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


It is actually a proposed standard By Jaap Akkerhuis  –  Sep 01, 2010 1:48 pm PST

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 By Jothan Frakes  –  Sep 03, 2010 8:07 pm PST

Congratulations, John.  And I love the new ackronym.

Deployment? By The Famous Brett Watson  –  Sep 09, 2010 9:56 pm PST

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 By Alessandro Vesely  –  Sep 12, 2010 2:01 am PST

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 By John Levine  –  Sep 10, 2010 6:43 am PST

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" By Anthony Edwards  –  Oct 05, 2010 10:33 am PST

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 By The Famous Brett Watson  –  Oct 05, 2010 3:14 pm PST

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.

Add Your Comments

 To post your comments, please login or create an account.



New TLDs

Sponsored byAfilias

Brand Protection

Sponsored byAppdetex


Sponsored byThreat Intelligence Platform

DNS Security

Sponsored byAfilias

Domain Names

Sponsored byVerisign

IP Addressing

Sponsored byIPv4.Global


Sponsored byWhoisXML API


Sponsored byVerisign