Messaging Abuse Reporting Format (marf) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Working Group Chair(s): Murray Kucherawy <msk@cloudmark.com> Barry Leiba <barryleiba@computer.org> Applications Area Director(s): Pete Resnick <presnick@qualcomm.com> Peter Saint-Andre <stpeter@stpeter.im> Applications Area Advisor: Pete Resnick <presnick@qualcomm.com> Mailing Lists: General Discussion:marf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/marf Archive: http://www.ietf.org/mail-archive/web/marf/ Description of Working Group: Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam, virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure and encourage future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. A report format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF was developed as a community effort within the context of a messaging trade organization independent of the IETF (MAAWG, http://www.maawg.org), and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility. Furthermore, some extensions to the current proposal are of interest to the community, such as the means for an operator to advertise an email address to which abuse reports using ARF should be sent. The working group will take on the task of considering and specifying such a mechanism. Existing ARF usage employs draft-shafranovich-feedback-report-08, which will provide the working group's starting point. The working group should consider such factors as: * implementation experience * ability to achieve broad implementation and interoperability * existing uses of ARF * internationalization * ability to address a wider range of uses Thus, the working group's specific tasks are as follows: 1) The group will first produce a Proposed Standard track specification of ARF. This will document current use, removing any portions that are not implemented and/or not required for a minimum implementation (these may be considered for extensions at some later date if demand warrants). This will include not only the format of an ARF message, but must also include appropriate documentation of security considerations and creation of IANA registries for elements of ARF to support future extensions, as well as informational sections conveying current best practices. 2) The group will produce an informational document detailing guidelines for deploying and using ARF, including descriptions of current practices and their rationales. 3) The group will specify the integration of ARF into DKIM-aware environments, with draft-kucherawy-dkim-reporting-06 as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing ("fraud") and as such are relevant to the ARF effort. The group will produce Proposed Standard track specification for these ARF and DKIM extensions. 4) The group will finally consider a means for publishing the address to which ARF reports should be sent. Not all ARF participants wish to use abuse@(domain), which is the current standard (RFC2142), as the place to send automated ARF-formatted reports. The group will either conclude that the industry should continue to use this de facto standard (and thus no specification is appropriate), or will produce a Proposed Standard track document identifying the means by which that address should be advertised. The group may consider re-chartering to cover related work, including consideration of items removed since earlier versions of ARF as possible extensions, once these deliverables have been achieved. The working group is aware of related activities in other SDOs, namely the Open Mobile Alliance (http://www.openmobilealliance.org) "MWG-SpamRep" effort and a similar as-yet-unnamed effort inside the GSM Alliance (GSMA, http://www.gsm.org). The working group will coordinate efforts with those groups, and with MAAWG, as required. Goals and Milestones: Jun 2010 Submit ARF specification for IETF approval Mar 2011 Submit DKIM reporting specification for IETF approval Sep 2011 Submit ARF guidelines document for IETF approval Sep 2011 Submit ARF address advertising specification for IETF approval Internet-Drafts: Posted Revised I-D Title <Filename> ------ ------- -------------------------------------------- Apr 2010 Sep 2011 <draft-ietf-marf-dkim-reporting-03.txt> Extensions to DKIM for Failure Reporting Jan 2011 Jul 2011 <draft-ietf-marf-reporting-discovery-01.txt> A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports Apr 2011 Nov 2011 <draft-ietf-marf-redaction-03.txt> Redaction of Potentially Sensitive Data from Mail Abuse Reports Jun 2011 Dec 2011 <draft-ietf-marf-authfailure-report-07.txt> Authentication Failure Reporting using the Abuse Report Format Jun 2011 Oct 2011 <draft-ietf-marf-spf-reporting-02.txt> SPF Authentication Failure Reporting using the Abuse Report Format Sep 2011 Dec 2011 <draft-ietf-marf-as-02.txt> Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC5965 PS Aug 2010 An Extensible Format for Email Feedback Reports RFC6430 PS Nov 2011 Email Feedback Report Type Value: not-spam