ARF Sample Report

An ARF report is a multipart MIME message consisting of three sections - a human readable description, machine-readable metadata and a copy of the original email.

The contents of the report are an assertion by the report sender to the report recipient. In the absence of any contractual agreement between the report sender and the report recipient there is no guarantee that any of the included data is correct. The report recipient might monitor the behaviour of report senders in order to judge their reputation and estimate the accuracy of a report - though in the case of formal feedback loops, likely to be the majority of ARF format reports, the report sender is likely to state the elements of the report that will be accurate.

Email headers of the report 
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
        boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This human readable section will not usually be read by recipients that recognise the ARF format, but will probably be preserved for recipients to read should the message be flagged for human attention. 
This is an email abuse report for an email message
received from IP 10.67.41.167 on Thu, 8 Mar 2005
14:00:00 EDT.
For more information about this format please see
http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
This metadata is the main means of communication between the sender of the report and the recipient, beyond the mail being reported. The data here will likely be used to triage, route and prioritise the report, and in many cases may be used to handle the report automatically.
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
The email that the report is about. While ideally this would be an unmodified copy of the original email it is likely that many senders of reports will modify or falsify elements of the report. Recipients of reports should not necessarily rely on the accuracy of elements of this attached message, especially the original message recipients email address. While report recipients will be able to recognise how particular report senders falsify this part of the report they would be well advised to, where possible, take any critical information that they need to maintain through the round trip of the message and record it in an encrypted and authenticated manner, and to only pay attention to reports where that data should be in the message where it is in the message and authenticates correctly.
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
          [10.67.41.167])
          by example.com with ESMTP id M63d4137594e46;
          Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--