This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] Abuse Contact Information - Policy Proposal
- Previous message (by thread): [anti-abuse-wg] Abuse Contact Information - Policy Proposal
- Next message (by thread): [anti-abuse-wg] Working group focus
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kostas Zorbadelos
kzorba at otenet.gr
Tue Aug 17 16:09:42 CEST 2010
On Friday 23 July 2010 17:32:05 Tobias Knecht wrote: Tobias, > I would suggest the following. > > Anti-Abuse Working Group publishes a Best Practice Paper, which tells > every RIPE member that the "ONE" and "ONLY" way for publishing abuse > contact information is: > > Creating an IRT Object with an abuse-mailbox attribute. > > If there is such a paper, a lot of institutions will push this to their > members as a best practice paper and they will have to follow. > Best practice papers and documents should be I think one of the main purposes of an anti-abuse WG. I believe there is a lot of room for improvement in this area in this WG. > The next step is a policy proposal that does the following things: > > - Introduce the IRT Object into ASN Objects. > - Make the abuse-mailbox attribute mandatory for the IRT Objects. > - Make IRT Objects mandatory for directly by RIPE delegated Ranges. > > > IMHO this will solve all the problems. > > Query is possible with the -b and you get for all IPs in the RIPE region > at least one contact, that is in direct connection with RIPE. > > The Abuse Finder Tool (which is really cool) is able to give back an > contactfor all IP addresses all the time. > > The query restriction problem is solved and Bulk Data service is not > needed. Saves money, saves resources, save small institutions from not > reporting abusive behavior because of to big barriers. > > The ISP/LIR/... can decide if he wants to receive all messages for his > netranges and forward them to the right contact or if he offers his > customers the possibility to create an own IRT Object. If the Object is > wrong all messages go to the Top Contact again and he can check out why > his customer is not offering the right contact information. > > > I think this is all there, this is easy, it is not yet another big idea > to solve all the problems and being disappointed if it is not working. > Writing a Best Practice, making a abuse-mailbox attribute mandatory and > making an IRT Object Mandatory should not waste resources at RIPE. > > Please give me just feedback to the Best Practice part. I think this > should really happen and the next steps could be discussed in a policy > process. > I am not sure sure if there are any "better" ways to achieve the result of having an abuse contact for all network ranges allocated in the RIPE region. There is however such a need which is not served now and your proposal of introducing one clear way to publish the information plus making it mandatory as a next step seems quite reasonable to me. Therefore I support your proposals. A general problem I find in this community, is that I see a lot of talk about issues and very little action. Clearly, abuse issues are not simple and there are no silver bullets, but I believe consensus on relatively small sub-areas can be reached and actions should be tried. This is a personal opinion of course and I would be interested to hear others on this subject. Do you have any schedule for the policy formation and submission? > Thanks, > > Tobias Regards Kostas PS: as a small personal experience, trying the abuse-finder tool of RIPE for spam arriving on my inbox, in most cases returns no abuse contact result. I guess this is a problem of data missing rather an error in the tool's logic.
- Previous message (by thread): [anti-abuse-wg] Abuse Contact Information - Policy Proposal
- Next message (by thread): [anti-abuse-wg] Working group focus
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]