A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by January 12, 2010. Messaging Abuse Reporting Format (marf) --------------------------------------- Last Modified: 12-21-2009 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault <lisa.dusseault@gmail.com> Alexey Melnikov <alexey.melnikov@isode.com> Applications Area Advisor: Alexey Melnikov <alexey.melnikov@isode.com> Mailing Lists: General Discussion: abuse-feedback-report@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 * ability to achieve broad implementation and interoperability * existing uses of ARF * internationalization * 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 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 (to be published later as extensions). 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 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. 3) 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. The working group is aware of a related activity in another group: - Open Mobile Alliance <http://www.openmobilealliance.org/> SpamRep The goal is to coordinate efforts with this group as required. Goals and Milestones: Jan 2010 Issue first WG-based Internet-Draft defining ARF Mar 2010 Achieve consensus on any WG-based changes to ARF Apr 2010 Submit ARF ID to IESG for publication Jun 2010 Issue first WG-based ID for DKIM reporting extensions Sep 2011 Achieve consensus on DKIM reporting extensions draft Nov 2011 Submit DKIM reporting ID to IESG for publication Jan 2011 Issue first WG-based ID for advertising the ARF address Mar 2011 Achieve consensus on ARF address advertising draft Jul 2011 Submit ARF address advertising ID to IESG for publication _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
