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.