* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Marf Status Pages

Messaging Abuse Reporting Format (Concluded WG)
App Area: Barry Leiba | 2010-Jan-26 — 2012-Jun-26 

2012-06-13 charter

Messaging Abuse Reporting Format (marf)


 Current Status: Active

     Murray Kucherawy <superuser@gmail.com>

 Applications Area Directors:
     Barry Leiba <barryleiba@computer.org>
     Pete Resnick <presnick@qualcomm.com>

 Applications Area Advisor:
     Barry Leiba <barryleiba@computer.org>

 Mailing Lists:
     General Discussion: marf@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/marf
     Archive:            http://www.ietf.org/mail-archive/web/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
    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)
    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

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/marf/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -