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


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


It is actually a proposed standard Jaap Akkerhuis  –  Sep 01, 2010 2:48 PM PDT

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 9:07 PM PDT

Congratulations, John.  And I love the new ackronym.

Deployment? The Famous Brett Watson  –  Sep 09, 2010 10:56 PM PDT

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 3:01 AM PDT

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 7:43 AM PDT

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 11:33 AM PDT

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 4:14 PM PDT

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

Related News

Explore Topics

Dig Deeper

IP Addressing

Sponsored by Avenue4 LLC


Sponsored by Verisign

DNS Security

Sponsored by Afilias

Mobile Internet

Sponsored by Afilias Mobile & Web Services

Promoted Posts

Buying or Selling IPv4 Addresses?

Watch this video to discover how ACCELR/8, a transformative trading platform developed by industry veterans Marc Lindsey and Janine Goodman, enables organizations to buy or sell IPv4 blocks as small as /20s. more»

Industry Updates – Sponsored Posts

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Port25 Announces Release of PowerMTA V4.5r5

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

An Update on Port25 and the Future of PowerMTA - One Year Later​

Encrypting Inbound and Outbound Email Connections with PowerMTA

V12 Group Sustains Customer Satisfaction by Deploying PowerMTA for Launchpad Platform

PowerMTA Now Offers Scheduled Delivery Control

DKIM for ESPs: The Struggle of Living Up to the Ideal

Reactivation Campaign: Shared vs. Dedicated IPs

To Where are Bounce Messages Sent?

An Open Source Perspective on Commercial MTAs

Five Essential PowerMTA Configuration Tips

What's New With Port25's PowerMTA v4.5

New Feature in PowerMTA v4.5: IP Based Rate Limiting

Case Study: Emergency Response Systems Rely on Timely Messaging Through PowerMTA

Port25 Announces Next Major Release of Its Email Delivery Solution, PowerMTA

Case Study: How PowerMTA Transparent Deliverability Metrics Paves Way for Email Service Provider

Case Study: MailChimp Achieves Efficient Execution and Reliability with PowerMTA

Case Study: Emma Swaps Its SMTP Infrastructure for PowerMTA to Handle Growing Mail Volume