[anti-abuse-wg] Discussion on 2011-06
Alessandro Vesely vesely at tana.it
Tue Jun 26 13:25:53 CEST 2012
I'd recommend that both the final text of 2011-06 and the Spam FAQs reference the new IETF proposed standard below. On Mon 25/Jun/2012 16:15:26 +0200 Denis Walker wrote: > > From the proceedings we understood the requirement is to have a single > location in the RIPE Database to store abuse contact details for any > Internet resource and for this to be applied hierarchically to minimise > management effort by the users and avoid unnecessary data duplication in > the database. > > The reasoning behind the selection of a ROLE object for the task is > partly based on our interaction with RIPE NCC member organisations. We > understand that abuse handling in the real world is a role within an > organisation. It therefore makes sense to map it directly to the ROLE > object within the database. > > [...] > > The Abuse Finder tool available through the ripe.net website is a first > iteration. We found it very difficult to define a proper scope for > heuristics to identify the correct abuse contacts for any given resource > with the current abuse contact documentation methods. A number of users > have reported issues with this tool providing the wrong contacts. We > held back from modifying the logic pending the outcome of the 2011-06 > proposal. If the community agrees on a new method of storing abuse > contacts the RIPE NCC will re-write the Abuse Finder tool to use the new > contact details. As we have recently re-implemented the RIPE Database > query service from scratch, we can also integrate the Abuse Finder > directly into the query logic. It will then also be available through a > web interface and by the RESTful API. I paste below the announce of RFC 6650. It envisions how to transmit solicited and unsolicited abuse reports. In particular, it mentions the use case of the Abuse Finder tool: Deciding where to send an unsolicited report will typically rely on heuristics. Abuse addresses in WHOIS [RFC3912] records of the IP address relaying the subject message and/or of the domain name found in the results of a PTR ("reverse lookup") query on that address are likely reasonable candidates, as is the abuse at domain role address (see [RFC2142]) of related domains. -------- Original Message -------- From: rfc-editor at rfc-editor.org Date: Mon, 25 Jun 2012 10:31:45 -0700 (PDT) To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: marf at ietf.org, rfc-editor at rfc-editor.org Subject: RFC 6650 on Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) A new Request for Comments is now available in online RFC libraries. RFC 6650 Title: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) Author: J. Falk, M. Kucherawy, Ed. Status: Standards Track Stream: IETF Date: June 2012 Mailbox: none, superuser at gmail.com Pages: 15 Characters: 35273 Updates: RFC5965 I-D Tag: draft-ietf-marf-as-16.txt URL: http://www.rfc-editor.org/rfc/rfc6650.txt RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK] This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.