Home / Blogs

ARF is Now an IETF Standard

John Levine

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. More blog posts from John Levine can also be read here.

Related topics: Email, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


It is actually a proposed standard 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 Jothan Frakes  –  Sep 03, 2010 8:07 PM PST

Congratulations, John.  And I love the new ackronym.

Deployment? 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 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 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" 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 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.

To post comments, please login or create an account.

Related Blogs

End-to-End Email Encryption - This Time For Sure?

Coordinating Attack Response at Internet Scale

Who Is Sending Email As Your Company?

When DNSBLs Go Bad

Email Vendors: Time to Build in DMARC

Related News


Industry Updates – Sponsored Posts

Non-English "IDN Email" Addresses Are Finally Working!

A Look Inside Dyn's 1.2 Billion Monthly Email Delivery Statistics

Dyn to Host Email Analytics Webinar With Ongage

Dyn Adds Claudia Santoro, Dave Connors and Andrew Sullivan to Technical Team

Dyn Receives $38M Investment from North Bridge

Nominum Launches Comprehensive Suite of DNS-Based Security Solutions for Russian Service Providers

Nominum Sets New Record for Network Speed and Efficiency

DNS on Defense, DNS on Offense

Managing Outbound Spam: A New DNS-based Approach For Stopping Abuse (Webinar)

MarkMonitor Fraud Intelligence Report, Q4 2011

MarkMonitor Fraud Intelligence Report Released for Q2 2011

Dyn Releases New Powerhouse in Enterprise Class Email Delivery

The Botnet-Counterfeit Drugs Connection

Global Company Leads the Pack as One of the First Microsoft Partners to Offer Exchange 2010

Dyn Inc. Acquires Email Delivery Provider SendLabs

Afilias and .JO Registry Bring Native Language E-mail to Arabic Internet Users

New Monthly Fraud Intelligence Report Now Available

MarkMonitor to Highlight Importance of Cross-Functional Approach to Brand Protection

Preventing Your DNS Account from Being Hacked

Paid Search Ads Can Lead to Fake Goods

Sponsored Topics



Sponsored by


Sponsored by
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines

DNS Security

Sponsored by