fbpx
Wikipedia

Abuse Reporting Format

The Abuse Reporting Format (ARF) also known as the Messaging Abuse Reporting Format (MARF) is a standard format for reporting spam via email.

History edit

A draft describing a standard format for feedback loop (FBL) reports was posted by Yakov Shafranovich in April 2005[1] and evolved to the current RFC 5965.[2] AOL, who pioneered the field in 2003, initially used a different format, and converted to this de facto standard in 2008.[3] Feedback loops don't have to use ARF, but most do.

In January 2010, the IETF chartered[4] a new working group working towards the goal of standardizing the ARF format. The WG was called Messaging Abuse Reporting Format WG or MARF, which produced RFC 5965. In 2012 it was extended by RFC 6591 and RFC 6692 to define Failure Reports, for reporting email authentication failures. In 2015, the latter report type was further extended by RFC 7489 to define DMARC's Failure Reports.

Purpose edit

The ARF format is designed to be extensible, providing for generic spam reporting, e.g. from users to some anti-spam center or help desk, or for opt-out operations. The format defines a new MIME type to be included in a multipart/report attachment, and includes at least the headers of the offending message. Although the draft description acknowledges that some operators may choose to modify or redact that portion for privacy or legal reasons, it recommends that the entire original email message be attached, including the unmodified recipient address.

An ARF-encapsulated FBL report comes with the same subject as the offending message. Much like bounce messages, an abuse report consists of a human readable part, followed by a machine readable part, and the original message. The machine readable part's type is message/feedback-report, whose definition is the core of the draft. Extensibility is achieved by including a Feedback-Type field that characterizes the report. Possible values of this field are:

abuse
spam or some other kind of email abuse;
fraud
indicates some kind of fraud or phishing activity;
virus
report of a virus found in the originating message;
other
any other feedback that doesn't fit into other types;
not-spam
can be used to report an email message that was mistakenly marked as spam.[5]

An IANA registry is provided for the Feedback-Type, as well as for the other field names.[6] Each field name may either be relevant for any type of feedback, or for a specified type only. Some fields may appear multiple times. For example, the Source-IP field, containing the IP address from which the original message was received, may appear in any type of FBL report, but only once; the Removal-Recipient field, indicating email addresses to be removed, may only appear in opt-out reports, but one or more times. In addition, there is a DKIM-Failure subtype, with its own IANA registry.

An example report for email abuse is as follows. (Note that only the first three lines of the machine readable part are required.)

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 is an email abuse report for an email message received from IP 192.0.2.2 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 Feedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 1 Original-Mail-From: <somespammer@example.net> Original-Rcpt-To: <user@example.com> Received-Date: Thu, 8 Mar 2005 14:00:00 EDT Source-IP: 192.0.2.2 Authentication-Results: mail.example.com;  spf=fail smtp.mail=somespammer@example.com Reported-Domain: example.net Reported-Uri: http://example.net/earn_money.html Reported-Uri: mailto:user@example.com Removal-Recipient: user@example.com --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline From: <somespammer@example.net> Received: from mailserver.example.net (mailserver.example.net  [192.0.2.2]) by example.com with ESMTP id M63d4137594e46;  Thu, 8 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, 2 Sep 2004 12:31:03 -0500 Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary-- 

See also edit

References edit

  1. ^ Yakov Shafranovich (14 April 2005). . Shaftek.org. Archived from the original on 7 October 2008. Retrieved 17 November 2008.
  2. ^ John Levine (1 September 2010). "ARF is Now an IETF Standard". CircleID. from the original on 5 September 2010. Retrieved 12 September 2010.
  3. ^ Christine Borgia (27 June 2008). . AOL. Archived from the original on 2 December 2008. Retrieved 17 November 2008.
  4. ^ IETF. "MARF charter". Retrieved 26 January 2010.
  5. ^ Kepeng Li; Barry Leiba (November 2011). "Email Feedback Report Type Value: not-spam". PROPOSED STANDARD. IETF. Retrieved 11 November 2011.
  6. ^ "Messaging Abuse Reporting Format (MARF) Parameters". Protocol Registries. IANA. 26 May 2010. Retrieved 29 November 2011.

