Subject: [AAA-DOCTORS] FW: WG Review: Messaging Abuse Reporting Format (marf)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Dec 2009 19:13:01 +0100

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Tuesday, December 22, 2009 8:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: WG Review: Messaging Abuse Reporting Format (marf) 

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 ([email-masked]) 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 <[email-masked]> Alexey Melnikov
<[email-masked]>

Applications Area Advisor:
Alexey Melnikov <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
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