WG Review: Messaging Abuse Reporting Format (marf)

[IESG Secretary <iesg-secretary at ietf.org>]

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (iesg at ietf.org) by January 12,
2010.

Messaging Abuse Reporting Format (marf)
---------------------------------------
Last Modified: 12-21-2009

Current Status: Proposed Working Group 

Chair(s):
TBD

Applications Area Director(s):
Lisa Dusseault <lisa.dusseault at gmail.com>
Alexey Melnikov <alexey.melnikov at isode.com>

Applications Area Advisor:
Alexey Melnikov <alexey.melnikov at isode.com>

Mailing Lists:
General Discussion: abuse-feedback-report at mipassoc.org
To Subscribe: 
http://mipassoc.org/mailman/listinfo/abuse-feedback-report
Archive: http://mipassoc.org/mailman/listinfo/abuse-feedback-report

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.

ARF was developed by a messaging trade organization independent of 
the IETF, 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.  The basic 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 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.

The initial proposal is published as draft-shafranovich-feedback-report,
and this will provide the working group's starting point.

The working group should consider such factors as:
* implementer experience
* ability to achieve broad implementation and interoperability
* existing uses of ARF
* internationalization
* ability to address broader use cases than may have be contemplated 
by the original authors
* overlap with the INCH working group's work (e.g. RFC5070); it is 
unclear whether
such overlap is appropriate or should be avoided

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 (to be published later as
extensions).
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 specify the integration of ARF into DKIM DNS key
records, with draft-kucherawy-dkim-reporting 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.

3) 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, such as
further extensions, once these deliverables have been achieved.

The working group is aware of a related activity in another group:

- Open Mobile Alliance <http://www.openmobilealliance.org/> SpamRep

The goal is to coordinate efforts with this group as required.

Goals and Milestones:
Jan 2010 Issue first WG-based Internet-Draft defining ARF
Mar 2010 Achieve consensus on any WG-based changes to ARF
Apr 2010 Submit ARF ID to IESG for publication
Jun 2010 Issue first WG-based ID for DKIM reporting extensions
Sep 2011 Achieve consensus on DKIM reporting extensions draft
Nov 2011 Submit DKIM reporting ID to IESG for publication
Jan 2011 Issue first WG-based ID for advertising the ARF address
Mar 2011 Achieve consensus on ARF address advertising draft
Jul 2011 Submit ARF address advertising ID to IESG for publication