2.1.10 Messaging Abuse Reporting Format (marf)
NOTE: This charter is a snapshot of the 77th IETF Meeting in Anaheim, California USA. It may now be out-of-date.
Last Modified: 2010-01-26
Barry Leiba <firstname.lastname@example.org>
Murray Kucherawy <email@example.com>
Applications Area Director(s):
Alexey Melnikov <firstname.lastname@example.org>
Peter Saint-Andre <email@example.com>
Applications Area Advisor:
Alexey Melnikov <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: https://www.ietf.org/mailman/listinfo/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
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
* 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
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)
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 |
|Sep 2010|| ||Submit ARF guidelines document for IETF approval |
|Mar 2011|| ||Submit DKIM reporting specification for IETF approval |
|Sep 2011|| ||Submit ARF address advertising specification for IETF approval |
No Request For Comments
MARF History and Overview
Mobile Spam Reporting Update