Working Group Name:
        Abuse Reporting Format (ARF)

   IETF Area:
        Applications Area

   Chair(s):
        TBD

   Applications Area Director(s):
        Lisa Dusseault <Lisa(_dot_)Dusseault(_at_)messagingarchitects(_dot_)com>
        Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>

   Responsible Area Director:
        TBD

   Mailing Lists:
        General Discussion: abuse-feedback-report(_at_)mipassoc(_dot_)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