abuse, reporting, format, also, known, messaging, marf, standard, format, reporting, spam, email, contents, history, purpose, also, referenceshistory, edita, draft, describing, standard, format, feedback, loop, reports, posted, yakov, shafranovich, april, 2005. The Abuse Reporting Format ARF also known as the Messaging Abuse Reporting Format MARF is a standard format for reporting spam via email Contents 1 History 2 Purpose 3 See also 4 ReferencesHistory editA draft describing a standard format for feedback loop FBL reports was posted by Yakov Shafranovich in April 2005 1 and evolved to the current RFC 5965 2 AOL who pioneered the field in 2003 initially used a different format and converted to this de facto standard in 2008 3 Feedback loops don t have to use ARF but most do In January 2010 the IETF chartered 4 a new working group working towards the goal of standardizing the ARF format The WG was called Messaging Abuse Reporting Format WG or MARF which produced RFC 5965 In 2012 it was extended by RFC 6591 and RFC 6692 to define Failure Reports for reporting email authentication failures In 2015 the latter report type was further extended by RFC 7489 to define DMARC s Failure Reports Purpose editThe ARF format is designed to be extensible providing for generic spam reporting e g from users to some anti spam center or help desk or for opt out operations The format defines a new MIME type to be included in a multipart report attachment and includes at least the headers of the offending message Although the draft description acknowledges that some operators may choose to modify or redact that portion for privacy or legal reasons it recommends that the entire original email message be attached including the unmodified recipient address An ARF encapsulated FBL report comes with the same subject as the offending message Much like bounce messages an abuse report consists of a human readable part followed by a machine readable part and the original message The machine readable part s type is message feedback report whose definition is the core of the draft Extensibility is achieved by including a Feedback Type field that characterizes the report Possible values of this field are abuse spam or some other kind of email abuse fraud indicates some kind of fraud or phishing activity virus report of a virus found in the originating message other any other feedback that doesn t fit into other types not spam can be used to report an email message that was mistakenly marked as spam 5 An IANA registry is provided for the Feedback Type as well as for the other field names 6 Each field name may either be relevant for any type of feedback or for a specified type only Some fields may appear multiple times For example the Source IP field containing the IP address from which the original message was received may appear in any type of FBL report but only once the Removal Recipient field indicating email addresses to be removed may only appear in opt out reports but one or more times In addition there is a DKIM Failure subtype with its own IANA registry An example report for email abuse is as follows Note that only the first three lines of the machine readable part are required From lt abusedesk example com gt Date Thu 8 Mar 2005 17 40 36 EDT Subject FW Earn money To lt abuse example net gt 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 is an email abuse report for an email message received from IP 192 0 2 2 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 Feedback Type abuse User Agent SomeGenerator 1 0 Version 1 Original Mail From lt somespammer example net gt Original Rcpt To lt user example com gt Received Date Thu 8 Mar 2005 14 00 00 EDT Source IP 192 0 2 2 Authentication Results mail example com spf fail smtp mail somespammer example com Reported Domain example net Reported Uri http example net earn money html Reported Uri mailto user example com Removal Recipient user example com part1 13d 2e68ed54 boundary Content Type message rfc822 Content Disposition inline From lt somespammer example net gt Received from mailserver example net mailserver example net 192 0 2 2 by example com with ESMTP id M63d4137594e46 Thu 8 Mar 2005 14 00 00 0400 To lt Undisclosed Recipients gt Subject Earn money MIME Version 1 0 Content type text plain Message ID 8787KJKJ3K4J3K4J3K4J3 mail example net Date Thu 2 Sep 2004 12 31 03 0500 Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam part1 13d 2e68ed54 boundary See also editFeedback loop email References edit Yakov Shafranovich 14 April 2005 New Abuse Draft Shaftek org Archived from the original on 7 October 2008 Retrieved 17 November 2008 John Levine 1 September 2010 ARF is Now an IETF Standard CircleID Archived from the original on 5 September 2010 Retrieved 12 September 2010 Christine Borgia 27 June 2008 AOL Converting All FBLs to ARF on 9 2 08 AOL Archived from the original on 2 December 2008 Retrieved 17 November 2008 IETF MARF charter Retrieved 26 January 2010 Kepeng Li Barry Leiba November 2011 Email Feedback Report Type Value not spam PROPOSED STANDARD IETF Retrieved 11 November 2011 Messaging Abuse Reporting Format MARF Parameters Protocol Registries IANA 26 May 2010 Retrieved 29 November 2011 Retrieved from https en wikipedia org w index php title Abuse Reporting Format amp oldid 1210818848, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.