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.dussea...@messagingarchitects.com>
Alexey Melnikov <alexey.melni...@isode.com>
Responsible Area Director:
TBD
Mailing Lists:
General Discussion: abuse-feedback-rep...@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
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
