IETF 79 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Messaging Abuse Reporting Format (marf) (WG)

No Minutes Submitted  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/marf

Chair(s): Barry Leiba Murray Kucherawy Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Pete Resnick

Meeting Slides

No Slides Present

Internet-Drafts:

• Authentication Failure Reporting using the Abuse Report Format (50283 bytes)
• A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports (31410 bytes)
• Redaction of Potentially Sensitive Data from Mail Abuse Reports (7884 bytes)

Request for Comments:

• An Extensible Format for Email Feedback Reports (RFC 5965) (47452 bytes)

Charter (as of 2011-04-05)

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