 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
ARF, or Abuse Report Format, is an email message format similar
to DSNs developed by ESPs and ISPs outside of the IETF. It is intended to be
used by service providers to automate the reporting of various kinds of
messaging abuse. Interested parties are seeking to create an IETF working group
to subject the current proposal to the review and other rigorous processes the
IETF brings to bear to promote interoperability and adoption. The current draft charter is attached. If you would be
interested in participating in such a working group or have comments on the
charter, please respond here or (preferably) on the current ARF mailing list, available
via http://mipassoc.org/mailman/listinfo/abuse-feedback-report. -MSK |
Working Group Name:
Abuse Reporting Format (ARF)
IETF Area:
Applications Area
Chair(s):
TBD
Applications Area Director(s):
Lisa Dusseault <Lisa.Dusseault at messagingarchitects.com>
Alexey Melnikov <alexey.melnikov at isode.com>
Responsible Area Director:
TBD
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
* internationalization
* existing uses of ARF
* ability to achieve broad implementation and interoperability
* 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 following possilble reporting extensions have been proposed and will be considered
possible for addition to the existing specification:
a) drop boxes (detection of a mailbox used to receive things like stolen
credit cards)
b) botnet detection (i.e. reporting of traffic that appears to have come
from a bot, regardless of content)
c) SSH attacks
d) FTP attacks
e) Web server attacks
f) mail sent to a honeypot or spam trap
g) malware connections to sinkholes
h) DDoS reports
i) others that may be proposed within the allotted timeframe
2) The group will then produce a Proposed Standard track specification of ARF.
This will include not only the format of an ARF message adapted as needed
for the issues enumerated above, but must also include appropriate
documentation of security considerations and creation of IANA registries
for elements of ARF to support future extensions.
3) 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.
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, such as further extensions,
once these deliverables have been achieved.
Goals and Milestones:
Jan 10 Issue first WG-based Internet-Draft defining ARF
Mar 10 Achieve consensus on any WG-based changes to ARF
Apr 10 Submit ARF ID to IESG for publication
Jul 10 Issue first WG-based ID about DKIM reporting extensions
Sep 10 Achieve consensus on DKIM reporting extensions draft
Oct 10 Submit DKIM reporting ID to IESG for publication
Jan 11 Issue first WG-based ID for advertising the ARF address
Apr 11 Achieve consensus on ARF address advertising draft
May 11 Submit ARF address advertising ID to IESG for publication
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.