From kzorba at otenet.gr Thu Dec 1 12:15:24 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Thu, 01 Dec 2011 13:15:24 +0200 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED66A6E.4000404@abusix.com> (Tobias Knecht's message of "Wed, 30 Nov 2011 18:39:58 +0100") References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> Message-ID: <87vcq05yr7.fsf@enigma.otenet.gr> Tobias Knecht writes: >From a first reading, it seems an elegant approach. Regards, Kostas > Thanks to Denis and RIPE NCC to come up with this view of the planned > implementation. > > Thanks, > > Tobias -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From tk at abusix.com Thu Dec 1 14:28:11 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 14:28:11 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <87vcq05yr7.fsf@enigma.otenet.gr> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> Message-ID: <4ED780EB.7040209@abusix.com> Hi, > From a first reading, it seems an elegant approach. The most elegant part is, that the next step will be easier. The data accuracy part needs to handle only one type of object and not different ones. That will make the data accuracy part imho easier. So this proposal is imho just a very first step down the road of more data accuracy and some other ideas. I hope with this explanation it gets clearer why we wanted to keep this proposal very lean. As Denis said, we had to step back. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From shane at time-travellers.org Thu Dec 1 15:06:16 2011 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 01 Dec 2011 15:06:16 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <4ED64AED.7030503@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> Message-ID: <1322748377.4245.17.camel@shane-desktop> Denis, On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote: > The RIPE NCC Database Group has now published an article on RIPE Labs > with a detailed explanation of how we propose to implement abuse > handling with an "abuse-c:" attribute referencing a ROLE object. > > https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database Thanks for putting this together. Basically, I think that the basic split between ABUSE and STANDARD ROLE objects does not make a lot of sense, and will likely lead to user confusion and frustration. Some of the ideas you've presented do make sense, but make sense for any contact data rather than restricting them via arbitrary business rules. One thing that I think would be a positive step forward for the RIPE Database is *not* to restrict references to ABUSE ROLE, but rather to restrict *all* references to person or role objects. I believe the database currently still allows me to reference any person/role object if I want to. This is a bug, not a feature, and I think adding "mnt-ref:" to person/role objects would be a better way forward than adding yet another special case. (This was introduced as a special case to the irt type, but then generalised in the organisation object.) I also suggest that normal access controls should apply to roles when used for abuse. Abuse desks don't like spam either. -- Shane From ripe-anti-spam-wg at powerweb.de Thu Dec 1 15:24:05 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 01 Dec 2011 15:24:05 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <1322748377.4245.17.camel@shane-desktop> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> Message-ID: <4ED78E05.9020305@powerweb.de> Shane Kerr wrote: > Denis, Dear Denis, a restriction or ACL for the abuse address is simple not what a lot of people intended. You forgot about bigger ISPs that likes to report abuse automatically in standarized formats (and what most abuse departments really LIKE to receive). An unrestricted abuse contact really helps here a lot. Sure, personal data should be protected, and thats why we really like the idea of seperating them from personal objects. But to be honest: no restriction helps that your email address ends up in a spammers list, they have more power you can dream of (I even heared that they pay people to enter captcha codes). Kind regards, Frank > > On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote: >> The RIPE NCC Database Group has now published an article on RIPE Labs >> with a detailed explanation of how we propose to implement abuse >> handling with an "abuse-c:" attribute referencing a ROLE object. >> >> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database > > Thanks for putting this together. > > Basically, I think that the basic split between ABUSE and STANDARD ROLE > objects does not make a lot of sense, and will likely lead to user > confusion and frustration. Some of the ideas you've presented do make > sense, but make sense for any contact data rather than restricting them > via arbitrary business rules. > > One thing that I think would be a positive step forward for the RIPE > Database is *not* to restrict references to ABUSE ROLE, but rather to > restrict *all* references to person or role objects. I believe the > database currently still allows me to reference any person/role object > if I want to. This is a bug, not a feature, and I think adding > "mnt-ref:" to person/role objects would be a better way forward than > adding yet another special case. (This was introduced as a special case > to the irt type, but then generalised in the organisation object.) > > I also suggest that normal access controls should apply to roles when > used for abuse. Abuse desks don't like spam either. > > -- > Shane > > > > -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From leo.vegoda at icann.org Thu Dec 1 15:28:56 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Dec 2011 06:28:56 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED780EB.7040209@abusix.com> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> Message-ID: <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> Hi Tobias, On Dec 1, 2011, at 5:28 am, Tobias Knecht wrote: [?] > The most elegant part is, that the next step will be easier. I think this is a problematic statement. It implies that this is the first step on a road towards a destination we have not yet been informed about. At the very least, it would have been courteous to publish a roadmap document prior to publishing the policy proposal, so that participants in the WG can review it in the context you intend it to have. I have no problem with improving the abuse reporting system but from my perspective, adding way to embed e-mail addresses in the database is not going to help significantly. The people who want abuse reports to so they can correct issues with their networks already have ways to publish that information and the people who don't want to deal with reports will either not use the proposed abuse-c objects or will populate them with broken data. New ways of putting information into the database will not fix abuse report handling. Unless you share your broader vision for how abuse report handling will improve, all this proposal does is add cost to RIPE NCC members and confusion to naive database users. Regards, Leo From shane at time-travellers.org Thu Dec 1 14:53:04 2011 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 01 Dec 2011 14:53:04 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) Message-ID: <1322747586.4245.7.camel@shane-desktop> All, On Wed, 2011-11-23 at 14:46 +0100, Emilio Madaio wrote: > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-06 As it is written I support this proposal. I am worried about the implication that an "abuse-c:" will be forced on all allocations. Without clear policies about what is required of such an abuse handling role, then organisations can simply set this to an unanswered mailbox, which doesn't actually improve the situation. But since that is not explicitly written in the proposal, I support the proposal. :) -- Shane From tk at abusix.com Thu Dec 1 15:40:14 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 15:40:14 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <4ED78E05.9020305@powerweb.de> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> <4ED78E05.9020305@powerweb.de> Message-ID: <4ED791CE.6040600@abusix.com> Hi, > a restriction or ACL for the abuse address is simple not > what a lot of people intended. We do not want to have a restriction on the abuse address it self. But we are able to control and split personal data from public data with these ACLs. And that is exactly what should happen. > You forgot about bigger ISPs that likes to report abuse > automatically in standarized formats (and what most abuse departments > really LIKE to receive). > An unrestricted abuse contact really helps here a lot. That is exactly what we want. That the abuse-mailbox attribute is unrestricted, but not the email address attribute. And that can be managed by ACLs. > Sure, personal data should be protected, and thats why we > really like the idea of seperating them from personal > objects. And that again is exactly what ACLs are for, to separate personal data from public data. I do not see any sense in splitting this up in different objects, since this makes things much more complicated for maintainers and especially for smaller maintainers. > But to be honest: no restriction helps that your email > address ends up in a spammers list, they have more > power you can dream of (I even heared that they pay > people to enter captcha codes). Paying people to entering captcha codes is not that new at all. ;-) The point is that we would not change anything. The abuse-mailbox attribute can be queried without restrictions already. So the whole proposal is about adding an abuse-c which makes imho sense and the implementation will take care of clearing thing up a little bit. Thanks, Tobias -- abusix > > > Kind regards, Frank > >> >> On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote: >>> The RIPE NCC Database Group has now published an article on RIPE Labs >>> with a detailed explanation of how we propose to implement abuse >>> handling with an "abuse-c:" attribute referencing a ROLE object. >>> >>> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database >> >> Thanks for putting this together. >> >> Basically, I think that the basic split between ABUSE and STANDARD ROLE >> objects does not make a lot of sense, and will likely lead to user >> confusion and frustration. Some of the ideas you've presented do make >> sense, but make sense for any contact data rather than restricting them >> via arbitrary business rules. >> >> One thing that I think would be a positive step forward for the RIPE >> Database is *not* to restrict references to ABUSE ROLE, but rather to >> restrict *all* references to person or role objects. I believe the >> database currently still allows me to reference any person/role object >> if I want to. This is a bug, not a feature, and I think adding >> "mnt-ref:" to person/role objects would be a better way forward than >> adding yet another special case. (This was introduced as a special case >> to the irt type, but then generalised in the organisation object.) >> >> I also suggest that normal access controls should apply to roles when >> used for abuse. Abuse desks don't like spam either. >> >> -- >> Shane >> >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-wg-antiabuse at kyubu.de Thu Dec 1 15:58:34 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 1 Dec 2011 15:58:34 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <4ED78E05.9020305@powerweb.de> References: <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> <4ED78E05.9020305@powerweb.de> Message-ID: <20111201145834.GA12617@core.kyubu.de> On Thu, Dec 01, 2011 at 03:24:05PM +0100, Frank Gadegast wrote: hi, > You forgot about bigger ISPs that likes to report abuse > automatically in standarized formats (and what most abuse departments > really LIKE to receive). True, but this is an orthogonal problem. > An unrestricted abuse contact really helps here a lot. Like, the abuse mailbox defined in RFC 2142? > But to be honest: no restriction helps that your email > address ends up in a spammers list, they have more Adding arbitrary restrictions doesn't prevent that either. > power you can dream of (I even heared that they pay > people to enter captcha codes). Yes. Cheers, Adrian From tk at abusix.com Thu Dec 1 16:05:54 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 16:05:54 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> Message-ID: <4ED797D2.9040302@abusix.com> Hi Leo, >> The most elegant part is, that the next step will be easier. > > I think this is a problematic statement. It implies that this is the > first step on a road towards a destination we have not yet been > informed about. At the very least, it would have been courteous to > publish a roadmap document prior to publishing the policy proposal, > so that participants in the WG can review it in the context you > intend it to have. I do not have a roadmap, but community has. And community asks over and over again what could be done about data accuracy. If community wants the Task Force to take care of this as well, the Task Force will be happy to do so. But if the community does not want the Task Force to take care of it, we will not do it. Maybe somebody else will come up with an idea, as I already did a few month ago with a proposal which I have withdrawn to get things sorted out in the Task Force. Sorry if this sounded like we are already having a masterplan in the pockets and we are not willed to share with you, that is not the case. But it is the case that we are listening to the discussions on the mailinglist and the meetings and wanted to make things more clean and clear for whomever will come up with and idea about improving data accuracy. > I have no problem with improving the abuse reporting system but from > my perspective, adding way to embed e-mail addresses in the database > is not going to help significantly. The people who want abuse reports > to so they can correct issues with their networks already have ways > to publish that information and the people who don't want to deal > with reports will either not use the proposed abuse-c objects or will > populate them with broken data. This proposal is not only about putting something into DB as it was done by APNIC and will hopefully be done by AfriNIC soon. In both these regions there was no possibility to add abuse contact information. In the RIPE region the point is that we have to many options and womtimes these options break things. And the main point of the Task Force was, to come up with a solution that fixes the variety we have at the moment and find "the place" to store abuse-contact information. And that is exactly what we did. > New ways of putting information into the database will not fix abuse > report handling. Unless you share your broader vision for how abuse > report handling will improve, all this proposal does is add cost to > RIPE NCC members and confusion to naive database users. And again this has never been the intention of this proposal. Such a proposal will never fix abuse report handling. Because handling incoming abuse reports is the business of every single ISP and not of RIPE NCC or RIPE as a community. The intention is to make it easier and clearer to publish and find the relevant things and maybe in a next step if community wants us to take care of focus on data accuracy. I do not see that this will make things more complicated to naive users. Imho the opposite is the case. The naive user should use the abuse finder tool which is already in place and would run much easier than today (150 db queries to get one single email address is just crazy). The naive user has to learn how to add abuse contact information in either way (old style or new style). And I as a naive user would rather know exactly what I have to do than thinking about what might be the right place to add information. I have no idea about the costs of this and I'm not sure if this is a relevant factor to decide if a proposal is good or not. Thanks for your feedback, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ripe-anti-spam-wg at powerweb.de Thu Dec 1 16:25:56 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 01 Dec 2011 16:25:56 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <20111201145834.GA12617@core.kyubu.de> References: <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> <4ED78E05.9020305@powerweb.de> <20111201145834.GA12617@core.kyubu.de> Message-ID: <4ED79C84.5080202@powerweb.de> Adrian wrote: > On Thu, Dec 01, 2011 at 03:24:05PM +0100, Frank Gadegast wrote: > > hi, Hi, >> You forgot about bigger ISPs that likes to report abuse >> automatically in standarized formats (and what most abuse departments >> really LIKE to receive). > > True, but this is an orthogonal problem. > >> An unrestricted abuse contact really helps here a lot. > > Like, the abuse mailbox defined in RFC 2142? Dont forget that the abuse-mailbox is mandatory, the new abuce-c isnt (and its also hierachically). When automatic parsing is needed, your need to query several objects including IRT, remarks, abuse-mailbox (what is usally not present for networks that ARE spamming a lot) and finally personal objects to find at least one email address you could send an abuse report too. And personal objects ARE restricted, what compicates things a lot. >> But to be honest: no restriction helps that your email >> address ends up in a spammers list, they have more > > Adding arbitrary restrictions doesn't prevent that either. > >> power you can dream of (I even heared that they pay >> people to enter captcha codes). > > Yes. Ok, so lets restrict access to personal objects even more and lets have a non mandatory and public abuse-c without any restriction. And I still like the idea of an "preferred contact method" field, so we can decide what format to use automatically. > Cheers, Adrian Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From leo.vegoda at icann.org Thu Dec 1 16:27:28 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Dec 2011 07:27:28 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4ED797D2.9040302@abusix.com> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> Hi Tobias, You wrote: > The intention is to make it easier and clearer to publish and find the > relevant things and maybe in a next step if community wants us to take > care of focus on data accuracy. Please don't add yet more data and then start thinking about the possibility of looking at data accuracy. Do it the other way around. There are already plenty of ways to publish abuse reporting data and adding another is not going to improve it. As sending reports to the wrong address is a wasted effort please don't make things worse by introducing requirements for new data to be published against the will of the people being forced to publish it. That will only make the overall dataset less useful. > I do not see that this will make things more complicated to naive users. > Imho the opposite is the case. Of course it will. The template will say that things are optional while the business rules say they are not. > The naive user should use the abuse > finder tool which is already in place and would run much easier than > today I disagree and I support the RIPE NCC's answer in its abuse FAQ: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam The overwhelming majority of abuse is perpetrated by skilled professionals who work hard to hide their tracks. Telling ordinary Internet users that they have a useful role in identifying abuse sources and reporting them to the hosting networks is a cruel lie. The scale of the problem requires large scale sampling and statistical analysis rather than individual reports. By all means work on the abuse issue but please approach it from the perspective of solving the abuse rather than adding a new, larger and more polluted set of addresses for reporting abuse. At a minimum, the proposal should include a policy for maintaining data quality and migrating from the existing dataset. Regards, Leo From babak at farrokhi.net Thu Dec 1 16:33:52 2011 From: babak at farrokhi.net (Babak Farrokhi) Date: Thu, 1 Dec 2011 19:03:52 +0330 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <87vcq05yr7.fsf@enigma.otenet.gr> References: <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> Message-ID: <20111201153350.GA263@swordfish.local> Hi, I support this proposal, hoping that it would eventually become mandatory and we have an auditing mechanism in place. Regards, -- Babak Farrokhi Network Expert / Unix SA / Security Analyst -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 243 bytes Desc: not available URL: From denis at ripe.net Thu Dec 1 16:45:04 2011 From: denis at ripe.net (Denis Walker) Date: Thu, 01 Dec 2011 16:45:04 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <1322748377.4245.17.camel@shane-desktop> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> Message-ID: <4ED7A100.2030803@ripe.net> Hi Shane You raised several points here, but I think they fall into two different issues. I will address one of them in this email. Then address the other ones in another email. First, the long standing question about referencing anyone's PERSON or ROLE object. I raised this question with the RIPE Data Protection Task Force and they considered the issue at great length some time ago. The Task Force concluded that it is actually better to NOT require authentication. As things stand now anyone can reference *your* PERSON object in their data. But you can do an inverse query (-i pn NIC-Hdl) and find any object in the RIPE Database where your PERSON object has been referenced. If you see a reference that you did not make, in data that you do not maintain, then you can question it with the maintainer of that data. If you get no success or response from them you can use the legal process (also set up by that Task Force) to deal with requests to remove (references to) personal data in the RIPE Database by a data subject. If the community asks for references to PERSON/ROLE objects to require mandatory authorisation, then no one can add a reference to YOUR object in their data. At first this looks like the ideal situation. However, the RIPE Data Protection Task Force looked at this from a different angle. There is no restriction on anyone creating a PERSON object containing any data. So anyone can create a new PERSON object with a copy of the data contained in your PERSON object. The guy who creates this copy also maintains it. So he can provide any mandatory authorisation for referencing this data copy. In the first case you can find any unauthorised references. In the second case you may never know someone has copied your personal data. So the Task Force considered it is safer to leave it as it is. Maybe a more important question to address is WHO made the changes? From the logs we can see which MNTNER and which password/PGP authorised a reference to your PERSON object or that created a copy of it. But a MNTNER is a box holding anonymous credentials of unknown people. What is missing is accountability. regards Denis On 1/12/11:49 3:06 PM, Shane Kerr wrote: > Denis, > > On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote: >> The RIPE NCC Database Group has now published an article on RIPE Labs >> with a detailed explanation of how we propose to implement abuse >> handling with an "abuse-c:" attribute referencing a ROLE object. >> >> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database > > Thanks for putting this together. > > Basically, I think that the basic split between ABUSE and STANDARD ROLE > objects does not make a lot of sense, and will likely lead to user > confusion and frustration. Some of the ideas you've presented do make > sense, but make sense for any contact data rather than restricting them > via arbitrary business rules. > > One thing that I think would be a positive step forward for the RIPE > Database is *not* to restrict references to ABUSE ROLE, but rather to > restrict *all* references to person or role objects. I believe the > database currently still allows me to reference any person/role object > if I want to. This is a bug, not a feature, and I think adding > "mnt-ref:" to person/role objects would be a better way forward than > adding yet another special case. (This was introduced as a special case > to the irt type, but then generalised in the organisation object.) > > I also suggest that normal access controls should apply to roles when > used for abuse. Abuse desks don't like spam either. > > -- > Shane > > > From ripe-wg-antiabuse at kyubu.de Thu Dec 1 16:45:24 2011 From: ripe-wg-antiabuse at kyubu.de (Adrian) Date: Thu, 1 Dec 2011 16:45:24 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> References: <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> Message-ID: <20111201154524.GA12250@core.kyubu.de> On Thu, Dec 01, 2011 at 07:27:28AM -0800, Leo Vegoda wrote: hi, > Please don't add yet more data and then start thinking about the possibility of looking at data accuracy. Do it the other way around. There are already plenty of ways to publish abuse reporting data and adding another is not going to improve it. > By all means work on the abuse issue but please approach it from the perspective of solving the abuse rather than adding a new, larger and more polluted set of addresses for reporting abuse. At a minimum, the proposal should include a policy for maintaining data quality and migrating from the existing dataset. 100% agree on that. Cheers, Adrian From kzorba at otenet.gr Thu Dec 1 16:51:35 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Thu, 01 Dec 2011 17:51:35 +0200 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> (Leo Vegoda's message of "Thu, 1 Dec 2011 07:27:28 -0800") References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> Message-ID: <87obvscmt4.fsf@otenet.gr> Leo Vegoda writes: > The overwhelming majority of abuse is perpetrated by skilled > professionals who work hard to hide their tracks. Telling ordinary > Internet users that they have a useful role in identifying abuse > sources and reporting them to the hosting networks is a cruel lie. The > scale of the problem requires large scale sampling and statistical > analysis rather than individual reports. This is true, but imagine the reporting function be handled automatically by machines and the counter-measures enforced near real-time by interested and cooperatings ISPs (again using automation). This might make the situation a bit better than today. Also parties that don't care or cooperate can be more easily identified. I think we should not leave the situation as-is. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba ---------------------------------------------------------------------------- () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\ From tk at abusix.com Thu Dec 1 17:19:32 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 17:19:32 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <4ED79C84.5080202@powerweb.de> References: <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> <4ED78E05.9020305@powerweb.de> <20111201145834.GA12617@core.kyubu.de> <4ED79C84.5080202@powerweb.de> Message-ID: <4ED7A914.30308@abusix.com> Hi, > Dont forget that the abuse-mailbox is mandatory, the new > abuce-c isnt (and its also hierachically). Don't forget hierarchy. If X.0.0.0/8 has an abuse-c all ips in this range are covered. If somebody wants to handle his own abuse he can add an abuse-c as well. If the maintainer of X.0.0.0/8 does not want to be responsible he has to ask his customers to publish an abuse-c. This should cover your thoughts. > When automatic parsing is needed, your need to query > several objects including IRT, remarks, abuse-mailbox (what > is usally not present for networks that ARE spamming > a lot) and finally personal objects to find at least > one email address you could send an abuse report too. This is exactly what should not happen in future, because the Abuse Finder API will give you the exact information you requested. If you use whois, you should use the -b option which returns only the abuse-mailbox attribute of the abuse-c. In the transitionphase this result will come up first and the other "old" results will come up if the first result is not possible to find. Later on there is only the mailbox attribute coming from an abuse-c. > And personal objects ARE restricted, what compicates > things a lot. As well this should not happen any more. Before sending the report to a personal address you should use hierarchy and go up one level and report things to this level. They can take care in whatever way they find it would be appropriate. > Ok, so lets restrict access to personal objects even more > and lets have a non mandatory and public abuse-c without any > restriction. I do not get the point why data other than abuse-mailbox would be needed in an unrestricted way. The abuse-c will be mandatory for at least the highest allocation, which gives you an abuse-mailbox attribute for every single ip address. So why would we need an unrestricted email-attribute, phone number, street and name of the object? > And I still like the idea of an "preferred contact method" > field, so we can decide what format to use automatically. There is a project working on this as a DNS based service in the IETF ARF Working Group. I'm absolutely against defining formats in the whois database. I could accept channels as soon as there are other channels finding their way in the everydays life of an abuse department. Putting formats into the whois things get polluted with stuff that has nothing to do in the whois. And second keeping this up2date is a pain. An abuse department does probably not want to get on NOCs people nerves and requests updates every once in a while. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From leo.vegoda at icann.org Thu Dec 1 17:42:52 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Dec 2011 08:42:52 -0800 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <87obvscmt4.fsf@otenet.gr> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <87obvscmt4.fsf@otenet.gr> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A4621@EXVPMBX100-1.exc.icann.org> Hi Kostas, You wrote: > This is true, but imagine the reporting function be handled > automatically by machines and the counter-measures enforced near > real-time by interested and cooperatings ISPs (again using > automation). This might make the situation a bit better than today. > Also parties that don't care or cooperate can be more easily > identified. It would only be able to identify someone who did not care after sending them a report. Why not allow the publication of abuse contact details to remain optional and know that someone does not care about abuse reports before wasting cycles in contacting them? There is nothing wrong with standardising the publication mechanism to aid automation but enforcing it on people who would prefer to be uncooperative just means a lot of wasted effort. > I think we should not leave the situation as-is. I don't believe anyone has suggested that things should not change and improve. I am suggesting that directionless, piecemeal changes are a bad idea and that any changes should be part of an overall plan that has received the consensus of the community before any single change is implemented. At a minimum, a plan needs to address the migration plan for automatically converting old abuse contact data to the new format and a systematic programme for maintaining data quality. If there are any implications for address allocation policy, such as reclaiming address space in certain circumstances, those should be spelled out explicitly and receive the consensus of the Address Policy WG. Regards, Leo From tk at abusix.com Thu Dec 1 18:08:03 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 18:08:03 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> Message-ID: <4ED7B473.1030309@abusix.com> Hi, > Please don't add yet more data and then start thinking about the > possibility of looking at data accuracy. Do it the other way around. So what is accurate at the moment? Remarks? IRT? abuse-mailbox? It does not make any sense looking at a "broken" structure and try to figure out what we can get out of it. Cleaning up and look at the cleaned structure makes much more sense. We do not add more data. That is absolutely not true. We are reorganizing the data in a way that there is no need for abuse contacts in remark fields and the abuse-mailbox attribute is handled in a different way. The only thing we add is a completely and easy to understandable point of reference. But the data behind the abuse-c can be the same data that is already there. It is just structured differently. > There are already plenty of ways to publish abuse reporting data and > adding another is not going to improve it. And that is the point we want to change. We do not want to have plenty half baked ways. We want to have one good one. > As sending reports to the wrong address is a wasted effort please > don't make things worse by introducing requirements for new data to > be published against the will of the people being forced to publish > it. That will only make the overall dataset less useful. We are not doing what you are saying. Today it would be good enough to add an abuse-mailbox attribute. Right? That is exactly what you are saying. That is what is already existing and we should stay with it. Right? So what would be needed to do after this proposal would be in place. If there is somebody with a role that does not contain an abuse-mailbox attribute he would have to add an abuse-mailbox attribute and say lets take this role as abuse-c. The only difference would be that the output would tell everybody that it is an abuse-c and not any object somewhere in the middle of "I do not know" that contains an abuse-mailbox attribute. So where is the part with forcing people to add more data? In the very end we are not even forcing members to do so. The only members that have to add an abuse-c are the direct allocated ranges. Not even the sub delegations. That means we are not forcing more people to add data, we are at the end force less people to add data than we do today. > Of course it will. The template will say that things are optional > while the business rules say they are not. If you want to use the object as an abuse-c it has to have an abuse-mailbox attribute, otherwise not. Is that really making things more complicated than they are today? >> The naive user should use the abuse finder tool which is already in >> place and would run much easier than today > > I disagree and I support the RIPE NCC's answer in its abuse FAQ: > > http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam Let me rephrase it: The naive user should use the abuse finder tool _if he wants_ and does not agree to RIPE NCC's answer in the abuse FAQ. Otherwise, if he agrees to RIPE NCC's answer in the abuse FAQ and does not want to do anything, which is absolutely fine, he can be ignored, because he will not be a user of this system and by that means this proposal does not touch him in any way. > By all means work on the abuse issue but please approach it from the > perspective of solving the abuse rather than adding a new, larger > and more polluted set of addresses for reporting abuse. At a > minimum, the proposal should include a policy for maintaining data > quality and migrating from the existing dataset. As already mentioned, the community seems to want a solution to the data accuracy problem. But I do not want to mix things up. We are talking here about an abuse-c, which will be than 1 of 4 -c's in the whois database (without counting the IRT). Data accuracy is a problem of all 4 (and the IRT object) of them. I will not try to fix a small part of the problem now and start over again to fix the general problem. The migration is mentioned but is not explained in detail because of the lack of an impact analysis. On of the main parts of the this proposal is cleaning up the existing situation. So I'm sure RIPE NCC will do everything that can be done to clean up as much as possible. 2 last questions: Do you agree that the data accuracy is a problem in the WHOIS DB? Do you think the Task Force should take care of this issue as soon as possible? Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From aftab.siddiqui at gmail.com Thu Dec 1 18:25:18 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 1 Dec 2011 22:25:18 +0500 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> Message-ID: Hi Tobias, So the RIPE NCC explanation and proposal states that the intention is to add abuse-c object (thats it). In this form do you think it will going to add any value to over all abuse reporting, IMHO the accuracy of data will always remain the biggest issue no matter how many objects you add, same is the case with IRT. But as a first step, I support it. Regards, Aftab A. Siddiqui > > On Wed, Nov 30, 2011 at 10:39 PM, Tobias Knecht wrote: >> >> Thanks to Denis and RIPE NCC to come up with this view of the planned >> implementation. >> >> Thanks, >> >> Tobias >> >> -- >> abusix >> >> >> Am 30.11.11 16:25, schrieb Denis Walker: >> > Dear Tobias and others >> > >> > The RIPE NCC Database Group has now published an article on RIPE Labs >> > with a detailed explanation of how we propose to implement abuse >> > handling with an "abuse-c:" attribute referencing a ROLE object. >> > >> > https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database >> > >> > Regards >> > Denis Walker >> > Business Analyst >> > RIPE NCC Database Group >> > >> > >> > On 29/11/11:49 4:49 PM, Tobias Knecht wrote: >> >> Hi Denis, >> >> >> >> thank you very much! Looking forward the document. >> >> >> >> Thanks, >> >> >> >> Tobias >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at abusix.com Thu Dec 1 18:29:00 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 01 Dec 2011 18:29:00 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> Message-ID: <4ED7B95C.3000609@abusix.com> Hi, > So the RIPE NCC explanation and proposal states that the intention is > to add abuse-c object (thats it). Right. > In this form do you think it will going to add any value to over all > abuse reporting, IMHO the accuracy of data will always remain the > biggest issue no matter how many objects you add, same is the case > with IRT. Right, but it is a first step that gives us a much easier start to look at data accuracy. Because we have to talk about one type of object and can handle them all the same way and not have to talk about different ones. > But as a first step, I support it. Thanks for that. For me this is also only a first step. I think the Task Force will be happy to extend the work on data accuracy and try to find ways to solve this as well. Of course only if community asks for it. Thanks a lot, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Thu Dec 1 22:47:55 2011 From: denis at ripe.net (denis at ripe.net) Date: Thu, 1 Dec 2011 22:47:55 +0100 (CET) Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <1322748377.4245.17.camel@shane-desktop> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> Message-ID: <51211.83.160.50.2.1322776075.squirrel@webmail.ripe.net> Hi Shane I answered your point about authorised references to PERSON objects separately as I don't think it is directly related to the technical proposal for this community policy proposal. The community may wish to discuss it further, but it may be better in another thread. Let me now answer the other half of this mail. If there were only to be two types of ROLE objects then it may not make sense to develop a generalised ROLE object. But as I illustrated in the article on RIPE Labs, the IRT object would fit very easily into this model as a third type of role. We have listened to comments about the IRT object over the years from people at RIPE Meetings and feedback from the trainers, who talk to many members every week. There is only a small group of people who really understand the complexity of the design of the IRT object. That is why for many years there were probably more POEM than IRT objects in the RIPE Database. It is a good example of using over complicated exceptions to solve a problem instead of generalising on an existing feature. However you look at it, the IRT object simply provides contact details for a specific role within an organisation. But it is not identical to the "admin-c:" role which is not identical to the "abuse-c:" role. When you look at the wider picture, an organisation has many role type functions. They may have slightly different characteristics in terms of where they are referenced from, the scope of the data they apply to (hierarchies for example), what type of contact details they present, authorisation issues and how much of the object should be displayed in different scenarios. But they are all roles. These differences can be handled by clearly defined business rules. They are by no means 'arbitrary'. This is why we made the technical proposal to make that generalisation now instead of building more one off exceptions. The article I wrote on RIPE Labs may look a little complicated because I included some of the design issues and background to explain how the RIPE Database developed into the animal it is today. If the community accepts this technical proposal as part of the policy under discussion, we will provide much simpler documentation explaining how to manage all contact data in the RIPE Database. This will include illustrated examples of the different role types, when and how to use them, what needs to be in them and the relationship between ROLE and PERSON objects. As a further step we can then improve Webupdates to recognise the different role types and present templates according to the type. This would clearly show what attributes are mandatory, optional, (not)allowed and required for a specific role type. Another step would then be for the Web Query form and the Query API to also present templates based on role type. In the long term we want to provide more modern tools for managing your data in the RIPE Database. As we further develop the Query and Update APIs we want to take away the need to remember what an RPSL object should look like in any given situation. It is a question of taking a series of small steps, each one to improve some aspect of using the RIPE Database. So rather than leading to 'confusion and frustration' we expect to provide clarity and calmness. It may look like a big change, but in reality it is a straight forward cleanup of the software to handle generalised roles and the final documentation will be much clearer than the article on RIPE Labs. When the community makes a decision on the policy, if we have the go ahead to implement this we will develop and deploy it quite quickly. As we now work with agile software development nothing is ever final. When a solution is deployed, if the community has any concerns or issues we can adapt it quite quickly. The aim is to work towards the perfect solution in a series of small, deployed steps. Then the community can review progress more often and see if it is the direction you want to be moving in. Change is much easier with small steps than a giant leap. I hope this answers some of the concerns over the technical details behind the communities policy proposal. Regards Denis Walker Business Analyst RIPE NCC Database Group > Denis, > > On Wed, 2011-11-30 at 16:25 +0100, Denis Walker wrote: >> The RIPE NCC Database Group has now published an article on RIPE Labs >> with a detailed explanation of how we propose to implement abuse >> handling with an "abuse-c:" attribute referencing a ROLE object. >> >> https://labs.ripe.net/ripe-database/abuse-handling-in-the-ripe-database > > Thanks for putting this together. > > Basically, I think that the basic split between ABUSE and STANDARD ROLE > objects does not make a lot of sense, and will likely lead to user > confusion and frustration. Some of the ideas you've presented do make > sense, but make sense for any contact data rather than restricting them > via arbitrary business rules. > > One thing that I think would be a positive step forward for the RIPE > Database is *not* to restrict references to ABUSE ROLE, but rather to > restrict *all* references to person or role objects. I believe the > database currently still allows me to reference any person/role object > if I want to. This is a bug, not a feature, and I think adding > "mnt-ref:" to person/role objects would be a better way forward than > adding yet another special case. (This was introduced as a special case > to the irt type, but then generalised in the organisation object.) > > I also suggest that normal access controls should apply to roles when > used for abuse. Abuse desks don't like spam either. > > -- > Shane > > > > From frank at powerweb.de Thu Dec 1 17:39:00 2011 From: frank at powerweb.de (Frank Gadegast) Date: Thu, 01 Dec 2011 17:39:00 +0100 Subject: [anti-abuse-wg] Proposal for technical details for abuse contact information in the RIPE Database In-Reply-To: <4ED7A914.30308@abusix.com> References: <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <1322748377.4245.17.camel@shane-desktop> <4ED78E05.9020305@powerweb.de> <20111201145834.GA12617@core.kyubu.de> <4ED79C84.5080202@powerweb.de> <4ED7A914.30308@abusix.com> Message-ID: <4ED7ADA4.2090607@powerweb.de> Tobias Knecht wrote: > Hi, Hi Tobias, >> Dont forget that the abuse-mailbox is mandatory, the new >> abuce-c isnt (and its also hierachically). > > Don't forget hierarchy. If X.0.0.0/8 has an abuse-c all ips in this > range are covered. If somebody wants to handle his own abuse he can add > an abuse-c as well. If the maintainer of X.0.0.0/8 does not want to be > responsible he has to ask his customers to publish an abuse-c. Thats a big point FOR the proposal. It will force the maintainer of the /8 to force his customers to migrate to the new abuce-c pretty quick. > attribute of the abuse-c. In the transitionphase this result will come > up first and the other "old" results will come up if the first result is > not possible to find. Later on there is only the mailbox attribute > coming from an abuse-c. Just what I meant, it will be perfect. One API or whois call or visit to the abuse finder tool to find the reponsible abuse email address, automatic or not, it simply will work for every complaint. >> And personal objects ARE restricted, what compicates >> things a lot. > > As well this should not happen any more. Before sending the report to a > personal address you should use hierarchy and go up one level and report > things to this level. They can take care in whatever way they find it > would be appropriate. We regulary climb that latter and often end up at hostmaster at ripe.net or bitbucket at ripe.net (or similar at the other RIRs) after making lots of unneeded queries :o( abuce-c will be much better than the confusion that we have right now (I even saw whois output with a different abuse-mailbox email that was mentioned in the remarks ;o) >> Ok, so lets restrict access to personal objects even more >> and lets have a non mandatory and public abuse-c without any >> restriction. > > I do not get the point why data other than abuse-mailbox would be needed > in an unrestricted way. That not what I meant, we will be happy, if the abuce-c is in place and its abuse-mailbox field queries will be unrestricted. > The abuse-c will be mandatory for at least the highest allocation, which > gives you an abuse-mailbox attribute for every single ip address. So why I know, thats why I support this proposal 100% +1 > would we need an unrestricted email-attribute, phone number, street and > name of the object? > >> And I still like the idea of an "preferred contact method" >> field, so we can decide what format to use automatically. > > There is a project working on this as a DNS based service in the IETF > ARF Working Group. > > I'm absolutely against defining formats in the whois database. I could > accept channels as soon as there are other channels finding their way in > the everydays life of an abuse department. Putting formats into the > whois things get polluted with stuff that has nothing to do in the > whois. And second keeping this up2date is a pain. An abuse department > does probably not want to get on NOCs people nerves and requests updates > every once in a while. Ok, can see that one too ... was just an idea that will help our daily work ... Kind regards, Frank > > > Thanks, > > Tobias > -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From vesely at tana.it Sun Dec 4 15:44:34 2011 From: vesely at tana.it (Alessandro Vesely) Date: Sun, 04 Dec 2011 15:44:34 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: <4ECD22AE.5090905@heanet.ie> References: <4ECD22AE.5090905@heanet.ie> Message-ID: <4EDB8752.1060003@tana.it> On 23/Nov/11 17:43, Brian Nisbet wrote: > Ren?, > > The RIPE Policy Development Process uses English as its primary > language. As such policy proposals and discussion can only be > guaranteed to take place in that language. I'd suggest to have their abuse-c's abuse-mailbox hold an address like, say, mauvais at wanadoo.fr. That will discourage manual submissions by non-french speakers, albeit it won't do anything for automated submissions. > "Briaut perso" wrote the following on 23/11/2011 15:19: >> Hello ! >> >> I speak french only >> >> Ren? BRIAUT >> >> 115 Cours Fauriel >> >> 42100 SAINT ETIENNE >> >> ( 04.77.46.96.07 et 06.07.61.29.49 >> >> rbriaut at wanadoo.fr >> -----Message d'origine----- >> De : anti-abuse-wg-bounces at ripe.net >> [mailto:anti-abuse-wg-bounces at ripe.net] >> De la part de Emilio Madaio >> Envoy? : mercredi 23 novembre 2011 14:47 >> ? : policy-announce at ripe.net >> Cc : anti-abuse-wg at ripe.net >> Objet : [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse >> ContactManagement >> in the RIPE NCC Database) >> >> >> Dear Colleagues, >> >> A new RIPE Policy Proposal has been made and is now available for >> discussion. >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-06 >> >> We encourage you to review this proposal and send your comments to >> before 21 December 2011. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> >> >> > From vesely at tana.it Sun Dec 4 16:56:13 2011 From: vesely at tana.it (Alessandro Vesely) Date: Sun, 04 Dec 2011 16:56:13 +0100 Subject: [anti-abuse-wg] OT: 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <1322747586.4245.7.camel@shane-desktop> References: <1322747586.4245.7.camel@shane-desktop> Message-ID: <4EDB981D.4050807@tana.it> On 01/Dec/11 14:53, Shane Kerr wrote: > On Wed, 2011-11-23 at 14:46 +0100, Emilio Madaio wrote: >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2011-06 > > As it is written I support this proposal. Thank you for the support. > I am worried about the implication that an "abuse-c:" will be forced on > all allocations. Without clear policies about what is required of such > an abuse handling role, then organisations can simply set this to an > unanswered mailbox, which doesn't actually improve the situation. I'm worried about that too. If LIRs don't cooperate, the situation won't improve. Moreover, skeptics will tend to think that the sole purpose of having an abuse-mailbox, possibly geared to /dev/null, is to free admin/tech-c mailboxes from unwanted spam complaints. If LIRs cooperate, there are some questions that I'd put, such as * What software is available to allow LIRs to operate reasonably without requiring them to consecrate a full blown team to sorting out spam complaints originating from their customers' operations? (I'd guess that forwarding complaints to the relevant mailbox provider, while monitoring their trend, could be the basis of a reasonable behavior.) * What is the correct (global) site for related discussion? > But since that is not explicitly written in the proposal, I support the > proposal. :) Thanks also for doing that distinction. From ops.lists at gmail.com Mon Dec 5 03:53:43 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 5 Dec 2011 08:23:43 +0530 Subject: [anti-abuse-wg] OT: 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4EDB981D.4050807@tana.it> References: <1322747586.4245.7.camel@shane-desktop> <4EDB981D.4050807@tana.it> Message-ID: Some way to weed out all the fake LIRs that started this discussion in the first place would obviate this entire discussion On Sun, Dec 4, 2011 at 9:26 PM, Alessandro Vesely wrote: > > > If LIRs cooperate, there are some questions that I'd put, such as > > * What software is available to allow LIRs to operate reasonably > ?without requiring them to consecrate a full blown team to sorting > ?out spam complaints originating from their customers' operations? -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Wed Dec 7 11:36:34 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 7 Dec 2011 16:06:34 +0530 Subject: [anti-abuse-wg] ripe whois - regexp search / full text search on the command line Message-ID: I can't do this through the command line though I can do it in arin, say - use a regexp and find a full list of netblocks allocated to a spammer For example there's a brazilian spammer with multiple sbl listings, who has lots of /27s and /28s swipped to him all over multiple /16s on an European ISP Finding him by command line whois doesn't work at all, but I can get all his netblocks by searching in https://apps.db.ripe.net/search/full-text.html -- Suresh Ramasubramanian (ops.lists at gmail.com) From chrish at consol.net Wed Dec 7 19:00:22 2011 From: chrish at consol.net (chrish at consol.net) Date: Wed, 07 Dec 2011 19:00:22 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <201111231347.pANDlMYe004526@gw1.consol.de> References: <201111231347.pANDlMYe004526@gw1.consol.de> Message-ID: <4EDFA9B6.9040503@consol.net> Hi! [...] > but business rules will require it to be [...] I didn't find any "business rules" document at RIPE. >From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target. Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. One hell of a vision you got there, I'd say... ;) [though not explicitly stated, the following seems to be meant as justification of the proposal] > Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred. When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. Later in the thread I had to find out that it isn't. In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all. In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!? But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation... Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue. Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say) Regards, Chris From ripe-anti-spam-wg at powerweb.de Wed Dec 7 19:43:56 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 07 Dec 2011 19:43:56 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4EDFA9B6.9040503@consol.net> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> Message-ID: <4EDFB3EC.8040502@powerweb.de> chrish at consol.net wrote: > Hi! Hi, > > [...] >> but business rules will require it to be > [...] > > I didn't find any "business rules" document at RIPE. > >> From the thread I understand that the intention is to make the abuse-c an actually mandatory attribute, at the same time kind of removing the e-mail attribute and making the abuse-mailbox by definition a bulk target. > > Now I have to think about a crowd of real persons with a ripe handle, referenced as admin-c for their objects. They would have to add an abuse-c (or otherwise somebody will try to take their resources away from them!?), i.e. they will usually just add their e-mail there once more (if they don't have an abuse-mailbox attribute yet - probably because they don't need it because the value in the e-mail is perfectly what they want to communicate for this purpose as well) - while this email was made a bulk target by definition (in which case they probably even preferred to remove the abuse-mailbox if they had one in favour of their e-mail attribute - which would just be made impossible by the proposal), and at the same time their e-mail would be made unusable. > One hell of a vision you got there, I'd say... ;) Usally people have different mailboxes or mail addresses for different purposes. The proposal even helps here a lot to seperate personal email addresses from abuse email addresses, simply because the abuse-c has to be defined now. So, everybody thats has to complain simply knows now who to contact and will nevermore bother somebodys personal email address like the email named in the admin-c (see an example below). > [though not explicitly stated, the following seems to be meant as justification of the proposal] >> Currently within the RIPE NCC service region, it is not clear whether to use the "abuse-mailbox:" attribute, the "remark:" attribute or an irt object. And since the "abuse-mailbox:" attribute can be added to various role objects, it is not clear in which of these role objects it should be preferred. > > When I read that I assumed it had to mean that it is proposed to drop "abuse-mailbox", "remark" and the irt object. > Later in the thread I had to find out that it isn't. > In case the mentioned attributes/objects are really to be dropped in favour of the single new attribute, I might see a benefit in simplifying things. I don't say yet that this justifies a policy change, but at least there would be some sort of point in it... > The implementation document kind of summarizes this aspect quite drastically, too. It describes the goal of 'going back to basics', 'avoiding complexity' in quite some length, and concludes in adding several attributes, objects, and quite some mainly undefined policy stuff while removing nothing at all. The other places will fanish just in the moment the abuse-c is introduced, simply because because every resource owner has to re-think, how a complaint should reach him. If the resource owner does not like any confusion, he will have to remove abuse contacts from the remark section. > In short I can't see any benefit from this proposal. It doesn't simplify things, it makes things (including finding abuse contact information) more complicated and for a huge part of the community it introduces severe problems. We're better off as it is now. The "Arguments supporting the proposal" are in my eyes simply unsustainable. > Another cue regarding the possible aim I found was: "The outcome is, to have an abuse-c in place. That is all." Well, that's not true as discussed above, there are major problematic implications, and on the other side, simply to have another attribute doesn't seem like a valid justification to me. I mean, it's not "to have an abuse-mailbox", which would bear some sort of sense in itself in my eyes - while of course this has been done already. > Actually I do not even see the motivation for an 'abuse industry' to lobby this at all!? > > But I don't think that this kind of policy should be following particulate interest but should be universal anyway. Like this: > - a resource has an administrative contact (complaints - whether abuse or not - are administrative issues) > - a contact can have an explicit address for abuse reports. In case the contact chose to not have/want/need a special abuse address, there are still the canonical addresses for this contact. > This is what we have, and while there might be problems somewhere that should or could be addressed, I don't see the problem the 2011-6 proposal fixes (or actually even formally addresses)!? > If you want to force every resource holder to have and publish an email that is explicitly meant to be bulk-spammed, you should propose exactly this (i.e. making an abuse-mailbox mandatory for the admin-c and announcing it as proper use to bulk spam these addresses). As a victim of this I'd ofc still be very much against this. And once again, I'm really wondering what the businesscase might be to motivate such a situation... > > Making the abuse-c attribute actually mandatory as described, imho is a very very bad idea for the reason given above. Effectively removing the e-mail attribute imho is too, though probably sligthly less important than the previous issue. > > Well, at least time to update the "Arguments opposing" paragraph, I'd say... (dropping the proposal wouldn't be wrong either, I'd say) I understand that you will like to drop this proposal. Its the usual reaction from somebody who likes to hide his personal responsibility: A whois on consol.net reveales: domain: consol.net owner: n/a organization: ConSol* GmbH contact-hdl: CNET-520629 person: n/a organization: ConSol* GmbH So thats a german company without a CEO/Geschaeftsfuehrer ? Well you can do something like this with a .net domain, but at least the DENIC whois reveals an admin-c here: Name: Michael Elbel Organisation: ConSol* GmbH Adresse: Franziskanerstr. 38 PLZ: 81669 Ort: M?nchen Land: DE and your netblock wich has your mailserver shows inetnum: 194.246.122.0 - 194.246.123.255 netname: CONSOL-NET descr: ConSol Consulting & Solutions Software GmbH country: DE admin-c: ME7 tech-c: NOG1-RIPE status: ASSIGNED PI org: ORG-CCSS3-RIPE mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-by: CONSOL-MNT mnt-routes: CONSOL-MNT mnt-domains: CONSOL-MNT source: RIPE # Filtered organisation: ORG-CCSS3-RIPE org-name: ConSol Consulting & Solutions Software GmbH org-type: LIR address: ConSol Consulting & Solutions Software GmbH Franziskanerstr. 38 81669 Muenchen Germany phone: +498945841100 fax-no: +498945841111 e-mail: ripeadm at consol.de mnt-ref: CONSOL-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT admin-c: ME7 source: RIPE # Filtered role: Network Operating Group address: ConSol* GmbH address: Franziskanerstrasse 38 address: Muenchen, BY D-81669 phone: +49 89 45841-100 fax-no: +49 89 45841-111 e-mail: nog at consol.de admin-c: ME7 tech-c: ME7 nic-hdl: NOG1-RIPE mnt-by: DENIC-P source: RIPE # Filtered person: Michael Elbel address: ConSol* GmbH address: Franziskanerstrasse 38 address: D-81669 Muenchen address: Germany phone: +49 89 45841 256 fax-no: +49 89 45841 111 e-mail: me at freebsd.org nic-hdl: ME7 mnt-by: DENIC-P source: RIPE # Filtered hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ... And a personal email address, thats obviously not related to your company (mabye simple because a lot of spam and wrong complains is arriving there). So ... you can be lucky, you will not have to remove or change any object or contact, because you already have none. You will simply insert the abuse-c and than you can even set the official email address of Michael Elbel in the ME7 contact. And looking on www.consol.de you should be able to insert abuse at consol.net with a working ticket system behind ... You should really support the proposal, it will help you a lot. Kind regards, Frank > Regards, > > Chris > > BTW: also very cool is to visit www.consol.net (the next step, if somebody likes to report abuse) ... PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From chrish at consol.net Wed Dec 7 22:03:41 2011 From: chrish at consol.net (chrish at consol.net) Date: Wed, 07 Dec 2011 22:03:41 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4EDFB3EC.8040502@powerweb.de> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> <4EDFB3EC.8040502@powerweb.de> Message-ID: <4EDFD4AD.8050007@consol.net> Hi! On 12/07/2011 07:43 PM, Frank Gadegast wrote: > Usally people have different mailboxes or mail addresses for different > purposes. I.e. your idea is to require every admin-c to have different mailboxes. > The proposal even helps here a lot to seperate personal email addresses > from abuse email addresses, simply because the abuse-c has to be > defined now. There already is an admin-c. To force admin-cs to use different/multiple mailboxes, another attribute is necessary. That would be abuse-mailbox. This already exists, so everybody who wants to use it, can use it. It's just that currently nobody is forced to use it, if you don't want/need to use it, you don't have to. > So, everybody thats has to complain simply knows now who to contact ...that would be the admin-c. And following the proposal: in some cases following weird, diffuse, and sparsely defined policies maybe also an abuse-c. > and will nevermore bother somebodys personal email address like > the email named in the admin-c (see an example below). The email address listed in my admin-c object is not my private personal email, but the email address chosen for the admin-c - for being contacted in case of administrative issues. This is true for both role and person objects. If you don't want to be emailed personally, use a role object. If you don't want people to use a specific email - don't list it in your contact objects! Even if you chose for whatever strange reason to enter into a role or person object an email you don't want people querying the db to know/use, what you would need following that rationale is an abuse-mailbox attribute for that admin-c object. Not another -c object. (Actually I guess a new 'secret-email' attribute would fit best for your needs) > The other places will fanish just in the moment the abuse-c is > introduced, simply because because every resource owner has > to re-think, how a complaint should reach him. Sorry, no. According to the proposal, there will be additional objects and attributes. And people are forced to 'accept' being bulk-spammed. That's it. The rest is prophecy (and experience suggests the opposite - see the remarks on contradicting abuse-mailbox and other attributes in this very same thread). Btw, a short hint for resource owners on how to be contacted: - list your postal address in the way you'd wish to be contacted by postal service - list the phone number you'd wish to be contacted by by phone - list the fax number you'd wish to be contacted by by fax, or leave it out if you don't want to be contacted by fax - list the email address you'd wish to be contacted by, or leave it out if you don't want to be contacted by email - list the abuse-mailbox email address you'd wish to be contacted by in case of abuse complaints in case you wish to have a special mailbox for those, or leave it out if you don't > If the resource owner does not like any confusion, he will > have to remove abuse contacts from the remark section. Non-sequitur. I'd say: to minimize confusion, let's not add the proposed stuff. :) > Its the usual reaction from somebody who likes to hide his personal > responsibility: Well I think my explanation was quite comprehensive. On the other hand I think trying to go ad personam in a technical discussion should not be accepted. ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. I'm working for ConSol*, and domain registration is not in my areas of responsibility or influence. Having said that - while wondering why, I mean it's not (well - it shouldn't be) your business - you might want to return to on-topic, non-ad-personam discussion. And what responsibility are you referring to? I mean, this sounds like I'm supposed to "take the responsibility to disagree with you"? Spooky... > hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ... Thanks for providing the opportunity to point that out. There is no abuse-c (well...), there is no abuse-mailbox, but there's no no nothing: there is an admin-c, and that admin-c has (among other contact data) an e-mail. > And a personal email address, thats obviously not related to > your company (mabye simple because a lot of spam and wrong > complains is arriving there). Again, all this is pulled out of thin air (much like the 'substance' of the proposal, if you ask me). It's a person object, in that regard 'personal email address' is probably formally right. And also: not surprising. :) I don't see how that is 'obviously not related to the company'. And regarding the rest of your statement, I don't quite understand what you're trying to say there. > You should really support the proposal, it will help you a lot. Well actually, as I already explained, at least for the broad majority this proposal doesn't help, but complicates things and causes partly severe problems. So I don't really see a future for it... And this also doesn't really seem to change, it actually gets worse: in your reply I didn't find a single argument explaining or clarifying on the issues I mentioned, or bringing forward any new or neglected aspects. And experience shows that being attacked personally when trying to discuss a technical issue is a red flag regarding the subject and/or the motivation of the attacking party... I still failed to see who might be 'helped' by the proposed stuff, and how... I mean, I'm convinced the authors at least had to think this will somehow help them, but I don't see how... Regards, Chris From ripe-anti-spam-wg at powerweb.de Thu Dec 8 02:01:33 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 08 Dec 2011 02:01:33 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4EDFD4AD.8050007@consol.net> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> <4EDFB3EC.8040502@powerweb.de> <4EDFD4AD.8050007@consol.net> Message-ID: <4EE00C6D.1000901@powerweb.de> chrish at consol.net wrote: > Hi! Hi, > There already is an admin-c. Well, administration is something completely different than abuse responsibilty, right ? One is called "administration", the other is "abuse" ... ... "administration", "abuse", you see, two different words. Two different responsibilities. I somehow got puzzled, because you really think, that somebody should try to reach your admin-c, when reporting spam or other abuse. The admin-c is the administration, the CEO, the owner, not the administrator of some resources. Could that all explain your big confusion ? Yes, and thats why your arguments are all wrong and useless and are only confusing. > And what responsibility are you referring to? Surely your responsibility for the use of the resources giving your company by your RIR/LIR. Who should I contact, if one of your servers on your networks got hacked and misused for attacking our networks ? Please publish some email addresses at the right places, so I could contact you quick as possible, what also helps you to identify problems. I will defny not contact your admin-c, hes probably on a long business trip aqcuiring a third company, maybe "Consol Ltd.", making holidays or is ill, I need an email address of your anti abuse staff beeing read 24x7 and no postal address or phone only working daytime on business days. > ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. Hm, obviously wrong, these to companies are directly nested: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; Ques: 1, Ans: 1, Auth: 3, Addit: 2 ;; QUESTIONS: ;; consol.net, type = MX, class = IN ;; ANSWERS: consol.net. 63955 MX 10 mailrelay.consol.de. ;; AUTHORITY RECORDS: consol.net. 63955 NS dns3.consol.net. consol.net. 63955 NS dns2.consol.net. consol.net. 63955 NS dns1.consol.net. And you have an address under @consol.net But you are using the internal resources, mailservers and gateways of consol.de So: consol.de and consol.net are the same and you are an internal. Received: from sol1.bb.consol.de (sol1.bb.consol.de [10.250.0.71]) by gw1.consol.de (8.14.4/8.14.4) with ESMTP id pB7L3g6f040098 BTW: you have no signature attached, thats why it has to go over the list only. Im not sending somebody email, when hes not open enough to tell who he is. > To force admin-cs to use different/multiple mailboxes, another attribute is necessary. > That would be abuse-mailbox. > This already exists, so everybody who wants to use it, can use it. It's just that currently nobody is forced to use it, if you don't want/need to use it, you don't have to. > >> So, everybody thats has to complain simply knows now who to contact > > ...that would be the admin-c. > And following the proposal: in some cases following weird, diffuse, and sparsely defined policies maybe also an abuse-c. > >> and will nevermore bother somebodys personal email address like >> the email named in the admin-c (see an example below). > > The email address listed in my admin-c object is not my private personal email, but the email address chosen for the admin-c - for being contacted in case of administrative issues. > This is true for both role and person objects. > If you don't want to be emailed personally, use a role object. If you don't want people to use a specific email - don't list it in your contact objects! > > Even if you chose for whatever strange reason to enter into a role or person object an email you don't want people querying the db to know/use, what you would need following that rationale is an abuse-mailbox attribute for that admin-c object. Not another -c object. > (Actually I guess a new 'secret-email' attribute would fit best for your needs) > >> The other places will fanish just in the moment the abuse-c is >> introduced, simply because because every resource owner has >> to re-think, how a complaint should reach him. > > Sorry, no. According to the proposal, there will be additional objects and attributes. And people are forced to 'accept' being bulk-spammed. That's it. > > The rest is prophecy (and experience suggests the opposite - see the remarks on contradicting abuse-mailbox and other attributes in this very same thread). > > Btw, a short hint for resource owners on how to be contacted: > - list your postal address in the way you'd wish to be contacted by postal service > - list the phone number you'd wish to be contacted by by phone > - list the fax number you'd wish to be contacted by by fax, or leave it out if you don't want to be contacted by fax > - list the email address you'd wish to be contacted by, or leave it out if you don't want to be contacted by email > - list the abuse-mailbox email address you'd wish to be contacted by in case of abuse complaints in case you wish to have a special mailbox for those, or leave it out if you don't > >> If the resource owner does not like any confusion, he will >> have to remove abuse contacts from the remark section. > > Non-sequitur. > I'd say: to minimize confusion, let's not add the proposed stuff. :) > >> Its the usual reaction from somebody who likes to hide his personal >> responsibility: > > Well I think my explanation was quite comprehensive. > > On the other hand I think trying to go ad personam in a technical discussion should not be accepted. > > ConSol* GmbH is - as you probably already know from your extensive research, which btw also shows that your 'accusation' of 'hiding' is obviously unfounded - not my company. I'm working for ConSol*, and domain registration is not in my areas of responsibility or influence. Having said that - while wondering why, I mean it's not (well - it shouldn't be) your business - you might want to return to on-topic, non-ad-personam discussion. > And what responsibility are you referring to? I mean, this sounds like I'm supposed to "take the responsibility to disagree with you"? Spooky... > >> hm, no abuse contact in the remarks, no abuse-mailbox, no nothing ... > > Thanks for providing the opportunity to point that out. > There is no abuse-c (well...), there is no abuse-mailbox, but there's no no nothing: there is an admin-c, and that admin-c has (among other contact data) an e-mail. > >> And a personal email address, thats obviously not related to >> your company (mabye simple because a lot of spam and wrong >> complains is arriving there). > > Again, all this is pulled out of thin air (much like the 'substance' of the proposal, if you ask me). > > It's a person object, in that regard 'personal email address' is probably formally right. And also: not surprising. :) > I don't see how that is 'obviously not related to the company'. And regarding the rest of your statement, I don't quite understand what you're trying to say there. > >> You should really support the proposal, it will help you a lot. > > Well actually, as I already explained, at least for the broad majority this proposal doesn't help, but complicates things and causes partly severe problems. So I don't really see a future for it... > And this also doesn't really seem to change, it actually gets worse: in your reply I didn't find a single argument explaining or clarifying on the issues I mentioned, or bringing forward any new or neglected aspects. And experience shows that being attacked personally when trying to discuss a technical issue is a red flag regarding the subject and/or the motivation of the attacking party... > > I still failed to see who might be 'helped' by the proposed stuff, and how... I mean, I'm convinced the authors at least had to think this will somehow help them, but I don't see how... > > Regards, > > Chris > > Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From vesely at tana.it Thu Dec 8 10:03:50 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 08 Dec 2011 10:03:50 +0100 Subject: [anti-abuse-wg] Call for participation in IETF WG on abuse reporting Message-ID: <4EE07D76.9040605@tana.it> The MARF WG http://datatracker.ietf.org/wg/marf/ issued RFC 5965 for the abuse reporting format (ARF). RFC 6449, Complaint Feedback Loop Operational Recommendations, is an informational document that originated in MAAWG. The activity of MARF WG recently decreased and it apparently needs to get invigorated with the participation of newcomers who are willing to devolve their interest and experience in abuse reporting to the community. If that's your case, please review one or more drafts in that page and post comments on the MARF mailing list. In particular, draft-ietf-marf-reporting-discovery is an alternative to whois lookups, while draft-ietf-marf-as is an application statement for RFC 6449, which may modify or complement any operational recommendation contained therein, e.g. by merging in draft-vesely-marf-abuse-reporting. The participation called for here is an occasion to standardize how abuse reporting is to be done, thereby complementing the work carried out by this WG and ACM-TF. TIA From tk at abusix.com Thu Dec 8 11:04:59 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 08 Dec 2011 11:04:59 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse Contact Management in the RIPE NCC Database) In-Reply-To: <4EDFA9B6.9040503@consol.net> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> Message-ID: <4EE08BCB.1060906@abusix.com> Hi, >> From the thread I understand that the intention is to make the >> abuse-c an actually mandatory attribute, at the same time kind of >> removing the e-mail attribute and making the abuse-mailbox by >> definition a bulk target. > > Now I have to think about a crowd of real persons with a ripe > handle, referenced as admin-c for their objects. They would have to > add an abuse-c (or otherwise somebody will try to take their > resources away from them!?), i.e. they will usually just add their > e-mail there once more (if they don't have an abuse-mailbox attribute > yet - probably because they don't need it because the value in the > e-mail is perfectly what they want to communicate for this purpose as > well) - while this email was made a bulk target by definition (in > which case they probably even preferred to remove the abuse-mailbox > if they had one in favour of their e-mail attribute - which would > just be made impossible by the proposal), and at the same time their > e-mail would be made unusable. One hell of a vision you got there, > I'd say... ;) > > [though not explicitly stated, the following seems to be meant as > justification of the proposal] >> Currently within the RIPE NCC service region, it is not clear >> whether to use the "abuse-mailbox:" attribute, the "remark:" >> attribute or an irt object. And since the "abuse-mailbox:" >> attribute can be added to various role objects, it is not clear in >> which of these role objects it should be preferred. If the current system was so obvious to everyone: - why do so many data maintainers put abuse contact details in "remarks:"? - why do so many users send complaints to email addresses found in "notify:" and "changed:" attributes? - why does anyone use "abuse-mailbox:", which has always been optional, when "admin-c:" has always been available? - The "admin-c:" has never been defined as an abuse contact. It is not reasonable to assume that everyone who linked an email address to that attribute wants to receive abuse complaints on that address, even if some do. > When I read that I assumed it had to mean that it is proposed to > drop "abuse-mailbox", "remark" and the irt object. Later in the > thread I had to find out that it isn't. In case the mentioned > attributes/objects are really to be dropped in favour of the single > new attribute, I might see a benefit in simplifying things. I don't > say yet that this justifies a policy change, but at least there > would be some sort of point in it... The implementation document kind > of summarizes this aspect quite drastically, too. It describes the > goal of 'going back to basics', 'avoiding complexity' in quite some > length, and concludes in adding several attributes, objects, and > quite some mainly undefined policy stuff while removing nothing at > all. Just to clarify what the implementation is really doing, because it seems that some things have been mixed up a little bit. - Add 2 new attributes, "role-type:" and "abuse-c:" - Add NO new objects - Optionally remove the IRT object as it fits well as a role type - Optionally replace "mnt-irt:" attribute with an "irt-c:" - Remove "abuse-mailbox:" from MNTNER, ORGANISATION, PERSON objects - Keep "abuse-mailbox:" and "e-mail:" in ROLE object > In short I can't see any benefit from this proposal. It doesn't > simplify things, it makes things (including finding abuse contact > information) more complicated and for a huge part of the community > it introduces severe problems. A new system often looks more complicated than something you are familiar with. Imho it makes things easier to understand and much easier to maintain. > But I don't think that this kind of policy should be following > particulate interest but should be universal anyway. Like this: - a > resource has an administrative contact (complaints - whether abuse > or not - are administrative issues) - a contact can have an explicit > address for abuse reports. What if the administrative contact is not the place to report abuse to. Just because other companies are different then yours? And admin-c, as I understood it is not the (System) Administration. What would we do in this situation? Where would we store phone number and other information about an abuse department. Because in other companies there are abuse departments wanting to publish these information. > In case the contact chose to not > have/want/need a special abuse address, there are still the > canonical addresses for this contact. Which are usually all spam filtered, because these addresses are in many cases personal addresses. Beside that since these are personal addresses they are underlying query restrictions. > This is what we have, and while > there might be problems somewhere that should or could be addressed, > I don't see the problem the 2011-6 proposal fixes (or actually even > formally addresses)!? If you want to force every resource holder to > have and publish an email that is explicitly meant to be > bulk-spammed, you should propose exactly this (i.e. making an > abuse-mailbox mandatory for the admin-c and announcing it as proper > use to bulk spam these addresses). As a victim of this I'd ofc still > be very much against this. And once again, I'm really wondering what > the businesscase might be to motivate such a situation... If that would have been the intend I would have worded the Proposal exactly in this way ;-) But since I have not and the whole working group agreed on this wording and not another it should be clear that this was not the intention. > Making the abuse-c attribute actually mandatory as described, imho > is a very very bad idea for the reason given above. Effectively > removing the e-mail attribute imho is too, though probably sligthly > less important than the previous issue. Nobody said, that we are removing the e-mail attribute and I can not follow the reasons above, because I do not completely understand the reasons above, because they are referencing just wrong information. That confusion starts already with the fact that the abuse-mailbox attribute shall be mandatory. That is in general just wrong. The abuse-c is mandatory and the object that will be referenced by the abuse-c has to have an abuse-mailbox attribute. If you use your usual object and add an abuse-mailbox or if you create a complete new object for an abuse department and add an abuse-mailbox there is completely open. In other words, if you have 10 different objects and you have to publish an abuse-c there is only need to add an abuse-mailbox attribute to 1 object. Hope this makes things more clear. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From jorgen at hovland.cx Thu Dec 8 15:25:59 2011 From: jorgen at hovland.cx (=?UTF-8?B?SsO4cmdlbiBIb3ZsYW5k?=) Date: Thu, 08 Dec 2011 15:25:59 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: <4EE08BCB.1060906@abusix.com> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> <4EE08BCB.1060906@abusix.com> Message-ID: <4EE0C8F7.1070203@hovland.cx> On 12/08/11 11:04, Tobias Knecht wrote: > If the current system was so obvious to everyone: > - why do so many data maintainers put abuse contact details in "remarks:"? Until recently, the attribute trouble: existed. Then it was removed and moved all the data over to remarks-attribute. At the same time, the abuse-mailbox:-attribute was created. It is going to take at least another 10 years before all handles are updated to this standard. > - why do so many users send complaints to email addresses found in > "notify:" and "changed:" attributes? I always send to all emails I can find when contacting unknown companies. This is because the data accuracy is not always very good and I don't want to waste time resending my email. Secondly, it can be difficult to know if tech-c or admin-c should receive the mail. Adding abuse-c could make it even more difficult to decide. The works-all-the-time solution is to send to anyone. > - why does anyone use "abuse-mailbox:", which has always been optional, > when "admin-c:" has always been available? Because the email:-attribute is by default hidden. Abuse-mailbox: is the workaround. > - The "admin-c:" has never been defined as an abuse contact. It is not > reasonable to assume that everyone who linked an email address to that > attribute wants to receive abuse complaints on that address, even if > some do. That doesn't really matter to me. They are responsible for the resource and can redirect my email to the proper person if they are unable to answer it. Failure to respond is subject to existing ripe policies, although probably never practised. > What if the administrative contact is not the place to report abuse to. > Just because other companies are different then yours? > You are correct about that. Admin-c is always the end-user/customer (Ripe policy). The abuse-contact is however often an ISP/LIR or a comination of one/both/the other depending on the what the issue is. An abusive user on a webforum is subject to admin-c while a hacker could be subject to the ISP abuse-c. From tk at abusix.com Thu Dec 8 15:51:27 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 08 Dec 2011 15:51:27 +0100 Subject: [anti-abuse-wg] 2011-06 New Policy Proposal (Abuse ContactManagement in the RIPE NCC Database) In-Reply-To: <4EE0C8F7.1070203@hovland.cx> References: <201111231347.pANDlMYe004526@gw1.consol.de> <4EDFA9B6.9040503@consol.net> <4EE08BCB.1060906@abusix.com> <4EE0C8F7.1070203@hovland.cx> Message-ID: <4EE0CEEF.8020004@abusix.com> Hi, > On 12/08/11 11:04, Tobias Knecht wrote: >> If the current system was so obvious to everyone: >> - why do so many data maintainers put abuse contact details in >> "remarks:"? > > Until recently, the attribute trouble: existed. Then it was removed and > moved all the data over to remarks-attribute. > At the same time, the abuse-mailbox:-attribute was created. > It is going to take at least another 10 years before all handles are > updated to this standard. I think you are partly right. I do not think that this will take 10 years. The clean-up is a major part of this proposal and I think there will be a lot of opportunities to really clean up things. It could be easily done to use the same objects that are used for an admin-c as an abuse-c as long as an abuse-mailbox attribute is given. If this is not given, maybe one of the higher level ranges has an abuse-c which is absolutely enough. At the end only direct allocated ranges would need an abuse-c set, because this would be enough from a policy point of view. >> - why do so many users send complaints to email addresses found in >> "notify:" and "changed:" attributes? > > I always send to all emails I can find when contacting unknown companies. > This is because the data accuracy is not always very good and I don't > want to waste time resending my email. > Secondly, it can be difficult to know if tech-c or admin-c should > receive the mail. > Adding abuse-c could make it even more difficult to decide. The > works-all-the-time solution is to send to anyone. And that is exactly what this proposal should fix. This will not make it more difficult to decide. If you have an abuse report you have to use abuse-c in future. There is no questions if you should use admin-c or tech-c. If abuse-c is not working you can go up in the hierarchy and/or inform RIPE NCC if something is really going wrong and data is not accurate. This will start a process in whcih RIPE NCC will contact the maintainer and work through with him to get things solved. (Another plus for the data accuracy) The data accuracy part can be looked at by the Task Force if wished by the community as soon as we have consensus on this proposal. >> - why does anyone use "abuse-mailbox:", which has always been optional, >> when "admin-c:" has always been available? > > Because the email:-attribute is by default hidden. > Abuse-mailbox: is the workaround. Exactly. And this workaround should be pushed into a working solution and not staying a workaround. >> - The "admin-c:" has never been defined as an abuse contact. It is not >> reasonable to assume that everyone who linked an email address to that >> attribute wants to receive abuse complaints on that address, even if >> some do. > > That doesn't really matter to me. They are responsible for the resource > and can redirect my email to the proper person if they are unable to > answer it. > Failure to respond is subject to existing ripe policies, although > probably never practised. I'm not on the same page with you here. Redirecting complaints kills the speed of complaints to react fast. And this will end up in bad abuse handling. Great abuse handling imho is fast in processing and in reaction. And we are talking here not about 10 or 15 complaints a day. We are talking about Abuse Departments and abuse mailboxes receiving up to 500.000 messages per day and asking for more. >> What if the administrative contact is not the place to report abuse to. >> Just because other companies are different then yours? >> > > You are correct about that. Admin-c is always the end-user/customer > (Ripe policy). The abuse-contact is however often an ISP/LIR or a > comination of one/both/the other depending on the what the issue is. > An abusive user on a webforum is subject to admin-c while a hacker could > be subject to the ISP abuse-c. Abuse departments are there to solve abuse. No matter what kind of abuse. I do not see a difference in that. Even than while automatic reporting formats like ARF or X-ARF are used more and more it is easily possible to redirect complaints from a role-account to the right place. But is is not easy doable to redirect complaints from a personal email address to the right place. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Mon Dec 12 11:44:09 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 12 Dec 2011 11:44:09 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> Message-ID: <4EE5DAF9.5030505@tana.it> All, some of the replies to spam FAQs are bad. FAQ#1 (What is spam?) looks good enough to me. So I'd start with FAQ#2 that Leo brought up recently On 01/Dec/11 16:27, Leo Vegoda wrote: > Hi Tobias, You wrote: > >> The naive user should use the abuse finder tool which is already >> in place and would run much easier than today > > I disagree and I support the RIPE NCC's answer in its abuse FAQ: > > http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam I too disagree with Tobias' statement, at least for some values of "naive user". Nevertheless, that FAQ's answer is bad. It reads: Should I just ignore spam? Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5. I propose the following replacement text: Should I just ignore spam? Your mailbox provider may equip you with some means to report spam. If you can conveniently deploy such means using your preferred email client, please do so. Otherwise, we recommend that you simply ignore and delete any spam emails you get. Your email client may provide you with filters to do so automatically. Spam is a social problem, not a technical one. Therefore, technical remedies tend to get rather complicated. If you are a mailbox provider or want to learn more about how to find out where the spam is originating from, you can follow the steps in the FAQ entry "How can I counter spam?" Please note that FAQ#5 currently asks "What can I do to stop spam emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is ambiguous, so I quoted its text, and changed the question while at it. FAQ#5 needs an even deeper revision, but please let's tackle them one at a time. Does everyone agree with the replacement text for FAQ#2? > The overwhelming majority of abuse is perpetrated by skilled > professionals who work hard to hide their tracks. Telling ordinary > Internet users that they have a useful role in identifying abuse > sources and reporting them to the hosting networks is a cruel lie. Agreed. > The scale of the problem requires large scale sampling and > statistical analysis rather than individual reports. In part agreed. Individual reports are useful because humans can complement automated filters in detecting spam, albeit both make errors. At any rate, I agree individual reports are to be collected. That's why I'm proposing to amend that entry. From ops.lists at gmail.com Mon Dec 12 15:47:18 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 20:17:18 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EE5DAF9.5030505@tana.it> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: It is a FAQ, not an advocacy portal. Simply link to the MAAWG best practices document - there's several available for providers, end users etc. Tryign to define spam and write faqs on spam ends up as a hair splitting discussion, so I'd rather not have it here or reinvent multiple of maawg's wheels. thank you srs On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely wrote: > All, > some of the replies to spam FAQs are bad. > > FAQ#1 (What is spam?) looks good enough to me. ?So I'd start with > FAQ#2 that Leo brought up recently > > On 01/Dec/11 16:27, Leo Vegoda wrote: >> Hi Tobias, You wrote: >> >>> The naive user should use the abuse finder tool which is already >>> in place and would run much easier than today >> >> I disagree and I support the RIPE NCC's answer in its abuse FAQ: >> >> http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam > > I too disagree with Tobias' statement, at least for some values of > "naive user". ?Nevertheless, that FAQ's answer is bad. ?It reads: > > ? Should I just ignore spam? > > ? Yes. We recommend that you simply ignore and delete any spam > ? emails you get. Spam is a universal problem and there is not much > ? that can be done to stop it. However, if you do want to try to > ? find out where the spam is originating from you can follow the > ? steps in FAQ 5. > > I propose the following replacement text: > > ? Should I just ignore spam? > > ? Your mailbox provider may equip you with some means to report > ? spam. ?If you can conveniently deploy such means using your > ? preferred email client, please do so. ?Otherwise, we recommend > ? that you simply ignore and delete any spam emails you get. ?Your > ? email client may provide you with filters to do so automatically. > > ? Spam is a social problem, not a technical one. ?Therefore, > ? technical remedies tend to get rather complicated. ?If you are a > ? mailbox provider or want to learn more about how to find out where > ? the spam is originating from, you can follow the steps in the FAQ > ? entry "How can I counter spam?" > > Please note that FAQ#5 currently asks "What can I do to stop spam > emails?" ?Since FAQ entries are not numbered, referring to "FAQ 5" is > ambiguous, so I quoted its text, and changed the question while at it. > ?FAQ#5 needs an even deeper revision, but please let's tackle them one > at a time. > > Does everyone agree with the replacement text for FAQ#2? > >> The overwhelming majority of abuse is perpetrated by skilled >> professionals who work hard to hide their tracks. Telling ordinary >> Internet users that they have a useful role in identifying abuse >> sources and reporting them to the hosting networks is a cruel lie. > > Agreed. > >> The scale of the problem requires large scale sampling and >> statistical analysis rather than individual reports. > > In part agreed. ?Individual reports are useful because humans can > complement automated filters in detecting spam, albeit both make > errors. ?At any rate, I agree individual reports are to be collected. > ?That's why I'm proposing to amend that entry. > -- Suresh Ramasubramanian (ops.lists at gmail.com) From michele at blacknight.ie Mon Dec 12 16:14:26 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 12 Dec 2011 15:14:26 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: <49B2D6B8-44EA-4F9B-9EB5-F8CCE6D3F9A7@blacknight.ie> +1 On 12 Dec 2011, at 09:47, Suresh Ramasubramanian wrote: > It is a FAQ, not an advocacy portal. > > Simply link to the MAAWG best practices document - there's several > available for providers, end users etc. > > Tryign to define spam and write faqs on spam ends up as a hair > splitting discussion, so I'd rather not have it here or reinvent > multiple of maawg's wheels. > > thank you > srs > > On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely wrote: >> All, >> some of the replies to spam FAQs are bad. >> >> FAQ#1 (What is spam?) looks good enough to me. So I'd start with >> FAQ#2 that Leo brought up recently >> >> On 01/Dec/11 16:27, Leo Vegoda wrote: >>> Hi Tobias, You wrote: >>> >>>> The naive user should use the abuse finder tool which is already >>>> in place and would run much easier than today >>> >>> I disagree and I support the RIPE NCC's answer in its abuse FAQ: >>> >>> http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam >> >> I too disagree with Tobias' statement, at least for some values of >> "naive user". Nevertheless, that FAQ's answer is bad. It reads: >> >> Should I just ignore spam? >> >> Yes. We recommend that you simply ignore and delete any spam >> emails you get. Spam is a universal problem and there is not much >> that can be done to stop it. However, if you do want to try to >> find out where the spam is originating from you can follow the >> steps in FAQ 5. >> >> I propose the following replacement text: >> >> Should I just ignore spam? >> >> Your mailbox provider may equip you with some means to report >> spam. If you can conveniently deploy such means using your >> preferred email client, please do so. Otherwise, we recommend >> that you simply ignore and delete any spam emails you get. Your >> email client may provide you with filters to do so automatically. >> >> Spam is a social problem, not a technical one. Therefore, >> technical remedies tend to get rather complicated. If you are a >> mailbox provider or want to learn more about how to find out where >> the spam is originating from, you can follow the steps in the FAQ >> entry "How can I counter spam?" >> >> Please note that FAQ#5 currently asks "What can I do to stop spam >> emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is >> ambiguous, so I quoted its text, and changed the question while at it. >> FAQ#5 needs an even deeper revision, but please let's tackle them one >> at a time. >> >> Does everyone agree with the replacement text for FAQ#2? >> >>> The overwhelming majority of abuse is perpetrated by skilled >>> professionals who work hard to hide their tracks. Telling ordinary >>> Internet users that they have a useful role in identifying abuse >>> sources and reporting them to the hosting networks is a cruel lie. >> >> Agreed. >> >>> The scale of the problem requires large scale sampling and >>> statistical analysis rather than individual reports. >> >> In part agreed. Individual reports are useful because humans can >> complement automated filters in detecting spam, albeit both make >> errors. At any rate, I agree individual reports are to be collected. >> That's why I'm proposing to amend that entry. >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From thor.kottelin at turvasana.com Mon Dec 12 16:29:51 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Mon, 12 Dec 2011 17:29:51 +0200 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Suresh Ramasubramanian > Sent: Monday, December 12, 2011 4:47 PM > To: Alessandro Vesely > Cc: anti-abuse-wg at ripe.net > It is a FAQ, not an advocacy portal. > > Simply link to the MAAWG best practices document - there's several > available for providers, end users etc. Linking to MAAWG could also be viewed as a form of advocacy, and the interests of RIPE may not be entirely aligned with those of MAAWG. As an example, Yahoo is a MAAWG member at the highest level of influence ('Sponsor', which includes a seat on the MAAWG Board of Directors), but decade after decade, Yahoo inflicts enormous amounts of spam on the RIPE community and other Internet users. Other MAAWG members with reputations for spam and/or spam support include Amazon and Constant Contact. I would prefer for RIPE to produce its own information on spam and other forms of abuse of the network, as needed. -- Thor Kottelin http://www.anta.net/ From ops.lists at gmail.com Mon Dec 12 17:14:28 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 21:44:28 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: MAAWG is not an advocacy or lobbying organization. It is an organization that advocates best practices. "Reps for spam or spam support" and constant contact .. jesus, you don't know too much do you? As for yahoo - or gmail or any of the other large free services out there, they can deter spammers from signing up. And they can spam filter their outbound email. But I seriously doubt they, or anybody else, is going to catch 100% of the spam. They just happen to have like several million users more than you do, so the volume of spam (as opposed to the percentage of spam) is higher. As for the interests of RIPE not being "aligned" with MAAWG .. I'll see your spam from amazon and constant contact and raise you a big bunch of fake romanian and eastern european LIRs, assigned PA/PI netblocks given to botmasters, "we are not the * police" memes etc. --srs On Mon, Dec 12, 2011 at 8:59 PM, Thor Kottelin wrote: > Linking to MAAWG could also be viewed as a form of advocacy, and the > interests of RIPE may not be entirely aligned with those of MAAWG. > > As an example, Yahoo is a MAAWG member at the highest level of influence > ('Sponsor', which includes a seat on the MAAWG Board of Directors), but > decade after decade, Yahoo inflicts enormous amounts of spam on the RIPE > community and other Internet users. Other MAAWG members with reputations for > spam and/or spam support include Amazon and Constant Contact. > > I would prefer for RIPE to produce its own information on spam and other > forms of abuse of the network, as needed. -- Suresh Ramasubramanian (ops.lists at gmail.com) From pk at DENIC.DE Mon Dec 12 17:33:23 2011 From: pk at DENIC.DE (Peter Koch) Date: Mon, 12 Dec 2011 17:33:23 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: <20111212163323.GD30174@x27.adm.denic.de> On Mon, Dec 12, 2011 at 08:17:18PM +0530, Suresh Ramasubramanian wrote: > It is a FAQ, not an advocacy portal. i'd like to suggest the FAQ is maintained as part of the NCC's operational duties. My experience is that NCC staff quite well listens to community input, but this should not encourage micro management. > Simply link to the MAAWG best practices document - there's several > available for providers, end users etc. MAAWG is but one organization. I am not convinced that, undue endorsement or not, the user community is best served by a 'simple link' to MAAWG documents. -Peter From vesely at tana.it Mon Dec 12 17:39:24 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 12 Dec 2011 17:39:24 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <49B2D6B8-44EA-4F9B-9EB5-F8CCE6D3F9A7@blacknight.ie> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <49B2D6B8-44EA-4F9B-9EB5-F8CCE6D3F9A7@blacknight.ie> Message-ID: <4EE62E3C.2070500@tana.it> That would be fine too. It's far better not to have a "Hacking & Spamming" section [1] in the FAQ than having wrong entries. Is it possible to remove it? [1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming thanks On 12/Dec/11 16:14, Michele Neylon :: Blacknight wrote: > +1 > > On 12 Dec 2011, at 09:47, Suresh Ramasubramanian wrote: > >> It is a FAQ, not an advocacy portal. >> >> Simply link to the MAAWG best practices document - there's several >> available for providers, end users etc. >> >> Tryign to define spam and write faqs on spam ends up as a hair >> splitting discussion, so I'd rather not have it here or reinvent >> multiple of maawg's wheels. >> >> thank you >> srs >> >> On Mon, Dec 12, 2011 at 4:14 PM, Alessandro Vesely wrote: >>> All, >>> some of the replies to spam FAQs are bad. >>> >>> FAQ#1 (What is spam?) looks good enough to me. So I'd start with >>> FAQ#2 that Leo brought up recently >>> >>> On 01/Dec/11 16:27, Leo Vegoda wrote: >>>> Hi Tobias, You wrote: >>>> >>>>> The naive user should use the abuse finder tool which is already >>>>> in place and would run much easier than today >>>> >>>> I disagree and I support the RIPE NCC's answer in its abuse FAQ: >>>> >>>> http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam >>> >>> I too disagree with Tobias' statement, at least for some values of >>> "naive user". Nevertheless, that FAQ's answer is bad. It reads: >>> >>> Should I just ignore spam? >>> >>> Yes. We recommend that you simply ignore and delete any spam >>> emails you get. Spam is a universal problem and there is not much >>> that can be done to stop it. However, if you do want to try to >>> find out where the spam is originating from you can follow the >>> steps in FAQ 5. >>> >>> I propose the following replacement text: >>> >>> Should I just ignore spam? >>> >>> Your mailbox provider may equip you with some means to report >>> spam. If you can conveniently deploy such means using your >>> preferred email client, please do so. Otherwise, we recommend >>> that you simply ignore and delete any spam emails you get. Your >>> email client may provide you with filters to do so automatically. >>> >>> Spam is a social problem, not a technical one. Therefore, >>> technical remedies tend to get rather complicated. If you are a >>> mailbox provider or want to learn more about how to find out where >>> the spam is originating from, you can follow the steps in the FAQ >>> entry "How can I counter spam?" >>> >>> Please note that FAQ#5 currently asks "What can I do to stop spam >>> emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is >>> ambiguous, so I quoted its text, and changed the question while at it. >>> FAQ#5 needs an even deeper revision, but please let's tackle them one >>> at a time. >>> >>> Does everyone agree with the replacement text for FAQ#2? >>> >>>> The overwhelming majority of abuse is perpetrated by skilled >>>> professionals who work hard to hide their tracks. Telling ordinary >>>> Internet users that they have a useful role in identifying abuse >>>> sources and reporting them to the hosting networks is a cruel lie. >>> >>> Agreed. >>> >>>> The scale of the problem requires large scale sampling and >>>> statistical analysis rather than individual reports. >>> >>> In part agreed. Individual reports are useful because humans can >>> complement automated filters in detecting spam, albeit both make >>> errors. At any rate, I agree individual reports are to be collected. >>> That's why I'm proposing to amend that entry. >>> >> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> > > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://blacknight.mobi/ > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > UK: 0844 484 9361 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > From ops.lists at gmail.com Mon Dec 12 17:49:34 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 22:19:34 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EE62E3C.2070500@tana.it> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <49B2D6B8-44EA-4F9B-9EB5-F8CCE6D3F9A7@blacknight.ie> <4EE62E3C.2070500@tana.it> Message-ID: Instead of all that I'd focus on this little nugget from the faq. Which was, is and will remain central to why this wg was set up in the first place. ________ Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on? ? The records in the Regional Internet Registries' (RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records. On Mon, Dec 12, 2011 at 10:09 PM, Alessandro Vesely wrote: > That would be fine too. ?It's far better not to have a "Hacking & > Spamming" section [1] in the FAQ than having wrong entries. ?Is it > possible to remove it? > > [1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming > From vesely at tana.it Mon Dec 12 18:03:26 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 12 Dec 2011 18:03:26 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <49B2D6B8-44EA-4F9B-9EB5-F8CCE6D3F9A7@blacknight.ie> <4EE62E3C.2070500@tana.it> Message-ID: <4EE633DE.8020506@tana.it> Yes, FAQ#6 is to be removed as well. On 12/Dec/11 17:49, Suresh Ramasubramanian wrote: > Instead of all that I'd focus on this little nugget from the faq. > Which was, is and will remain central to why this wg was set up in the > first place. > > ________ > > Why are there no contact details or incorrect contact details for > reporting spam email listed in the RIPE Database for the IP address I > searched on? ? > > The records in the Regional Internet Registries' (RIR) databases are > entered and maintained by the organisations that receive IP addresses > from each RIR. The RIRs do not check the accuracy of any of the > records in the database or make any changes to the data maintained by > these organisations. The RIPE NCC has no power to update any of these > records. > > On Mon, Dec 12, 2011 at 10:09 PM, Alessandro Vesely wrote: >> That would be fine too. It's far better not to have a "Hacking & >> Spamming" section [1] in the FAQ than having wrong entries. Is it >> possible to remove it? >> >> [1] http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming >> > From peter at hk.ipsec.se Mon Dec 12 18:00:00 2011 From: peter at hk.ipsec.se (peter h) Date: Mon, 12 Dec 2011 18:00:00 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> Message-ID: <201112121800.00898.peter@hk.ipsec.se> On Monday 12 December 2011 17.14, Suresh Ramasubramanian wrote: > MAAWG is not an advocacy or lobbying organization. It is an > organization that advocates best practices. > > "Reps for spam or spam support" and constant contact .. jesus, you > don't know too much do you? Yahoo in one of the major sources of "ISP-based spam. The majority however comes from stolen windoze (home)computers. -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From ops.lists at gmail.com Mon Dec 12 18:26:05 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 22:56:05 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <201112121800.00898.peter@hk.ipsec.se> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <201112121800.00898.peter@hk.ipsec.se> Message-ID: And that'd be just how much as a percentage of the legitimate mail you get from their IP space? Note - please have data points that are based on a more substantial number of users than say "corporate exchange server" or "personal linux box" On Mon, Dec 12, 2011 at 10:30 PM, peter h wrote: > > Yahoo in one of the major sources of "ISP-based spam. The majority however > comes from stolen windoze (home)computers. -- Suresh Ramasubramanian (ops.lists at gmail.com) From thor.kottelin at turvasana.com Mon Dec 12 18:39:58 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Mon, 12 Dec 2011 19:39:58 +0200 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Monday, December 12, 2011 6:14 PM > To: Thor Kottelin > Cc: anti-abuse-wg at ripe.net > "Reps for spam or spam support" and constant contact .. jesus, you > don't know too much do you? No, definitely not too much, but considering your vast experience in combating spam, I would be surprised were you to deny the reputation I mentioned. That is really a side issue though. My point was that MAAWG and RIPE are dissimilar communities with dissimilar memberships. Whether those dissimilarities are minor enough for RIPE to refer to MAAWG documents instead of continue creating its own is a matter for consensus. > As for yahoo - or gmail or any of the other large free services out > there, they can deter spammers from signing up. And they can spam > filter their outbound email. But I seriously doubt they, or > anybody > else, is going to catch 100% of the spam. They just happen to > have > like several million users more than you do, so the volume of spam > (as > opposed to the percentage of spam) is higher. It is the volume that hurts, not the percentage. -- Thor Kottelin http://www.anta.net/ From peter at hk.ipsec.se Mon Dec 12 18:54:44 2011 From: peter at hk.ipsec.se (peter h) Date: Mon, 12 Dec 2011 18:54:44 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <201112121800.00898.peter@hk.ipsec.se> Message-ID: <201112121854.45171.peter@hk.ipsec.se> On Monday 12 December 2011 18.26, Suresh Ramasubramanian wrote: > And that'd be just how much as a percentage of the legitimate mail you > get from their IP space? 100% It's years ago since i had any mail conversation with a yahoo-customer. But i still get spam from various yahoo-ranges, none of them related to former contacts. It's simply a lazy policy that allows abuse of their resources. I can mention gmail as a site with excellent spam policy. Anyone trying to send spam through gmail will be "killed" fast. So it's not impossible to block spammers, but it takes some resources and comittment to do so. > > Note - please have data points that are based on a more substantial > number of users than say "corporate exchange server" or "personal > linux box" > > On Mon, Dec 12, 2011 at 10:30 PM, peter h wrote: > > > > Yahoo in one of the major sources of "ISP-based spam. The majority however > > comes from stolen windoze (home)computers. > > > -- Peter H?kanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det ?r billigare att g?ra r?tt. Det ?r dyrt att laga fel. ) From ops.lists at gmail.com Mon Dec 12 19:09:25 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 23:39:25 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: On Mon, Dec 12, 2011 at 11:09 PM, Thor Kottelin wrote: > That is really a side issue though. My point was that MAAWG and RIPE are > dissimilar communities with dissimilar memberships. Whether those > dissimilarities are minor enough for RIPE to refer to MAAWG documents > instead of continue creating its own is a matter for consensus. Er, the very same memberships if you look at organizations. If the IP and routing people come to RIPE and make one set of policies, without knowing anything at all about what their colleagues from the very same SP's abuse and security teams are doing at other events .. what does that say? > It is the volume that hurts, not the percentage. Yes that's why I was more like "put yourself in the shoes of a large provider first". -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Mon Dec 12 19:11:20 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 23:41:20 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <201112121854.45171.peter@hk.ipsec.se> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <201112121800.00898.peter@hk.ipsec.se> <201112121854.45171.peter@hk.ipsec.se> Message-ID: No no... let's not confine conversation to one mailbox, or one small personal domain. Please. If you run a large enough mail system, you'll see quite a lot of spam issues on gmail as well (google groups and other google properties too, just as you'd see distinct yahoo properties such as yahoogroups have their own abuse volumes, challenges etc) On Mon, Dec 12, 2011 at 11:24 PM, peter h wrote: > > It's years ago since i had any mail conversation with a yahoo-customer. But i still get > spam from various yahoo-ranges, none of them related to former contacts. It's simply > a lazy policy that allows abuse of their resources. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Mon Dec 12 19:11:45 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 12 Dec 2011 23:41:45 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <201112121800.00898.peter@hk.ipsec.se> <201112121854.45171.peter@hk.ipsec.se> Message-ID: and s/gmail/any other provider/ and my statement below would still apply. I'm not picking on gmail or yahoo here. On Mon, Dec 12, 2011 at 11:41 PM, Suresh Ramasubramanian wrote: > No no... let's not confine conversation to one mailbox, or one small > personal domain. ?Please. > > If you run a large enough mail system, you'll see quite a lot of spam > issues on gmail as well (google groups and other google properties > too, just as you'd see distinct yahoo properties such as yahoogroups > have their own abuse volumes, challenges etc) > > On Mon, Dec 12, 2011 at 11:24 PM, peter h wrote: >> >> It's years ago since i had any mail conversation with a yahoo-customer. But i still get >> spam from various yahoo-ranges, none of them related to former contacts. It's simply >> a lazy policy that allows abuse of their resources. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) -- Suresh Ramasubramanian (ops.lists at gmail.com) From joe at oregon.uoregon.edu Mon Dec 12 20:22:06 2011 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Mon, 12 Dec 2011 11:22:06 -0800 (PST) Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy Message-ID: <11121211220660_3B34@oregon.uoregon.edu> Hi, When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/ I'd probably write something that looks quite a bit different than what's currently there. For example, just starting at the top: -- "What is spam? FAQ currently says: "Spam is junk email, usually offering bogus products and invitations to pornography sites. Sometimes, spam email is used to spread viruses. You may also receive 'phishing' emails. These are emails that look like they have been sent by a legitimate organisation and attempt to fraudulently acquire sensitive information, such as passwords and credit card details." I'd suggest that the definition of "spam" that's available at http://www.spamhaus.org/definition.html is significantly stronger. -- "Should I just ignore spam?" FAQ currently says: "Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5." I'd suggest that's a passive/defeatist approach that spammers absolutely adore since it fails to put any back pressure on spammers. By NOT reporting spam, service providers hosting spam-related sites (and service providers with botted customers) get no feedback that will allow them to clean up their issues. That really needs to change. I'd suggest: "No. Consider reporting spam via a well-established spam reporting channel. This might be a "this is spam" button offered as part of your provider's web email interface, or via a third party spam reporting service such as Spamcop (http://spamcop.net/), which is free. If you want to report spam directly, you may find it helpful to see the abuse reporting addresses available from http://abuse.net/" I'd like to suggest that users report spam to appropriate government agencies, see for example: http://spamlinks.net/track-report-addresses.htm#country I would also note that encouraging user reporting is consistent with the explanation that's provided later in the FAQ under "What can I do to stop spam emails?" which goes into some detail when it comes to how to actually do manual spam reporting. -- "What can the RIPE NCC do about the spam email I have received?" FAQ currently says: "Unfortunately, the RIPE NCC can do nothing about spam email or 'phishing' email. The RIPE NCC does not send, or facilitate the sending of, spam email. Nor is it responsible for any spam you receive. It is also unable to investigate any complaints about spamming." Again, that's not the answer to this FAQ item that I'd like to see. I would like to see RIPE NCC acknowledge that it *does* have a role in combatting network abuse, particularly when it comes to ensuring that the resources it manages are not abused. For example, if RIPE NCC learns that a network resource has been acquired under fraudulent pretenses for the purpose of engaging in network abuse, or a network resource has bogus point of contact information, those behaviors are not acceptable and will result in a review by RIPE NCC and, if that abuse is confirmed, those resources will be reclaimed. Obviously that would also imply a change to "Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on?" which states "The records in the Regional Internet Registries'(RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records." If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see: -- https://www.arin.net/policy/nrpm.html#three6 "3.6 Annual Whois POC Validation "3.6.1 Method of Annual Verification "During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." -- http://www.apnic.net/apnic-info/whois_search/abuse-and-spamming/invalid-contact-form "Use this form to report invalid contact details found in the APNIC Whois Database. APNIC will take appropriate steps to try to have the database objects updated." See also http://www.apnic.net/policy/policy-environment#processing at 7.1 ("Validity of IP address delegations") -- http://lacnic.net/en/politicas/manual7-1.html ("Resource Recovery") See also http://lacnic.net/en/politicas/manual7-1.html "The organizations receiving IPs addresses from LACNIC have the commitment to keep their registration information updated. "But, in the case it is noticed that some information is invalid we ask you to communicated the fact to hostmaster at lacnic.net informing the IP address with invalid registration information." So, RIPE may not have processes for keeping their part of the global databases accurate, but other RIRs do... There are also many redundancies in the FAQ, e.g., see the "Can I stop spam?" item vis-a-vis "Should I just ignore spam?" Or "I want to know more about spam" vs. "Where can I find more information about spam" Or "How do I found out who's behind a suspect message?" vs. the tutorial on reading headers that's in "What can I do to stop spam emails?" And there are other duplications of that sort in the FAQ... I think it probably grew over time, but as stuff got slotted into the document, no deconfliction and reconciliation ever took place. I think that work to do that would strengthen the document and make it considerably stronger. Regards, Joe From thor.kottelin at turvasana.com Mon Dec 12 22:13:27 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Mon, 12 Dec 2011 23:13:27 +0200 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <11121211220660_3B34@oregon.uoregon.edu> References: <11121211220660_3B34@oregon.uoregon.edu> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Joe St Sauver > Sent: Monday, December 12, 2011 9:22 PM > To: anti-abuse-wg at ripe.net > When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking- > spamming/ > I'd probably write something that looks quite a bit different than > what's > currently there. The suggestions that followed are excellent. Thank you. (Proposal snipped due to its length but available at http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2011-December/001161.html.) -- Thor Kottelin http://www.anta.net/ From rezaf at mindspring.com Mon Dec 12 22:25:50 2011 From: rezaf at mindspring.com (Reza Farzan) Date: Mon, 12 Dec 2011 16:25:50 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <11121211220660_3B34@oregon.uoregon.edu> References: <11121211220660_3B34@oregon.uoregon.edu> Message-ID: Hello All, Joe St Sauver's comments and suggestions make perfect sense and RIPE NCC needs to follow such a sound advice. Joe's specific recommendation that "Consider reporting spam via a well-established spam reporting Channel" should be promoted by ALL user groups, and ISPs. RIPE's FAQ recommendation that "simply ignore and delete any spam emails you get" has been one of the main causes proliferation of Spam everywhere. By guiding users to sites like this, http://spamlinks.net/track-report-addresses.htm, almost anyone can report a Spam properly and keep ISP's aware of malicious traffic that passes through their servers. As Joe suggested, RIPE's FAQ must provide better guidance than reminding us to simply ignore and delete any spam emails you get. By remaining diligent, we can make this situation better for everyone. Thank you, Reza Farzan ====================== > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net > [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Joe St Sauver > Sent: Monday, December 12, 2011 2:22 PM > To: anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] Spam FAQs need revision, was > 2011-06 New Policy > > Hi, > > When I look at > http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/ > I'd probably write something that looks quite a bit different > than what's currently there. > > For example, just starting at the top: > > -- "What is spam? > > FAQ currently says: > > "Spam is junk email, usually offering bogus products and > invitations to > pornography sites. Sometimes, spam email is used to spread > viruses. You > may also receive 'phishing' emails. These are emails that > look like they > have been sent by a legitimate organisation and attempt to > fraudulently > acquire sensitive information, such as passwords and > credit card details." > > I'd suggest that the definition of "spam" that's available at > http://www.spamhaus.org/definition.html is significantly stronger. > > -- "Should I just ignore spam?" > > FAQ currently says: > > "Yes. We recommend that you simply ignore and delete any > spam emails you > get. Spam is a universal problem and there is not much > that can be done > to stop it. However, if you do want to try to find out > where the spam is > originating from you can follow the steps in FAQ 5." > > I'd suggest that's a passive/defeatist approach that > spammers absolutely > adore since it fails to put any back pressure on spammers. By NOT > reporting spam, service providers hosting spam-related > sites (and service > providers with botted customers) get no feedback that will > allow them to > clean up their issues. That really needs to change. > > I'd suggest: > > "No. Consider reporting spam via a well-established > spam reporting > channel. This might be a "this is spam" button offered > as part of > your provider's web email interface, or via a third party spam > reporting service such as Spamcop > (http://spamcop.net/), which is > free. If you want to report spam directly, you may find > it helpful > to see the abuse reporting addresses available from > http://abuse.net/" > > I'd like to suggest that users report spam to appropriate > government > agencies, see for example: > http://spamlinks.net/track-report-addresses.htm#country > > I would also note that encouraging user reporting is > consistent with > the explanation that's provided later in the FAQ under > "What can I do to stop spam emails?" which goes into some detail > when it comes to how to actually do manual spam reporting. > > -- "What can the RIPE NCC do about the spam email I have received?" > > FAQ currently says: > > "Unfortunately, the RIPE NCC can do nothing about spam email or > 'phishing' email. The RIPE NCC does not send, or > facilitate the sending > of, spam email. Nor is it responsible for any spam you > receive. It is > also unable to investigate any complaints about spamming." > > Again, that's not the answer to this FAQ item that I'd > like to see. > > I would like to see RIPE NCC acknowledge that it *does* have a role > in combatting network abuse, particularly when it comes to > ensuring > that the resources it manages are not abused. For example, > if RIPE NCC > learns that a network resource has been acquired under fraudulent > pretenses for the purpose of engaging in network abuse, or > a network > resource has bogus point of contact information, those > behaviors are > not acceptable and will result in a review by RIPE NCC > and, if that > abuse is confirmed, those resources will be reclaimed. > > Obviously that would also imply a change to > > "Why are there no contact details or incorrect contact details for > reporting spam email listed in the RIPE Database for the > IP address > I searched on?" > > which states > > "The records in the Regional Internet Registries'(RIR) > databases are > entered and maintained by the organisations that receive > IP addresses > from each RIR. The RIRs do not check the accuracy of any > of the records > in the database or make any changes to the data maintained > by these > organisations. The RIPE NCC has no power to update any of > these records." > > If nothing else, that FAQ answer should *at least* be > updated to correct > factual inaccuracies because at least *some* other RIRs > *DO* check and/or > correct inaccuracies in their databases, e.g., see, in the > case of ARIN, > APNIC and LACNIC, see: > > -- https://www.arin.net/policy/nrpm.html#three6 > > "3.6 Annual Whois POC Validation > > "3.6.1 Method of Annual Verification > > "During ARINs annual Whois POC validation, an email > will be sent to > every POC in the Whois database. Each POC will have a > maximum of 60 > days to respond with an affirmative that their Whois contact > information is correct and complete. Unresponsive POC > email addresses > shall be marked as such in the database. If ARIN staff > deems a POC to > be completely and permanently abandoned or otherwise > illegitimate, > the POC record shall be marked invalid. ARIN will > maintain, and make > readily available to the community, a current list of > number resources > with no valid POC; this data will be subject to the > current bulk Whois > policy." > > -- > http://www.apnic.net/apnic-info/whois_search/abuse-and-spammin > g/invalid-contact-form > > "Use this form to report invalid contact details found > in the APNIC > Whois Database. APNIC will take appropriate steps to > try to have the > database objects updated." > > See also > http://www.apnic.net/policy/policy-environment#processing > at 7.1 ("Validity of IP address delegations") > > -- http://lacnic.net/en/politicas/manual7-1.html > ("Resource Recovery") > > See also http://lacnic.net/en/politicas/manual7-1.html > > "The organizations receiving IPs addresses from LACNIC have the > commitment to keep their registration information updated. > > "But, in the case it is noticed that some information > is invalid we > ask you to communicated the fact to > hostmaster at lacnic.net informing > the IP address with invalid registration information." > > So, RIPE may not have processes for keeping their part of > the global > databases accurate, but other RIRs do... > > There are also many redundancies in the FAQ, e.g., see the > "Can I stop spam?" > item vis-a-vis "Should I just ignore spam?" > > Or "I want to know more about spam" vs. "Where can I find > more information about spam" > > Or "How do I found out who's behind a suspect message?" vs. > the tutorial on reading headers that's in "What can I do to > stop spam emails?" > > And there are other duplications of that sort in the FAQ... I > think it probably grew over time, but as stuff got slotted > into the document, no deconfliction and reconciliation ever > took place. I think that work to do that would strengthen the > document and make it considerably stronger. > > Regards, > > Joe > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.0.0.888, Virus/Spyware Database: 6.18870) > http://www.pctools.com/ ======= > From moderated at localhost Mon Dec 12 22:08:20 2011 From: moderated at localhost (Moderated) Date: Mon, 12 Dec 2011 22:08:20 +0100 Subject: [Moderated] Message-ID: This message has been removed from the archive. From moderated at localhost Tue Dec 13 10:30:36 2011 From: moderated at localhost (Moderated) Date: Tue, 13 Dec 2011 10:30:36 +0100 Subject: [Moderated] Message-ID: This message has been removed from the archive. From denatrisconsult at hotmail.nl Tue Dec 13 11:09:41 2011 From: denatrisconsult at hotmail.nl (Wout de Natris) Date: Tue, 13 Dec 2011 11:09:41 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: References: Message-ID: Hi, > -- "Should I just ignore spam?" On the spam should be ignored discussion. It's time people realised and acted upon the fact that by reporting spam and all the content/fraud/phishing/malware related with spam to spam reporting centres and/or authorities, maybe just something will change. Somewhere in this data the identity of the spammers lies hidden, including the data of all involved, whether consciously or unconsciously. Also countries or agencies less active will be revealed. Transparency is what this discussion needs and that may just prove half of the much needed silver bullet. Without reporting there is no analyses of data. So please change the topic to report spam actively where possible. And perhaps even add that if there is no spam reporting centre in a country, to lobby to your local government to start one. Regards, Wout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - De Natris Consult Raaphorst 33 Tel: +31 648388813 2352 KJ Leiderdorp Skype: wout.de.natris denatrisconsult at hotmail.nl http://www.denatrisconsult.nl Blog http://woutdenatris.wordpress.com ******** Due to privacy concerns, part of this message has been removed as per the sender's request ******** -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Tue Dec 13 11:52:23 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 13 Dec 2011 11:52:23 +0100 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <11121211220660_3B34@oregon.uoregon.edu> References: <11121211220660_3B34@oregon.uoregon.edu> Message-ID: <1323773544.2031.7.camel@shane-desktop> Joe, It's a bit of a tangent, but... On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote: > If nothing else, that FAQ answer should *at least* be updated to correct > factual inaccuracies because at least *some* other RIRs *DO* check and/or > correct inaccuracies in their databases, e.g., see, in the case of ARIN, > APNIC and LACNIC, see: > > -- https://www.arin.net/policy/nrpm.html#three6 > > "3.6 Annual Whois POC Validation > > "3.6.1 Method of Annual Verification > > "During ARINs annual Whois POC validation, an email will be sent to > every POC in the Whois database. Each POC will have a maximum of 60 > days to respond with an affirmative that their Whois contact > information is correct and complete. Unresponsive POC email addresses > shall be marked as such in the database. If ARIN staff deems a POC to > be completely and permanently abandoned or otherwise illegitimate, > the POC record shall be marked invalid. ARIN will maintain, and make > readily available to the community, a current list of number resources > with no valid POC; this data will be subject to the current bulk Whois > policy." What a great method for finding networks that are poorly monitored and maintained! Simply check ARIN's Whois database until you find networks with POC that are marked as invalid! I hope that RIPE does not adopt this address-hijacking-friendly technique. :( -- Shane From laura at ripe.net Tue Dec 13 12:39:43 2011 From: laura at ripe.net (Laura Cobley) Date: Tue, 13 Dec 2011 12:39:43 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EE5DAF9.5030505@tana.it> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> Message-ID: <4EE7397F.4020908@ripe.net> Dear all, We are working on improving the procedures and documentation in the area of reporting abuse. As part of this work, we have already rewritten the FAQs currently being discussed on this list. We will inform you as soon as the revised FAQs are published. Best regards, Laura Cobley RIPE NCC Customer Services Manager On 12/12/11 11:44 AM, Alessandro Vesely wrote: > All, > some of the replies to spam FAQs are bad. > > FAQ#1 (What is spam?) looks good enough to me. So I'd start with > FAQ#2 that Leo brought up recently > > On 01/Dec/11 16:27, Leo Vegoda wrote: >> Hi Tobias, You wrote: >> >>> The naive user should use the abuse finder tool which is already >>> in place and would run much easier than today >> >> I disagree and I support the RIPE NCC's answer in its abuse FAQ: >> >> http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam > > I too disagree with Tobias' statement, at least for some values of > "naive user". Nevertheless, that FAQ's answer is bad. It reads: > > Should I just ignore spam? > > Yes. We recommend that you simply ignore and delete any spam > emails you get. Spam is a universal problem and there is not much > that can be done to stop it. However, if you do want to try to > find out where the spam is originating from you can follow the > steps in FAQ 5. > > I propose the following replacement text: > > Should I just ignore spam? > > Your mailbox provider may equip you with some means to report > spam. If you can conveniently deploy such means using your > preferred email client, please do so. Otherwise, we recommend > that you simply ignore and delete any spam emails you get. Your > email client may provide you with filters to do so automatically. > > Spam is a social problem, not a technical one. Therefore, > technical remedies tend to get rather complicated. If you are a > mailbox provider or want to learn more about how to find out where > the spam is originating from, you can follow the steps in the FAQ > entry "How can I counter spam?" > > Please note that FAQ#5 currently asks "What can I do to stop spam > emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is > ambiguous, so I quoted its text, and changed the question while at it. > FAQ#5 needs an even deeper revision, but please let's tackle them one > at a time. > > Does everyone agree with the replacement text for FAQ#2? > >> The overwhelming majority of abuse is perpetrated by skilled >> professionals who work hard to hide their tracks. Telling ordinary >> Internet users that they have a useful role in identifying abuse >> sources and reporting them to the hosting networks is a cruel lie. > > Agreed. > >> The scale of the problem requires large scale sampling and >> statistical analysis rather than individual reports. > > In part agreed. Individual reports are useful because humans can > complement automated filters in detecting spam, albeit both make > errors. At any rate, I agree individual reports are to be collected. > That's why I'm proposing to amend that entry. > > From ops.lists at gmail.com Tue Dec 13 15:15:26 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 13 Dec 2011 19:45:26 +0530 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <1323773544.2031.7.camel@shane-desktop> References: <11121211220660_3B34@oregon.uoregon.edu> <1323773544.2031.7.camel@shane-desktop> Message-ID: security by obscurity you mean? --srs (iPad) On 13-Dec-2011, at 16:22, Shane Kerr wrote: > Joe, > > It's a bit of a tangent, but... > > On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote: >> If nothing else, that FAQ answer should *at least* be updated to correct >> factual inaccuracies because at least *some* other RIRs *DO* check and/or >> correct inaccuracies in their databases, e.g., see, in the case of ARIN, >> APNIC and LACNIC, see: >> >> -- https://www.arin.net/policy/nrpm.html#three6 >> >> "3.6 Annual Whois POC Validation >> >> "3.6.1 Method of Annual Verification >> >> "During ARINs annual Whois POC validation, an email will be sent to >> every POC in the Whois database. Each POC will have a maximum of 60 >> days to respond with an affirmative that their Whois contact >> information is correct and complete. Unresponsive POC email addresses >> shall be marked as such in the database. If ARIN staff deems a POC to >> be completely and permanently abandoned or otherwise illegitimate, >> the POC record shall be marked invalid. ARIN will maintain, and make >> readily available to the community, a current list of number resources >> with no valid POC; this data will be subject to the current bulk Whois >> policy." > > What a great method for finding networks that are poorly monitored and > maintained! Simply check ARIN's Whois database until you find networks > with POC that are marked as invalid! > > I hope that RIPE does not adopt this address-hijacking-friendly > technique. :( > > -- > Shane > > From Woeber at CC.UniVie.ac.at Tue Dec 13 15:48:34 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 13 Dec 2011 14:48:34 +0000 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: References: <11121211220660_3B34@oregon.uoregon.edu> <1323773544.2031.7.camel@shane-desktop> Message-ID: <4EE765C2.2090907@CC.UniVie.ac.at> Suresh Ramasubramanian wrote: > security by obscurity you mean? this may be seen as one end of a stick - offering the info on a silver platter may be seen as the other end :-) wilfried > --srs (iPad) > > On 13-Dec-2011, at 16:22, Shane Kerr wrote: > > >>Joe, >> >>It's a bit of a tangent, but... >> >>On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote: >> >>> If nothing else, that FAQ answer should *at least* be updated to correct >>> factual inaccuracies because at least *some* other RIRs *DO* check and/or >>> correct inaccuracies in their databases, e.g., see, in the case of ARIN, >>> APNIC and LACNIC, see: >>> >>> -- https://www.arin.net/policy/nrpm.html#three6 >>> >>> "3.6 Annual Whois POC Validation >>> >>> "3.6.1 Method of Annual Verification >>> >>> "During ARINs annual Whois POC validation, an email will be sent to >>> every POC in the Whois database. Each POC will have a maximum of 60 >>> days to respond with an affirmative that their Whois contact >>> information is correct and complete. Unresponsive POC email addresses >>> shall be marked as such in the database. If ARIN staff deems a POC to >>> be completely and permanently abandoned or otherwise illegitimate, >>> the POC record shall be marked invalid. ARIN will maintain, and make >>> readily available to the community, a current list of number resources >>> with no valid POC; this data will be subject to the current bulk Whois >>> policy." >> >>What a great method for finding networks that are poorly monitored and >>maintained! Simply check ARIN's Whois database until you find networks >>with POC that are marked as invalid! >> >>I hope that RIPE does not adopt this address-hijacking-friendly >>technique. :( >> >>-- >>Shane From P.Vissers at opta.nl Tue Dec 13 16:46:49 2011 From: P.Vissers at opta.nl (Vissers, Pepijn) Date: Tue, 13 Dec 2011 15:46:49 +0000 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <1323773544.2031.7.camel@shane-desktop> References: <11121211220660_3B34@oregon.uoregon.edu> <1323773544.2031.7.camel@shane-desktop> Message-ID: > I hope that RIPE does not adopt this address-hijacking-friendly > technique. :( One could argue that some form of validation is better than no validation at all. The follow up question is 'should this data be made readily available to the community' the way ARIN does, or are there other ways to raise the bar for your doom scenario. Pepijn +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail at opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail at opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message. From vesely at tana.it Tue Dec 13 20:17:42 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 13 Dec 2011 20:17:42 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: References: Message-ID: <4EE7A4D6.6040503@tana.it> Hi Wout! On 13/Dec/11 11:09, Wout de Natris wrote: > >> -- "Should I just ignore spam?" > > On the spam should be ignored discussion. It's time people realised > and acted upon the fact that by reporting spam and all the > content/fraud/phishing/malware related with spam to spam reporting > centres and/or authorities, maybe just something will change. Agreed, ignoring spam will only allow changes for the worse... > Somewhere in this data the identity of the spammers lies hidden, > including the data of all involved, whether consciously or > unconsciously. Also countries or agencies less active will be > revealed. Transparency is what this discussion needs and that may just > prove half of the much needed silver bullet. Without reporting there > is no analyses of data. The data only reveals the (first) covering screen, but it is indeed true that headers, which are crucial for identifying senders, are usually hidden from "naive users". Users have to be trained to report messages integrally. But then doing so they may expose more data than they may want. Mailbox providers are in the best position to tackle this issue, because they know exactly where their SMTP software stores the relevant data. Moreover, they know their users and have a trust relationship with them, sort of. > So please change the topic to report spam actively where possible. And > perhaps even add that if there is no spam reporting centre in a > country, to lobby to your local government to start one. IMHO, mailbox providers should be the first recipients of naive users' reports. Gov's agencies already pester ISPs whenever they miss any grip for controlling the Internet. Why shouldn't they arrange to get spam complaints from cooperating mailbox providers? >> Message: 2 >> From: "Joe St Sauver" >> >> I'd like to suggest that users report spam to appropriate government >> agencies, see for example: >> http://spamlinks.net/track-report-addresses.htm#country Some of those links lead to 404 failures. Some are bare email addresses whose owners are probably unaware of that publication. From vesely at tana.it Tue Dec 13 20:24:28 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 13 Dec 2011 20:24:28 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: <4EE7397F.4020908@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <4EE7397F.4020908@ripe.net> Message-ID: <4EE7A66C.9050208@tana.it> On 13/Dec/11 12:39, Laura Cobley wrote: > > We are working on improving the procedures and documentation in the > area of reporting abuse. As part of this work, we have already > rewritten the FAQs currently being discussed on this list. > > We will inform you as soon as the revised FAQs are published. Thank you so much! It is quite curious that this WG shouldn't able to suggest an adequate wording... From joe at oregon.uoregon.edu Tue Dec 13 21:26:19 2011 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Tue, 13 Dec 2011 12:26:19 -0800 (PST) Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) Message-ID: <11121312261942_378E@oregon.uoregon.edu> Shane commented: #What a great method for finding networks that are poorly monitored and #maintained! Simply check ARIN's Whois database until you find networks #with POC that are marked as invalid! # #I hope that RIPE does not adopt this address-hijacking-friendly #technique. :( If I were a person inclined toward hijacking netblocks, I think I'd likely use data from Routeviews (or a similar routing table analysis project) to identify IP address ranges that consistently are absent from the global routing table. You could certainly use whois database queries in an effort to verify or validate potential target IP address ranges, but I don't really see stale data flags in whois as materially worsening the existing problem of abusers scavening apparently unused (or underused) network resources. After all, if a bad guy or bad gal sees a "juicy" likely-"abandoned" /16 or whatever, it really isn't that hard for them to try emailing the points of contact, or to try calling the listed phone POCs, etc. If the goal is to seriously deter address hijacking, I think we need to talk about things like RPKI (folks who may be interested may want to see Bush and Austein's NANOG RPKI Tutorial from June 2011, http://www.nanog.org/meetings/nanog52/abstracts.php?pt=MTc3MyZuYW5vZzUy&nm=nanog52 or for those who find URL shorteners more convenient, try http://tinyurl.com/rpki-tutorial for that same page). Or, if you're skeptical of RPKI, encourage your friends to carefully monitor their space and how it's being announced. But I digress :-; Regards, Joe From ops.lists at gmail.com Wed Dec 14 02:47:37 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Dec 2011 07:17:37 +0530 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <11121312261942_378E@oregon.uoregon.edu> References: <11121312261942_378E@oregon.uoregon.edu> Message-ID: I fully agree with Joe here. Trying to hide this in the whois is not much more than a figleaf. The route registries aren't very heavily used at all (not even by providers like swisscom who prefer to filter on minimum allocation size rather than prefixes registered in route registries, but that's another can of worms) :) There are plenty of other places for malicious actors to hijack old IP space, register shell companies (yeah yeah you're not the document police) . etc. So - hiding stuff from the whois is just not going to cut it as much as RIRs fixign their process, and SPs adopting best practices. --srs On Wed, Dec 14, 2011 at 1:56 AM, Joe St Sauver wrote: > Shane commented: > > #What a great method for finding networks that are poorly monitored and > #maintained! Simply check ARIN's Whois database until you find networks > #with POC that are marked as invalid! > # > #I hope that RIPE does not adopt this address-hijacking-friendly > #technique. :( > > If I were a person inclined toward hijacking netblocks, I think I'd > likely use data from Routeviews (or a similar routing table analysis > project) to identify IP address ranges that consistently are absent > from the global routing table. You could certainly use whois database > queries in an effort to verify or validate potential target IP address > ranges, but I don't really see stale data flags in whois as materially > worsening the existing problem of abusers scavening apparently unused > (or underused) network resources. After all, if a bad guy or bad gal > sees a "juicy" likely-"abandoned" /16 or whatever, it really isn't that > hard for them to try emailing the points of contact, or to try calling > the listed phone POCs, etc. > > If the goal is to seriously deter address hijacking, I think we need to > talk about things like RPKI (folks who may be interested may want to > see Bush and Austein's NANOG RPKI Tutorial from June 2011, > http://www.nanog.org/meetings/nanog52/abstracts.php?pt=MTc3MyZuYW5vZzUy&nm=nanog52 > or for those who find URL shorteners more convenient, try > http://tinyurl.com/rpki-tutorial for that same page). > > Or, if you're skeptical of RPKI, encourage your friends to carefully > monitor their space and how it's being announced. But I digress :-; > > Regards, > > Joe > -- Suresh Ramasubramanian (ops.lists at gmail.com) From shane at time-travellers.org Wed Dec 14 09:34:23 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 14 Dec 2011 09:34:23 +0100 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: References: <11121312261942_378E@oregon.uoregon.edu> Message-ID: <1323851664.2495.11.camel@shane-desktop> Suresh, On Wed, 2011-12-14 at 07:17 +0530, Suresh Ramasubramanian wrote: > So - hiding stuff from the whois is just not going to cut it as much > as RIRs fixign their process, and SPs adopting best practices. To be clear, I'm not advocating hiding things in the Whois, I just don't see any value in spending resources to find unresponsive contacts if the only point is to label them in the Whois. I guess when you are trying to report a problem it can save the effort of sending an e-mail if the address has no contact. But I figure that most reporting is automated at least a little, so overall the actual efficiency gained is minimal. Now if there was some actual implications about the resource - which to be honest, means revoking the allocation - then it would make sense. The problem is, others have pointed out, making a requirement to have an abuse e-mail role that replies to messages is such a low bar it actually has no real value. But maybe others think that forcing address holders to set up an e-mail autoresponder is worthwhile? -- Shane From ops.lists at gmail.com Wed Dec 14 10:41:59 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Dec 2011 15:11:59 +0530 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <1323851664.2495.11.camel@shane-desktop> References: <11121312261942_378E@oregon.uoregon.edu> <1323851664.2495.11.camel@shane-desktop> Message-ID: On Wed, Dec 14, 2011 at 2:04 PM, Shane Kerr wrote: > To be clear, I'm not advocating hiding things in the Whois, I just don't > see any value in spending resources to find unresponsive contacts if the > only point is to label them in the Whois. I guess when you are trying to > report a problem it can save the effort of sending an e-mail if the But this effort was, I thought, aimed at identifying defunct entities that still hold IP space and attempt to reclaim it? --srs From shane at time-travellers.org Wed Dec 14 10:43:51 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 14 Dec 2011 10:43:51 +0100 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: References: <11121312261942_378E@oregon.uoregon.edu> <1323851664.2495.11.camel@shane-desktop> Message-ID: <1323855832.2495.17.camel@shane-desktop> On Wed, 2011-12-14 at 15:11 +0530, Suresh Ramasubramanian wrote: > On Wed, Dec 14, 2011 at 2:04 PM, Shane Kerr wrote: > > To be clear, I'm not advocating hiding things in the Whois, I just don't > > see any value in spending resources to find unresponsive contacts if the > > only point is to label them in the Whois. I guess when you are trying to > > report a problem it can save the effort of sending an e-mail if the > > But this effort was, I thought, aimed at identifying defunct entities > that still hold IP space and attempt to reclaim it? I think that the ARIN policy only mandates that unresponsive contacts be clearly identified, and no further actions are taken. -- Shane From ops.lists at gmail.com Wed Dec 14 10:54:33 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 Dec 2011 15:24:33 +0530 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <1323855832.2495.17.camel@shane-desktop> References: <11121312261942_378E@oregon.uoregon.edu> <1323851664.2495.11.camel@shane-desktop> <1323855832.2495.17.camel@shane-desktop> Message-ID: On Wed, Dec 14, 2011 at 3:13 PM, Shane Kerr wrote: > I think that the ARIN policy only mandates that unresponsive contacts be > clearly identified, and no further actions are taken. And this makes future efforts in the right direction easier, I expect. It also deters hijacking to some extent. -- Suresh Ramasubramanian (ops.lists at gmail.com) From tk at abusix.com Wed Dec 14 11:28:54 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 14 Dec 2011 11:28:54 +0100 Subject: [anti-abuse-wg] How to find abandoned networks (was Spam FAQs need revision) In-Reply-To: <1323855832.2495.17.camel@shane-desktop> References: <11121312261942_378E@oregon.uoregon.edu> <1323851664.2495.11.camel@shane-desktop> <1323855832.2495.17.camel@shane-desktop> Message-ID: <4EE87A66.2010108@abusix.com> Am 14.12.11 10:43, schrieb Shane Kerr: > On Wed, 2011-12-14 at 15:11 +0530, Suresh Ramasubramanian wrote: >> On Wed, Dec 14, 2011 at 2:04 PM, Shane Kerr wrote: >>> To be clear, I'm not advocating hiding things in the Whois, I just don't >>> see any value in spending resources to find unresponsive contacts if the >>> only point is to label them in the Whois. I guess when you are trying to >>> report a problem it can save the effort of sending an e-mail if the >> >> But this effort was, I thought, aimed at identifying defunct entities >> that still hold IP space and attempt to reclaim it? > > I think that the ARIN policy only mandates that unresponsive contacts be > clearly identified, and no further actions are taken. If that is the case, that there is no other action than publishing the information in whois it is imho not enough. RIPE NCC already has processes in place that contact maintainers and try to solve the open issues together. If that does not work deregistration processes can be started. This in addition with the annual process is imho a pretty good way to increase data accuracy in the database. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From russ at consumer.net Thu Dec 15 13:28:32 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 07:28:32 -0500 Subject: [anti-abuse-wg] whois access Message-ID: <4EE9E7F0.7080905@consumer.net> Hi. I am a problem with RIPE mis-applying it anti-abuse procedures for the RIPE database. I have operated Network-Tools.com for 13 years. The site is often used by people tracing spam or other security issues that includes IP address block lookups so people can send in a complaint or otherwise contact the network they have an issue with. I find my web site is suddenly blocked from accessing the RIPE database and I cannot get answers to my questions from contacting the database administrator or IANA. First - I am being accused of wanting "bulk access" to the database. That is not true. My system is a pass-through system where many different people make requests through network-tools.com. The web site is merely a pass-through. I have asked many times how I can pass the requestor's IP address through so my web site won't be "penalized." I never get an answer from RIPE. ARIN told me they don't support such a scheme. One purpose of the whois is so that individuals can contact abuse contacts, verfify who owns address blocks, etc. so blocking pass-through systems thwarts the whole purpose of the RIPE database. Second- RIPE keeps claims the requests are for "personal information." IP address and abuse contacts are business contacts and role accounts meant for the public. this is nor "personal information" (ARIN calls it "sensitive" data). These are business contacts meant for the public, not "personal information" or "sensitive." If if were "sensitive" it would not be available to the public. In any case I do not want to display sensitive data or personal information, I want to display the abuse contacts. As for blocking IP from accessing the database I do not see the purpose anyway. Most harvesters use a distributed system of IP addresses so blocking IP only serves to disrupt pass-through systems doing legitimate tasks while harvesters continue to freely collect their data. For the most part the only thing it does is disrupt legitimate users and cause expense to those users for no purpose. How can I get answers to these questions? Thank you From michele at blacknight.ie Thu Dec 15 14:48:38 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 15 Dec 2011 13:48:38 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EE9E7F0.7080905@consumer.net> References: <4EE9E7F0.7080905@consumer.net> Message-ID: <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> On 15 Dec 2011, at 12:28, russ at consumer.net wrote: > Hi. I am a problem with RIPE mis-applying it anti-abuse procedures for the RIPE database. > > I have operated Network-Tools.com for 13 years. The site is often used by people tracing spam or other security issues that includes IP address block lookups so people can send in a complaint or otherwise contact the network they have an issue with. I find my web site is suddenly blocked from accessing the RIPE database and I cannot get answers to my questions from contacting the database administrator or IANA. > > First - I am being accused of wanting "bulk access" to the database. That is not true. Yes it is. You want bulk access. > My system is a pass-through system where many different people make requests through network-tools.com. The web site is merely a pass-through. It's irrelevant that you think your site is a "pass through" as you haven't coded your requests in such a manner as to pass the requesting IP over. > I have asked many times how I can pass the requestor's IP address through so my web site won't be "penalized." I never get an answer from RIPE. ARIN told me they don't support such a scheme. One purpose of the whois is so that individuals can contact abuse contacts, verfify who owns address blocks, etc. so blocking pass-through systems thwarts the whole purpose of the RIPE database. No it doesn't Someone can go to the RIPE or ARIN website and request the information for free. > > Second- RIPE keeps claims the requests are for "personal information." IP address and abuse contacts are business contacts and role accounts meant for the public. this is nor "personal information" (ARIN calls it "sensitive" data). These are business contacts meant for the public, not "personal information" or "sensitive." If if were "sensitive" it would not be available to the public. > In any case I do not want to display sensitive data or personal information, I want to display the abuse contacts. > > As for blocking IP from accessing the database I do not see the purpose anyway. Most harvesters use a distributed system of IP addresses so blocking IP only serves to disrupt pass-through systems doing legitimate tasks while harvesters continue to freely collect their data. For the most part the only thing it does is disrupt legitimate users and cause expense to those users for no purpose. > > How can I get answers to these questions? > > Thank you > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From thor.kottelin at turvasana.com Thu Dec 15 14:51:50 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Thu, 15 Dec 2011 15:51:50 +0200 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EE9E7F0.7080905@consumer.net> References: <4EE9E7F0.7080905@consumer.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of russ at consumer.net > Sent: Thursday, December 15, 2011 2:29 PM > To: anti-abuse-wg at ripe.net > I am being accused of wanting "bulk access" to the > database. > That is not true. My system is a pass-through system where many > different people make requests through network-tools.com. The web > site > is merely a pass-through. I would also describe your usage as bulk access. Can you not apply for such access? I have, and the RIPE NCC was most helpful. > RIPE keeps claims the requests are for "personal > information." > IP address and abuse contacts are business contacts and role > accounts > meant for the public. this is nor "personal information" Directive 95/46/EC defines 'personal data' as 'any information relating to an identified or identifiable natural person ("data subject"); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity'. In other words, my email address in the RIPE database is personal data because it relates to a natural person, even though it is being published for business purposes. -- Thor Kottelin http://www.anta.net/ From fweimer at bfk.de Thu Dec 15 14:54:17 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 15 Dec 2011 13:54:17 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EE9E7F0.7080905@consumer.net> (russ@consumer.net's message of "Thu, 15 Dec 2011 07:28:32 -0500") References: <4EE9E7F0.7080905@consumer.net> Message-ID: <82obva3ppy.fsf@mid.bfk.de> > Second- RIPE keeps claims the requests are for "personal information." > IP address and abuse contacts are business contacts and role accounts > meant for the public. In the RIPE database, the abuse contact information is not attached to resource objects, but to person (and role) objects, which are referenced from resource objects. This is a design flaw, and there are proposals currently under discussion to work around it. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From russ at consumer.net Thu Dec 15 17:42:14 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 11:42:14 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> Message-ID: <4EEA2366.8050101@consumer.net> Thanks for all the replies. As for passing through the IP of the requesters of the whois records I have asked about this several times. ARIN told me they don't support it and RIPE won't answer my inquiries. Are there standards for that or any other information about setting up some sort of ip address pass-through or proxy for whois queries for the RIR's? As I understand it the fact that the abuse contact is not associated with the object record is a design flaw. It seems to me this matter should have been dealt with before the RIPE blocking initiatives. The definition of "personal data" in Directive 95/46/EC is not really useful when you talk about protection of the data. This definition groups information that is mandated by law to be public with truly private or sensitive data. For instance, company "Example.com" has an e-mail address "president at example.com." The company is legally required to file documents declaring who their president is and make that publicly available so the address "president at example.com" falls under this definition. Now if you have his private cell phone number that is also "personal data" but it is not mandated to be public information. The cell phone number deserves a high level of protection while but the e-mail address does not so treating them the same is not useful. In any case I have no desire to access persoanl contacts or other data other than contact information meant for public consumption. If I understand things correctly the so-called "bulk access" option is using a "-r" which would not display the abuse contact. Since getting the abuse contacts is often the main purpose of the query this does not seem to be viable option. In actuality I am not requesting "bulk access" and I don't save any of the data myself. My system is a pass-though where the users get the data and I package the data with other functions. It may appear as if it is bulk access because it all comes from a single IP but it is not. The same thing happened with ARIN several years ago. Once I showed them the web site they agreed that is was a pass-through system and removed the block. Now we have a situation where different RIR's have different policies for the same type of whois requests. In my case I use a commercial whois component from hexillion.com and i cannot go in and change the queries just to RIPE without going back to the software vendor or completely reprogramming my site. I have plans to do that anyway but I cannot do it overnight or during the Christmas season because someone at RIPE woke up one day after 13 years and decided to block my site. One purpose of the database is to provide access to the public for IP address allocations. While it is true people can visit the RIPE database themselves it is not practical (the person suggesting this has ads in his signature for a business that combines several services people could get on their own). As I see it the problem lies with ICANN/IANA. They are contractually obligated with the US Department of Commerce to "ensure the authentication, integrity, and reliability of the data in performing the IANA requirements, including the data relevant to DNS, root zone file, and IP address allocation." Obviously there should a single WHOIS interface with standard policies and procedures for accessing it and not this hodgepodge system where users of the data have to deal with each RIR separately. The funny part about this whole thing is that I contacted a busines that provides whois services (they are not a spammer or harvester). One of the first things they told me was that they use a distributed IP address system for requests to avoid the blocking. the current policy forces legitimate business to use hacking techniques to access data that is supposed to publicly variable. The current IP address blocking scheme has no practical purpose other than preventing DOS attacks. Harvesters continue collected data using distributed IP's while small sites like mine suffer and possibly get run out of business. The impression I have is that the people doing the blocking have no concern whatsoever about the collateral damage they are casing or the fact that their actions have little or no purpose. Then if someone complains they are often ignored or ridiculed. Thank You From niall at blacknight.com Thu Dec 15 18:16:42 2011 From: niall at blacknight.com (Niall Donegan) Date: Thu, 15 Dec 2011 17:16:42 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA2366.8050101@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> Message-ID: <4EEA2B7A.4090902@blacknight.com> On 15/12/11 16:42, russ at consumer.net wrote: > As for passing through the IP of the requesters of the whois records I > have asked about this several times. ARIN told me they don't support > it and RIPE won't answer my inquiries. Are there standards for that > or any other information about setting up some sort of ip address > pass-through or proxy for whois queries for the RIR's? That's because whois is one of the simplest protocols there is. For example, to get the details for 192.0.2.1, just telnet into port 43 of whois.ripe.net. As soon as the disclaimer comes up, type "192.0.2.1" followed by enter, and you get the results. Why would you want to mess up as simple a protocol as that with something like the X-Forwarded-For header in HTTP? RIPE can only see the IP you're connecting from, and it's doing a lot more traffic than a normal IP. If you have a legit need, they can and will give you bulk access for that ip. Niall. -- Niall Donegan ---------------- http://www.blacknight.com Blacknight Internet Solutions Ltd, Unit 12A, Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From michele at blacknight.ie Thu Dec 15 19:02:41 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 15 Dec 2011 18:02:41 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA2366.8050101@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> Message-ID: <658D846C-6903-4DBC-B2E8-21F821F25E56@blacknight.ie> On 15 Dec 2011, at 16:42, russ at consumer.net wrote: > Thanks for all the replies. > > As for passing through the IP of the requesters of the whois records I have asked about this several times. ARIN told me they don't support it and RIPE won't answer my inquiries. Are there standards for that or any other information about setting up some sort of ip address pass-through or proxy for whois queries for the RIR's? You want bulk access. Stop pretending that you don't > > As I understand it the fact that the abuse contact is not associated with the object record is a design flaw. It seems to me this matter should have been dealt with before the RIPE blocking initiatives. Why? Because it puts you out? > > The definition of "personal data" in Directive 95/46/EC is not really useful when you talk about protection of the data. It's European law. Saying it's "not really useful" won't change that > This definition groups information that is mandated by law to be public with truly private or sensitive data. For instance, company "Example.com" has an e-mail address "president at example.com." The company is legally required to file documents declaring who their president is and make that publicly available so the address "president at example.com" falls under this definition. Now if you have his private cell phone number that is also "personal data" but it is not mandated to be public information. The cell phone number deserves a high level of protection while but the e-mail address does not so treating them the same is not useful. In any case I have no desire to access persoanl contacts or other data other than contact information meant for public consumption. > > If I understand things correctly the so-called "bulk access" option is using a "-r" which would not display the abuse contact. Since getting the abuse contacts is often the main purpose of the query this does not seem to be viable option. In actuality I am not requesting "bulk access" and I don't save any of the data myself. My system is a pass-though where the users get the data and I package the data with other functions. It may appear as if it is bulk access because it all comes from a single IP but it is not. The same thing happened with ARIN several years ago. Once I showed them the web site they agreed that is was a pass-through system and removed the block. Now we have a situation where different RIR's have different policies for the same type of whois requests. In my case I use a commercial whois component from hexillion.com and i cannot go in and change the queries just to RIPE without going back to the software vendor or completely reprogramming my site. I have plans to do that anyway but I cannot do it overnight or during the Christmas season because someone at RIPE woke up one day after 13 years and decided to block my site. > > One purpose of the database is to provide access to the public for IP address allocations. While it is true people can visit the RIPE database themselves it is not practical Practical according to who? > (the person suggesting this has ads in his signature for a business that combines several services people could get on their own). I assume that was aimed at me? If it was why don't you just say so instead of trying to be "clever" ? > > As I see it the problem lies with ICANN/IANA. They are contractually obligated with the US Department of Commerce to "ensure the authentication, integrity, and reliability of the data in performing the IANA requirements, including the data relevant to DNS, root zone file, and IP address allocation." Obviously there should a single WHOIS interface with standard policies and procedures for accessing it and not this hodgepodge system where users of the data have to deal with each RIR separately. IPs in the RIPE region are clearly delegated to RIPE by IANA. IANA has completed its function. > > The funny part about this whole thing is that I contacted a busines that provides whois services (they are not a spammer or harvester). Who? The only companies I know of that provider "whois services" are doing so by harvesting data from other people's systems. > One of the first things they told me was that they use a distributed IP address system for requests to avoid the blocking. Which tells me that what they're harvesting. If their usage was "legitimate" then they would be able to get whitelisted > the current policy forces legitimate business to use hacking techniques to access data that is supposed to publicly variable. The current IP address blocking scheme has no practical purpose other than preventing DOS attacks. Harvesters continue collected data using distributed IP's while small sites like mine suffer and possibly get run out of business. So you want to make money out of our data? And you're upset that EU law and RIPE's policies slows you down? > The impression I have is that the people doing the blocking have no concern whatsoever about the collateral damage they are casing or the fact that their actions have little or no purpose. Then if someone complains they are often ignored or ridiculed. > > Thank You > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From russ at consumer.net Thu Dec 15 19:04:22 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 13:04:22 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA2B7A.4090902@blacknight.com> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> Message-ID: <4EEA36A6.3000001@consumer.net> I don't want to change anything, I just want to get my site unblocked from RIPE. ARIN has agreed that I have a legit need and has removed all blocks. After 13 years RIPE suddenly blocked me and will not remove the block no matter what explanation I give and they won't answer my questions. They just tell me I have to change my queries to include a "-r" I am in contact with the software vendor and I am trying to get something done but I had no prior notice. I am getting complaints and the following I have built up over 13 years is being lost. Even if I can include the "-r" the abuse contact will no longer show up and people are going to leave my site anyway. This is a major disaster for me and I cannot get any of my questions answered from RIPE or ICANN/IANA. They couldn't care less. >> As for passing through the IP of the requesters of the whois records I >> have asked about this several times. ARIN told me they don't support >> it and RIPE won't answer my inquiries. Are there standards for that >> or any other information about setting up some sort of ip address >> pass-through or proxy for whois queries for the RIR's? > That's because whois is one of the simplest protocols there is. For > example, to get the details for 192.0.2.1, just telnet into port 43 of > whois.ripe.net. As soon as the disclaimer comes up, type "192.0.2.1" > followed by enter, and you get the results. > > Why would you want to mess up as simple a protocol as that with > something like the X-Forwarded-For header in HTTP? > > RIPE can only see the IP you're connecting from, and it's doing a lot > more traffic than a normal IP. If you have a legit need, they can and > will give you bulk access for that ip. > > Niall. > > From russ at consumer.net Thu Dec 15 19:41:59 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 13:41:59 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <658D846C-6903-4DBC-B2E8-21F821F25E56@blacknight.ie> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <658D846C-6903-4DBC-B2E8-21F821F25E56@blacknight.ie> Message-ID: <4EEA3F77.1080603@consumer.net> >So you want to make money out of our data? And you're upset that EU law and RIPE's policies slows you down? > Mr Michele Neylon Blacknight Solutions You may not like the response (I would not like it if I were outside the US) but the data is bought and paid for by the US taxpayer. IANA is done via contract to the US Department of Commerce NTIA. I have filed a formal Freedom of Information Act under US law requesting access since it appears to me the US Government owns the data. US Taxpayers are paying ICANN/IANA to standardize this data and ensure stuff like this does not happen. ARIN (and all the RIR's) should be under the same requirements and should supply data to other countries as well. It is an issue of supplying an Internet function to all users not an "our data" vs. "their data" issue. But, yes, I want to continue to make money off the data. Just like your business wants to continue make money off the fact that domain registration was changed from a one-company monopoly to a distributed competitive system so that companies like your can combine domain registration and web hosting. Since most of the Internet was developed in the US by the US government (not to say there weren't significant contributions elsewhere) an argument could be made the rest of the world is profiting off USA data. But I see nothing wrong with that. The more people involved in commerce, competition, and making money off the Internet the better it will be and more and better services will be offered. But none of your customers actually need to register a domain through you, they can all the US based Network Solutions. I bet before competition is they blocked your company from registering domains I expect you would have had a fit. As it is you are profiting from a US-developed system. I have no problem when data laws are applied correctly. The situation we have here is that you have data that is mandated to be public while, at the same time, there are claims it needs to be protected. You can't do both, either it is public or protected. On top of that we have methods that claim to protect the data that do no such thing and it is costing me money and inconveniencing Internet users and serves no real purpose. Thank you From thor.kottelin at turvasana.com Thu Dec 15 20:55:17 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Thu, 15 Dec 2011 21:55:17 +0200 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA3F77.1080603@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <658D846C-6903-4DBC-B2E8-21F821F25E56@blacknight.ie> <4EEA3F77.1080603@consumer.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of russ at consumer.net > Sent: Thursday, December 15, 2011 8:42 PM > Cc: anti-abuse-wg at ripe.net > >So you want to make money out of our data? And you're upset that > EU > law and RIPE's policies slows you down? > > Mr Michele Neylon Blacknight Solutions > > You may not like the response (I would not like it if I were > outside the > US) but the data is bought and paid for by the US taxpayer. The RIPE database is maintained by the RIPE NCC, and to the best of my knowledge, the RIPE-specific (non-mirrored) contents of the database have been contributed, update by update, by the RIPE NCC and the RIPE community. I totally fail to see how e.g. my person object would have been 'bought and paid for by the US taxpayer'. > But, yes, I want to continue to make money off the data. Just like > your > business wants to continue make money off the fact that domain > registration was changed from a one-company monopoly to a > distributed > competitive system so that companies like your can combine domain > registration and web hosting. I have no problem with that. If you can provide added value that attracts customers, more power to you. I believe many other players, including US-based ones, quite successfully use RIPE database contents for purposes similar to yours. -- Thor Kottelin http://www.anta.net/ From Woeber at CC.UniVie.ac.at Thu Dec 15 21:27:17 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 15 Dec 2011 20:27:17 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA36A6.3000001@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> Message-ID: <4EEA5825.90308@CC.UniVie.ac.at> russ at consumer.net wrote: > I don't want to change anything, ...so I could stop reading? > I just want to get my site unblocked > from RIPE. ARIN has agreed that I have a legit need and has removed all > blocks. Fine, I'm sure ARIN had good reasons to act as they did, either favourably to your interests, or not, it simply doesn't matter in the RIPE Region. > After 13 years RIPE suddenly blocked me Sorry, the bulk access/harvesting prevention mechanisms have been in place for a *very* long time. So, I guess the "suddenly" is more likely to be related to a change in your query pattern and/or frequency, than to a change in the mechanisms. > and will not remove the > block no matter what explanation I give and they won't answer my > questions. Although I am not a native speaker, I think you are contradicting yourself within a single sentence? > They just tell me I have to change my queries to include a > "-r" I am in contact with the software vendor and I am trying to get > something done but I had no prior notice. I am getting complaints and > the following I have built up over 13 years is being lost. Even if I > can include the "-r" the abuse contact will no longer show up and people > are going to leave my site anyway. This is a major disaster for me and > I cannot get any of my questions answered from RIPE or ICANN/IANA. They > couldn't care less. Well - although this is formally outside the topic of discussion - looking at your style, approach and choice of words, I am not overly surprised... >>> As for passing through the IP of the requesters of the whois records I >>> have asked about this several times. ARIN told me they don't support >>> it and RIPE won't answer my inquiries. Are there standards for that >>> or any other information about setting up some sort of ip address >>> pass-through or proxy for whois queries for the RIR's? For the full set of 5 RIRs? My educated geuss would be: NO. >> That's because whois is one of the simplest protocols there is. For >> example, to get the details for 192.0.2.1, just telnet into port 43 of >> whois.ripe.net. As soon as the disclaimer comes up, type "192.0.2.1" >> followed by enter, and you get the results. >> >> Why would you want to mess up as simple a protocol as that with >> something like the X-Forwarded-For header in HTTP? >> >> RIPE can only see the IP you're connecting from, and it's doing a lot >> more traffic than a normal IP. If you have a legit need, they can and >> will give you bulk access for that ip. >> >> Niall. Wilfried. PS: and even I ( :-) ), or rather the lab where I am doing teaching this stuff, get blocked when we activate the triggers, for one reason or another. And that's how it is meant to work :-) PPS: regarding your contacts to entities "cleverly" circumventing the bulk access prevcention mechanisms, we'd be interested to get those leads, because there's a good chance that these parties are violating the "RIPE Database Terms and Conditions", aka AUP and need to be contacted. From russ at consumer.net Thu Dec 15 22:22:56 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 16:22:56 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA5825.90308@CC.UniVie.ac.at> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> Message-ID: <4EEA6530.7020308@consumer.net> > I'm sure ARIN had good reasons to act as they did, either favourably to your interests, or not, it simply doesn't matter in the RIPE Region. Why would you be sure of that and why wouldn't it matter? It seems to me that all internet users have a stake in seeing that the services are reliable in all regions. >Sorry, the bulk access/harvesting prevention mechanisms have been in place for a *very* long time. So, I guess the "suddenly" is more likely to be related to a change in your query pattern >and/or frequency, than to a change in the mechanisms. No, something has changed. They are claiming now there is some type of limit of 1000 queries per day. They have not blocked me in the past and the queries exceed that so something changed recently. >Well - although this is formally outside the topic of discussion - looking at your style, approach and choice of words, I am not overly surprised... So you are saying Internet policy should be based on an evaluation of a person's choice of style? In other words if you are not part of a small clique then you don't matter? Many system admins act like this and they think their anti-spam systems trumps every other need and they don't care how much damage is done. There are many people like this involved in Internet governance and it is a big problem because they don't balance the needs of different parties. these are the people that often ridicule anyone who brings up issues or ideas that goers against their view of the world from their limited experience. >PS: and even I ( :-) ), or rather the lab where I am doing teaching this stuff, get blocked when we activate the triggers, for one reason or another. And that's how it is meant to work :-) Yes. Then there is supposed to be a policy in place to make a determination of what is allowed and what is not. the problem is that ARIN says it is allowed but RIPE says it is not. It is apparentky common to all the commercial whois providers that they use a distributed system of IP's so I don't have any special knowledge or information. >I believe many other players, including US-based ones, quite successfully use RIPE database contents for purposes similar to yours. I was doing fine for 13 years until recently. Apparently the successful ones uses distributed IP's to avoid the blocking. >The RIPE database is maintained by the RIPE NCC, and to the best of my >knowledge, the RIPE-specific (non-mirrored) contents of the database have >been contributed, update by update, by the RIPE NCC and the RIPE community. >I totally fail to see how e.g. my person object would have been 'bought and >paid for by the US taxpayer'. I believe the data is under the ultimate control of the US Government based on the contract between the US and IANA. Here is an EC news release about it: http://europa.eu/rapid/pressReleasesAction.do?reference=IP/11/1345&format=HTML&aged=0&language=en&guiLanguage=en If someone has the contract between RIPE and IANA I would like to see that as well. It is interesting that nobody can explain why RIPE has one policy and ARIN has a different one. Also, nobody seems to agree that the services like whois need to be standardized across the Internet. Most shockingly nobody wants to address the fact that the IP address blocking does not do what it is intended to do. Most comments just assume RIPE must be right and that I must have done something wrong ... my stye is wrong and I present myself incorrectly, etc, etc. This is what happens when someone outside the closed community tries to bring issues to the table. The speaker is attacked and the issues are glossed over. It is interesting because I am usually on the other side of the privacy argument and I have testified before the US Federal Trade Commission arguing for greater privacy protection. thank you From Woeber at CC.UniVie.ac.at Thu Dec 15 23:31:48 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 15 Dec 2011 22:31:48 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA6530.7020308@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> Message-ID: <4EEA7554.303@CC.UniVie.ac.at> russ at consumer.net wrote: >> I'm sure ARIN had good reasons to act as they did, either favourably > to your interests, or not, it simply doesn't matter in the RIPE Region. > > Why would you be sure of that and why wouldn't it matter? Because the policies to distribute and manage the number resources provided by IANA to the RIRs are a regional matter. Policy delvelopment in this context, when and if, it relates to the operation of IANA is a global policy process. Even this process is a bootom-up process, not a top-down mehanism as you seem to believe. ARIN operates in the legal framework of the United States of America, the RIPE NCC operates in the legal framework of the European Union in general and Dutch Law in particular. It is a pretty well-known fact that the legal systems in those regions are not identical. Thus, imho, ARIN's approach to managing access to whois data is not directly relevant to this region - in the sense that an aproach by ARIN has automatically to be copied by other regions. > It seems to > me that all internet users have a stake in seeing that the services are > reliable in all regions. Agreed, totally, that's the reason why all the 5 RIRs do provide access to whois data for *users*, individually. >>Sorry, the bulk access/harvesting prevention mechanisms have been in > place for a *very* long time. So, I guess the "suddenly" is more likely > to be related to a change in your query pattern >and/or frequency, than > to a change in the mechanisms. > > No, something has changed. They are claiming now there is some type of > limit of 1000 queries per day. They have not blocked me in the past and > the queries exceed that so something changed recently. > >>Well - although this is formally outside the topic of discussion - > looking at your style, approach and choice of words, I am not overly > surprised... > > So you are saying Internet policy should be based on an evaluation of a > person's choice of style? No, what I am saying is that discussions regarding policy and discussions related to solving perceived problems SHOULD be conducted with respect to etiquette and mutual respect, rather than accusations. > In other words if you are not part of a small clique then you don't matter? Like in any community, you will certainly receive the appropriate attention. You are getting pretty much attention on this list already, isn't it? > Many system admins act like this and they > think their anti-spam systems trumps every other need and they don't > care how much damage is done. There are many people like this involved > in Internet governance and it is a big problem because they don't > balance the needs of different parties. these are the people that often > ridicule anyone who brings up issues or ideas that goers against their > view of the world from their limited experience. > >>PS: and even I ( :-) ), or rather the lab where I am doing teaching > this stuff, get blocked when we activate the triggers, for one reason or > another. And that's how it is meant to work :-) > > Yes. Then there is supposed to be a policy in place to make a > determination of what is allowed and what is not. the problem is that > ARIN says it is allowed but RIPE says it is not. Please see above why there may (or probably will) be differences in the regions. > It is apparentky > common to all the commercial whois providers that they use a distributed > system of IP's so I don't have any special knowledge or information. > >>I believe many other players, including US-based ones, quite > successfully use RIPE database contents for purposes similar to yours. > > I was doing fine for 13 years until recently. Apparently the successful > ones uses distributed IP's to avoid the blocking. > >> The RIPE database is maintained by the RIPE NCC, and to the best of my >> knowledge, the RIPE-specific (non-mirrored) contents of the database have >> been contributed, update by update, by the RIPE NCC and the RIPE >> community. >> I totally fail to see how e.g. my person object would have been >> 'bought and >> paid for by the US taxpayer'. > > > > I believe the data is under the ultimate control of the US Government Well, we keep hearing that generalized statement since quite a while, outside the US, and not limited to whois data :-) > based on the contract between the US and IANA. Here is an EC news > release about it: > http://europa.eu/rapid/pressReleasesAction.do?reference=IP/11/1345&format=HTML&aged=0&language=en&guiLanguage=en Thanks for providing this URL. Alas, I do not see any indication in this text that would support your interpretation. > If someone has the contract between RIPE and IANA I would like to see > that as well. To my knowledge, such a contract does not exist, but I may be wrong! However, there is an MoU in place, between ICANN and the NRO (the collective of the five RIRs) > It is interesting that nobody can explain why RIPE has one policy and > ARIN has a different one. I tried to do that above, to summarize: - different legal environment - different communities - regional policies apply > Also, nobody seems to agree that the services > like whois need to be standardized across the Internet. I do know quite a few parties which do share that view. I also know quit a few others which do not agree, for various reasons. > Most shockingly > nobody wants to address the fact that the IP address blocking does not > do what it is intended to do. I presume most people who get in contact with that do not see a problem. > Most comments just assume RIPE must be > right and that I must have done something wrong ... my stye is wrong and > I present myself incorrectly, etc, etc. This is what happens when > someone outside the closed community tries to bring issues to the > table. The speaker is attacked and the issues are glossed over. It is > interesting because I am usually on the other side of the privacy > argument and I have testified before the US Federal Trade Commission > arguing for greater privacy protection. > > thank you Best regards, Wilfried. From russ at consumer.net Fri Dec 16 00:05:58 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 18:05:58 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA7554.303@CC.UniVie.ac.at> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> Message-ID: <4EEA7D56.6060501@consumer.net> >Because the policies to distribute and manage the number resources provided by IANA to the RIRs are a regional matter. Yes, I would agree some things are a regional matter and should be handled regionally, in fact as much as possible. However, access to the whois abuse data should not be. The reason is that the purpose of this is to contact the administrator of ip blocks to notify them of issues. If someone is tracing an IP and they can get the data for some IP's and not others then I see a lack of standardization as a problem. I think the whole issue comes down to this. It is not possible to control how public information is used. people don't want to accept that fact that it can't be done so they come up with schemes to make it look like they are doing something, like IP address blocking. Then they get so focused on pursuing their IP address blocking policy that they lose sight of the fact that IP address blocking does essentially nothing to control the spam that is the core issue. There is a big mantra to stop "harvesting" when, in actuality, there is nothing illegal about harvesting publicly available information or Google would have been shut down long ago. Since there is no real basis for blocking access to public information this new argument has arisen where information is now mandated to be public yet is also protected and sensitive under privacy laws. None of this makes the slightest amount of sense to me. I do not believe blocking my network-tools.com is not going to affect the amount of spam sent to RIPE database contacts. This is the real issue here. My whois contacts for domains is in the Tucows whois. This is protected by IP address blocks, CAPCHA, etc. yet I get spam all the time, these measures do no good. I just change my address every few months. Maybe the RIR's should set up system like whois privacy where the published addresses are all under RIPE.net domain and forwarded to hidden addresses. The public RIPE.net e-mail addresses could also change periodically. That way you have no privacy issue and the addresses "time out" so harvesting for future use is useless. thank you. From russ at consumer.net Fri Dec 16 02:23:05 2011 From: russ at consumer.net (russ at consumer.net) Date: Thu, 15 Dec 2011 20:23:05 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA7D56.6060501@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> Message-ID: <4EEA9D79.6050403@consumer.net> I looked over the MOU for the RIR's and these seem to be the relevant clauses to whois data access: "The ICANN bylaws assign to the ASO the responsibility for the development of global policies relating to the following areas: Definition of global policies for the distribution and registration of Internet address space (currently IPv4 and IPv6);... Specifically this responsibility is limited to the above and does not extend to the business practices or local policies of the RIRs except as needed to ensure that the RIRs meet the criteria for ICANN approved RIRs. The RIRs are responsible to their own members and in most cases this must be their prime responsibility." ICANN/IANA has a responsibility under the US government contract: "The Contractor shall ensure the authentication, integrity, and reliability of the data in performing the IANA requirements, including the data relevant to DNS, root zone file, and IP address allocation." From ripe-anti-spam-wg at powerweb.de Fri Dec 16 09:55:12 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Fri, 16 Dec 2011 09:55:12 +0100 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEA7D56.6060501@consumer.net> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> Message-ID: <4EEB0770.4050205@powerweb.de> russ at consumer.net wrote: > >Because the policies to distribute and manage the number resources > > Maybe the RIR's should set up system like whois privacy where the > published addresses are all under RIPE.net domain and forwarded to > hidden addresses. The public RIPE.net e-mail addresses could also change > periodically. That way you have no privacy issue and the addresses "time > out" so harvesting for future use is useless. Thats what I already liked to discuss a year ago on this list, without big response. There defny should be a system like this to hide all personal email addresses from all kind of harvesting, simply because its personal data and RIPE NCC has no reason to give it to other people and it needs to be protected much better (at least according to German law). Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From ops.lists at gmail.com Fri Dec 16 10:07:54 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 16 Dec 2011 14:37:54 +0530 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEB0770.4050205@powerweb.de> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> <4EEB0770.4050205@powerweb.de> Message-ID: <30CAB55D-5C9C-423B-BEFA-DA5882B6DD52@gmail.com> thank god ripe is not located in germany --srs (iPad) On 16-Dec-2011, at 14:25, Frank Gadegast wrote: > russ at consumer.net wrote: >> >Because the policies to distribute and manage the number resources >> >> Maybe the RIR's should set up system like whois privacy where the >> published addresses are all under RIPE.net domain and forwarded to >> hidden addresses. The public RIPE.net e-mail addresses could also change >> periodically. That way you have no privacy issue and the addresses "time >> out" so harvesting for future use is useless. > > Thats what I already liked to discuss a year ago on this list, > without big response. > > There defny should be a system like this to hide all personal > email addresses from all kind of harvesting, simply because > its personal data and RIPE NCC has no reason to give it to > other people and it needs to be protected much better > (at least according to German law). > > > Kind regards, Frank > -- > PHADE Software - PowerWeb http://www.powerweb.de > Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de > Schinkelstrasse 17 fon: +49 33200 52920 > 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 > ====================================================================== > Public PGP Key available for frank at powerweb.de > > From fweimer at bfk.de Fri Dec 16 10:43:53 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 16 Dec 2011 09:43:53 +0000 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEB0770.4050205@powerweb.de> (Frank Gadegast's message of "Fri, 16 Dec 2011 09:55:12 +0100") References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> <4EEB0770.4050205@powerweb.de> Message-ID: <82ty50yhpi.fsf@mid.bfk.de> * Frank Gadegast: > There defny should be a system like this to hide all personal > email addresses from all kind of harvesting, simply because > its personal data and RIPE NCC has no reason to give it to > other people and it needs to be protected much better > (at least according to German law). Surely there are exceptions. Obviously, RIPE NCC should continue to operate mailing lists. Your proposal would prevent RIPE NCC from doing that. Come to think of it, from a privacy point of view, I don't see much of a difference between submitting a mail message to RIPE NCC for publication and distribution over a mailing list, and a person: object for publication and distribution using the RIPE database. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ripe-anti-spam-wg at powerweb.de Fri Dec 16 11:00:02 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Fri, 16 Dec 2011 11:00:02 +0100 Subject: [anti-abuse-wg] whois access In-Reply-To: <82ty50yhpi.fsf@mid.bfk.de> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> <4EEB0770.4050205@powerweb.de> <82ty50yhpi.fsf@mid.bfk.de> Message-ID: <4EEB16A2.50404@powerweb.de> Florian Weimer wrote: > * Frank Gadegast: > Hi Florian, >> There defny should be a system like this to hide all personal >> email addresses from all kind of harvesting, simply because >> its personal data and RIPE NCC has no reason to give it to >> other people and it needs to be protected much better >> (at least according to German law). > > Surely there are exceptions. Obviously, RIPE NCC should continue to > operate mailing lists. Your proposal would prevent RIPE NCC from doing > that. > > Come to think of it, from a privacy point of view, I don't see much of a > difference between submitting a mail message to RIPE NCC for publication > and distribution over a mailing list, and a person: object for > publication and distribution using the RIPE database. Not every spammer can harvest all addresses daily ;o) eMail lists are collected by specialists over years and handed over to several spammers, thats why a lot of addresses are outdated before a spammer starts using them. And surely they cannot seperate working from outdated addresses, because the sending address is always faked and any "User unknown" return email, bounce or whatever feedback from the receivers mail server will never reach the spammer itself. So, spams will be heavily reduced, if the random address at ripe used to forward mails to a personal email address in any object is changing on a regular basis. Harvesting the proxy addresses, lets say, on a daily basis, will surely not be possible, because of the whois restructions on whois. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From laura at ripe.net Fri Dec 16 14:04:31 2011 From: laura at ripe.net (Laura Cobley) Date: Fri, 16 Dec 2011 14:04:31 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EE7397F.4020908@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <4EE7397F.4020908@ripe.net> Message-ID: <4EEB41DF.6090101@ripe.net> Dear colleagues, Thank you for your comments. We have published new FAQs on spam/hacking. You can find them online at: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming We will add further information in the coming months to support the implementation of new procedures. Best regards, Laura Cobley RIPE NCC Customer Services Manager On 12/13/11 12:39 PM, Laura Cobley wrote: > Dear all, > > We are working on improving the procedures and documentation in the area > of reporting abuse. As part of this work, we have already rewritten the > FAQs currently being discussed on this list. > > We will inform you as soon as the revised FAQs are published. > > Best regards, > > Laura Cobley > RIPE NCC Customer Services Manager > > > On 12/12/11 11:44 AM, Alessandro Vesely wrote: >> All, >> some of the replies to spam FAQs are bad. >> >> FAQ#1 (What is spam?) looks good enough to me. So I'd start with >> FAQ#2 that Leo brought up recently >> >> On 01/Dec/11 16:27, Leo Vegoda wrote: >>> Hi Tobias, You wrote: >>> >>>> The naive user should use the abuse finder tool which is already >>>> in place and would run much easier than today >>> >>> I disagree and I support the RIPE NCC's answer in its abuse FAQ: >>> >>> http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/should-i-just-ignore-spam >>> >> >> I too disagree with Tobias' statement, at least for some values of >> "naive user". Nevertheless, that FAQ's answer is bad. It reads: >> >> Should I just ignore spam? >> >> Yes. We recommend that you simply ignore and delete any spam >> emails you get. Spam is a universal problem and there is not much >> that can be done to stop it. However, if you do want to try to >> find out where the spam is originating from you can follow the >> steps in FAQ 5. >> >> I propose the following replacement text: >> >> Should I just ignore spam? >> >> Your mailbox provider may equip you with some means to report >> spam. If you can conveniently deploy such means using your >> preferred email client, please do so. Otherwise, we recommend >> that you simply ignore and delete any spam emails you get. Your >> email client may provide you with filters to do so automatically. >> >> Spam is a social problem, not a technical one. Therefore, >> technical remedies tend to get rather complicated. If you are a >> mailbox provider or want to learn more about how to find out where >> the spam is originating from, you can follow the steps in the FAQ >> entry "How can I counter spam?" >> >> Please note that FAQ#5 currently asks "What can I do to stop spam >> emails?" Since FAQ entries are not numbered, referring to "FAQ 5" is >> ambiguous, so I quoted its text, and changed the question while at it. >> FAQ#5 needs an even deeper revision, but please let's tackle them one >> at a time. >> >> Does everyone agree with the replacement text for FAQ#2? >> >>> The overwhelming majority of abuse is perpetrated by skilled >>> professionals who work hard to hide their tracks. Telling ordinary >>> Internet users that they have a useful role in identifying abuse >>> sources and reporting them to the hosting networks is a cruel lie. >> >> Agreed. >> >>> The scale of the problem requires large scale sampling and >>> statistical analysis rather than individual reports. >> >> In part agreed. Individual reports are useful because humans can >> complement automated filters in detecting spam, albeit both make >> errors. At any rate, I agree individual reports are to be collected. >> That's why I'm proposing to amend that entry. >> >> > > From russ at consumer.net Fri Dec 16 14:43:59 2011 From: russ at consumer.net (russ at consumer.net) Date: Fri, 16 Dec 2011 08:43:59 -0500 Subject: [anti-abuse-wg] whois access In-Reply-To: <4EEB16A2.50404@powerweb.de> References: <4EE9E7F0.7080905@consumer.net> <281E2C8B-E720-474D-B042-CC8FABC2D2DA@blacknight.ie> <4EEA2366.8050101@consumer.net> <4EEA2B7A.4090902@blacknight.com> <4EEA36A6.3000001@consumer.net> <4EEA5825.90308@CC.UniVie.ac.at> <4EEA6530.7020308@consumer.net> <4EEA7554.303@CC.UniVie.ac.at> <4EEA7D56.6060501@consumer.net> <4EEB0770.4050205@powerweb.de> <82ty50yhpi.fsf@mid.bfk.de> <4EEB16A2.50404@powerweb.de> Message-ID: <4EEB4B1F.7050807@consumer.net> >Not every spammer can harvest all addresses daily ;o) I have been doing this for years with domain whois. I am listed in over 1000 domains. My experience (without taking detailed measurements) is that a small trickle of spam comes within a few hours (which is why I know IP restrictions don't work). However, it does not build up to any significant amount for a couple months. I suspect the RIPE database is not as desirable as .com whois so i suspect changing the address every few months will be more than sufficient. However, anyone can do this on your own and you don't need RIPE to do it for you as long as you can set up e-mail forwarding. What should have been is that honeypot addresses should have been set up to measure the effectiveness of any anti-spam methods used. has this been done in the case of RIPE? How did RIPE come up with this new 1,000 queries per day limit? Did someone just pick a number or was it tested with data? Are there ongoing efforts to test the effectiveness of these and any other tools? The other problem I see is that the operation of the whois databases are part of the requirements to be an RIR. The RIR's all agreed in the MOU that policies relating to the requirements to be an RIR be submitted to the consensus process. It is supposed to go to the "Address Council" of the "Address Supporting Organization (ASO)." Instead we have RIR's skipping the consensus process and establishing their own local policies. Thank You From joe at oregon.uoregon.edu Fri Dec 16 16:34:30 2011 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Fri, 16 Dec 2011 07:34:30 -0800 (PST) Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy Message-ID: <11121607343033_5905@oregon.uoregon.edu> Hi Laura, You mentioned: #We have published new FAQs on spam/hacking. You can find them online at: # http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming Tremendous improvement, thank you! One suggestion for the last item ("Where can I find out more about spam/hacking?"), which currently only has two items, would be to add additional resources, perhaps: -- Messaging Anti-Abuse Working Group (http://www.maawg.org/) -- Spamhaus (http://www.spamhaus.org/) -- Spamwiki (http://spamtrackers.eu/wiki/index.php/Main_Page) Thanks for all the work on this, Merry Christmas/Happy New Year! Regards, Joe From russ at consumer.net Fri Dec 16 17:33:20 2011 From: russ at consumer.net (russ at consumer.net) Date: Fri, 16 Dec 2011 11:33:20 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <11121607343033_5905@oregon.uoregon.edu> References: <11121607343033_5905@oregon.uoregon.edu> Message-ID: <4EEB72D0.8050709@consumer.net> >-- Spamhaus (http://www.spamhaus.org/) With all the discussion about European privacy laws I often wondered about blacklists like SpamHaus that operate in Europe. Don't they collect information that is considered "personal information" under European Privacy laws? Do they have to follow the requirements of collection and dissemination of the information like other European businesses? I had noticed in some cases they publish names of suspected spammers along with discussions of their activities (in addition to the distribution of the blacklists). The Spamhuas privacy policy doesn't address any of this stuff. Thank You From michele at blacknight.ie Fri Dec 16 17:39:35 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Fri, 16 Dec 2011 16:39:35 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEB72D0.8050709@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> Message-ID: <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> On 16 Dec 2011, at 16:33, russ at consumer.net wrote: > >-- Spamhaus (http://www.spamhaus.org/) > > With all the discussion about European privacy laws I often wondered about blacklists like SpamHaus that operate in Europe. Don't they collect information that is considered "personal information" under European Privacy laws? Like what exactly?? > Do they have to follow the requirements of collection and dissemination of the information like other European businesses? I had noticed in some cases they publish names of suspected spammers along with discussions of their activities (in addition to the distribution of the blacklists). They normally list companies .. > The Spamhuas privacy policy doesn't address any of this stuff. > > Thank You > Why don't you ask them directly? > > > > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From russ at consumer.net Fri Dec 16 18:04:24 2011 From: russ at consumer.net (russ at consumer.net) Date: Fri, 16 Dec 2011 12:04:24 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> Message-ID: <4EEB7A18.9040905@consumer.net> >Like what exactly?? They distribute IP addresses and identify individual spammers. As I understand the definition of personal information that if you can track someone down from an IP then it is "personal information. In some cases you can and other cases you cannot. I wondered how this is handled under these European privacy Laws. >They normally list companies .. They list IP's, companies, and individuals in some cases. They compile data from complaints, honeypots, etc. Then they report their findings via blacklists and reputations and sometimes they discuss activities of individual spammers (companies or individuals). >Why don't you ask them directly? I did and the head guy answered under his pseudonym and gave some vague discussion about how they are a volunteer organization without resources, etc. etc. and then never answered any followups. I asked them to update their privacy policy but they never did. Back when they were being sued in the US I noticed several people in Europe had filed complaints against Spamhaus with some data protection office in the UK citing these European Privacy Laws. I was wondering what ever became of that and if any ruling was ever made. Thank You From vesely at tana.it Fri Dec 16 20:15:31 2011 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 16 Dec 2011 20:15:31 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEB41DF.6090101@ripe.net> References: <20111123134719.EDB3516738D@smtpgate1.restena.lu> <4ECE0666.8010502@restena.lu> <20111129075105.GM9075@x27.adm.denic.de> <4ED49593.4030504@powerweb.de> <20111129084900.GB8460@core.kyubu.de> <4ED4C0DA.5000808@abusix.com> <20111129114133.GA9081@core.kyubu.de> <4ED4C7ED.3070305@abusix.com> <4ED4FBBC.7040101@ripe.net> <4ED4FEEE.9080307@abusix.com> <4ED64AED.7030503@ripe.net> <4ED66A6E.4000404@abusix.com> <87vcq05yr7.fsf@enigma.otenet.gr> <4ED780EB.7040209@abusix.com> <8811B64A-CFB3-4F83-8031-57C4D08172B9@icann.org> <4ED797D2.9040302@abusix.com> <41F6C547EA49EC46B4EE1EB2BC2F341849F85A460A@EXVPMBX100-1.exc.icann.org> <4EE5DAF9.5030505@tana.it> <4EE7397F.4020908@ripe.net> <4EEB41DF.6090101@ripe.net> Message-ID: <4EEB98D3.1010203@tana.it> On 16/Dec/11 14:04, Laura Cobley wrote: > > We have published new FAQs on spam/hacking. You can find them online > at: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming Great improvement! One quick comment. In the page referenced from the last entry, http://www.ripe.net/ripe/docs/ripe-409 the term *ISP* is often used instead of *Mailbox Provider* (MP). The latter is newer, but more specific, since some ISPs don't run mail servers nowadays. From russ at consumer.net Fri Dec 16 22:32:05 2011 From: russ at consumer.net (russ at consumer.net) Date: Fri, 16 Dec 2011 16:32:05 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEB7A18.9040905@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> Message-ID: <4EEBB8D5.6030204@consumer.net> I received a few private e-mails from people on this list claiming i am all wrong about IP addresses being classified as personal information. I did not make this ruling, it was a 2008 proclamation by the EU Data Commission. One link is at http://pcin.net/update/2008/01/22/ip-addresses-are-private-eu/. Obviously people are tracked down all the time by their IP address (just ask the copyright enforcers) so it fits the EU definition. One guy is writing to me telling me not to post on this list because I am all wrong and off topic. The e-mail he sent borders on harassment. The fact is security and abuse has to be balanced with privacy. It is funny how the so-called anti-spam privacy activists go berserk by the mere mention that anti-spam blacklists also have to abide by privacy regulations. If you want to argue the point don't complain to me, I am just reporting the EU's findings. Contact the EU privacy commissioners and argue your point. Security and privacy are things that need to be balanced so it is not off-topic to discuss privacy requirements for abuse systems. Thank You From vesely at tana.it Sat Dec 17 13:23:34 2011 From: vesely at tana.it (Alessandro Vesely) Date: Sat, 17 Dec 2011 13:23:34 +0100 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EEBB8D5.6030204@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> Message-ID: <4EEC89C6.5000303@tana.it> On 16/Dec/11 22:32, russ at consumer.net wrote: > Security and privacy are things that need to be balanced so it is > not off-topic to discuss privacy requirements for abuse systems. The subject is on topic indeed. It has various facets, including unlimited access to abuse-mailboxes, anonymity of IP delegations, and possibly even redaction of spam complaints. For IP numbers, a privacy requirement is necessary to avoid tracking users. However, there has to be an exception for mail delivery (not submission). IIRC there is an exception for e-commerce, that limits a merchant's right to anonymity. Likewise, mail servers shouldn't be allowed to be anonymous. Most EU concerns are discussed within the coordination-wg, though. So I'm not clear on the worthiness of having this discussion here. jm2c From russ at consumer.net Sat Dec 17 17:37:06 2011 From: russ at consumer.net (russ at consumer.net) Date: Sat, 17 Dec 2011 11:37:06 -0500 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EEC89C6.5000303@tana.it> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> Message-ID: <4EECC532.2040609@consumer.net> >The subject is on topic indeed. It has various facets, All my posts in the last couple threads are related to abuse and RIPE but I am making my points in a roundabout way. My main point is that some of the people involved in abuse issues get so wrapped up in one aspect of the problem that they fail to see the overall picture. When we talk about enforcement of the EU privacy laws for the RIPE database many are arguing for a very strict application of EU privacy laws. No consideration was given for pass-through sites like mine or that fact that access to the whois lookups is not a regional issue. This is what happens when we talk about something people don't like (namely getting spam from having a contact address in the RIPE database). Yet when I bring up applying these laws to an anti-spam group suddenly their position changes and they argue for not applying the EU privacy laws strictly. In this case we have an anti-spam mechanism that everybody likes. Some people are applying the laws based on whether they like something or not, not on the actual facts. As for IP addresses and whether they identity a person is a complicated issues. The US courts have been split over whether IP addresses are "Personally Identifiable Information" (PII). There are long complicated discussions of the context in which the information is collected. The EU definition of "personal information" appears to be broader that the PII definition. In the case of spam blacklists or reputation scores the information is generally collected to accuse someone of spamming and blacklist their IP address. If you get put on one these lists by mistake and want to dispute the findings you suddenly see the importance of the privacy aspect. If you blacklist someone you may have to give them the information you collected about them and allow them to dispute it. In my case my web site IP is on RIPE's blacklist. That IP leads directly to my company and identifies me. By bringing up these issue I am now being accused of all sorts of things. My web site was set up in 1998 as a tool to track down and complain about spam, not a harvesting system. Not only that, I used to sue companies for breaking US privacy laws and I even testified at the first "so-called" spam summit at the US Federal Trade Commission. The US telemarketing and junk fax laws you can take companies into small claims court. I took many large corporations to court even sued several companies who harvested by whois info and used it send illegal junk faxes. To claim I am a "harvester" or that I am promoting violating privacy laws is ridiculous. What RIPE did when they implemented this IP address blocking was they reduced security for the sake of privacy. It is now more difficult to get abuse contacts. Sure people can go directly to the database but it makes things more difficult and time comsuming. Several users of my web site took the time to write to me to complain about the block. These were mostly system administrators and abuse staff, not people looking to harvest RIPE e-mail addresses. I get contacted all the time from security companies and law enforcement entities who use the site. No consideration is given to them and the fact that they are users of RIPE services when this block system was implemented. The other issue is the fact that the data is being collected under a government contract with IANA. A contractor is not permitted, on its own, to place restrictions on the data because it doesn't belong to them. Forgetting about EU privacy laws for the moment I noticed ARIN has placed a restriction on their whois data that reads: "You may not use, allow to use, or otherwise facilitate the use of ARIN WHOIS data for advertising, direct marketing, marketing research, or similar purposes." There is no legal basis for this restriction since things like "marketing research" are perfectly legal. The marketing research companies paid their taxes like everyone else and they have right to the public data and they can legally use it any way they want (as long as they don't break a law like sending an illegal junk fax). I believe the whois access issues needs to handled at the level of the Address Council because it is a universal service and any access restrictions need to be coordinated with IANA who, in turn, should coordinate with the US Government as they are required to do under their contract. Certainly I should not have to join a European mailing list to discuss the services I use from North America. Thank You Thank You. From michele at blacknight.ie Sat Dec 17 17:49:40 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Sat, 17 Dec 2011 16:49:40 +0000 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EECC532.2040609@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> Message-ID: <99BA5770-50C4-4669-A982-1E18E63BB3D2@blacknight.ie> On 17 Dec 2011, at 16:37, russ at consumer.net wrote: > > > The other issue is the fact that the data is being collected under a government contract with IANA. A contractor is not permitted, on its own, to place restrictions on the data because it doesn't belong to them. Forgetting about EU privacy laws for the moment I noticed ARIN has placed a restriction on their whois data that reads: "You may not use, allow to use, or otherwise facilitate the use of ARIN WHOIS data for advertising, direct marketing, marketing research, or similar purposes." There is no legal basis for this restriction since things like "marketing research" are perfectly legal. The marketing research companies paid their taxes like everyone else and they have right to the public data and they can legally use it any way they want (as long as they don't break a law like sending an illegal junk fax). > > I believe the whois access issues needs to handled at the level of the Address Council because it is a universal service and any access restrictions need to be coordinated with IANA who, in turn, should coordinate with the US Government as they are required to do under their contract. Certainly I should not have to join a European mailing list to discuss the services I use from North America. If you feel so strongly about all this then go to the next ICANN meeting in Costa Rica in March and raise it with the ASO. And if you want to access a European database then you are going to have to deal with us nasty Europeans. Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From kjz at gmx.net Sun Dec 18 12:46:36 2011 From: kjz at gmx.net (Karl-Josef Ziegler) Date: Sun, 18 Dec 2011 12:46:36 +0100 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: References: Message-ID: <4EEDD29C.2030002@gmx.net> > And if you want to access a European database then you are going to > have to deal with us nasty Europeans. Just 2 things: - Privavy laws in Europe seem to have much stronger restrictions compared to US laws. - And: a contract between ICANN/IANA and RIPE can't break European laws. European law is stronger than such a contract. If this should be changed it needs a mutual agreement between EU and US government. Is such an agreement in place? Just my 2 cents and IANAL, - Karl-Josef From james.davis at ja.net Mon Dec 19 09:17:43 2011 From: james.davis at ja.net (James Davis) Date: Mon, 19 Dec 2011 08:17:43 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEBB8D5.6030204@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> Message-ID: <4EEEF327.9050409@ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/12/2011 21:32, russ at consumer.net wrote: > I received a few private e-mails from people on this list claiming > i am all wrong about IP addresses being classified as personal > information. I did not make this ruling, it was a 2008 proclamation > by the EU Data Commission. The law is meant to be interpreted with a degree of subtlety. ISPs and mail providers are generally allowed to process IP addresses if it's in their legitimate interest (we'd not get very far otherwise). Dealing with spam or running an incident response function is thought to lie within this realm. The risk of being able to identify an individual starting with an IP address listed in a black list is very small, and the impact very small, but the benefits from publishing them should be very clear. If you'd like to learn more, our legal and regulatory officer wrote a paper on these issues at http://www.terena.org/activities/tf-csirt/publications/data-protection-v2.pdf Regards, James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7u8ycACgkQjsS2Y6D6yLxbawD+OAUlE2LW/AWUSz3ivT69AJ7H AsNLcxv+T/ZM2L7MkssA/ibp1oqn3+QhyEM/zn3h29ZGpHTF/Zpj/8APaidMoNQN =Xok5 -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From russ at consumer.net Mon Dec 19 10:00:52 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 04:00:52 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEEF327.9050409@ja.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> Message-ID: <4EEEFD44.6060803@consumer.net> >The risk of being able to identify an individual starting with an IP address listed in a black list is very small, and the impact very small, >but the benefits from publishing them should be very clear. Your discussion and the associated paper implies that the list operator/security personnel are always right because they are protecting the Internet. It implies their mission is more important than any other issue that someone may have. "It should be very clear" implies that if you have another opinion then there must be something wrong with you. This is the attitude many of those involved in abuse have and I am trying to point out that there are problems with such a position. It gives people involved in abuse the idea that they don't have to answer to anyone or abide by the same rules as everyone else. If the list is run poorly the impact can be tremendous. Both Cisco and Microsoft both currently run blacklists that generate all sorts of complaints. They often won't tell people why they were put on the lists. Even when they remove someone people report the staff is arrogant and accusatory. They assume anyone on the list is guilty and it up to them to prove otherwise. the complaints say sometimes they don't remove false alarms for months. Another guy in Australia running a blacklist used to demand "donations" to get removed and if he got into an argument with someone he would add them to the list. (On top of that he used to register for free DNS services and crash them by uploading his blacklist). Many in abuse do not think twice about advising ISP's to do deep packet inspection to find abuse and malware without ever considering the ISP's marketing department will use the system for other purposes. The people involved in privacy are the same way. They often don't consider the security implications of keeping everything private. No, I do not agree that ignoring or minimizing the privacy issues is justified because of the benefits. The blacklists of today are much like the early days of credit reporting when there were no clear rules and people could not get mistakes fixes. The blacklist operators should promote these protections to improve their products rather than looking for excuses to avoid them. Thank You From ops.lists at gmail.com Mon Dec 19 14:30:25 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 Dec 2011 19:00:25 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEEFD44.6060803@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> Message-ID: I will be the last to deny that 1. There's poor quality spam filtering out there 2. There's poor quality customer service types out there [especially in abuse - being a great bofh doesnt make you a great abuse desker] But that isn't any reason to tar all spam filtering with the same brush. On Mon, Dec 19, 2011 at 2:30 PM, russ at consumer.net wrote: > If the list is run poorly the impact can be tremendous. ?Both Cisco and > Microsoft both currently run blacklists that generate all sorts of > complaints. ?They often won't tell people why they were put on the lists. > Even when they remove someone people report the staff is arrogant and > accusatory. ?They assume anyone on the list is guilty and it up to them to > prove otherwise. ?the complaints say sometimes they don't remove false > alarms for months. ?Another guy in Australia running a blacklist used to > demand "donations" to get removed and if he got into an argument with > someone he would add them to the list. ?(On top of that he used to register > for free DNS services and crash them by uploading his blacklist). ?Many in > abuse do not think twice about advising ISP's to do deep packet inspection > to find abuse and malware without ever considering the ISP's marketing > department will use the system for other purposes. ?The people involved in > privacy are the same way. ? They often don't consider the security > implications of keeping everything private. -- Suresh Ramasubramanian (ops.lists at gmail.com) From russ at consumer.net Mon Dec 19 15:16:43 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 09:16:43 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> Message-ID: <4EEF474B.307@consumer.net> >But that isn't any reason to tar all spam filtering with the same brush. I never said all abuse lists are bad or are run poorly, some of them are run very well and provide tremendous benefits and I use them. I am just saying they need to live by the same standards as everyone else. I have dealt with the abuse desk you ran before if you remember me. I tried to respond to an e-mail from the network you ran and it was blocked. Your abuse desk told me other people on my netblock were spammers and I was supposed to go to my hosting provider and somehow make it stop. I had no idea (or power) to do anything about it and I had no idea what anyone else on the netblock was doing. When I ask for proof of the claims you never sent anything or explained further (although you did unblock me). These are some of the crazy stunts pulled by abuse departments that has no basis in law or common sense. Thank You From michele at blacknight.ie Mon Dec 19 15:21:58 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 19 Dec 2011 14:21:58 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF474B.307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> Message-ID: <4D3EAA9C-4AEB-4902-9F17-72590AD462BD@blacknight.ie> On 19 Dec 2011, at 14:16, russ at consumer.net wrote: > >But that isn't any reason to tar all spam filtering with the same brush. > > I never said all abuse lists are bad or are run poorly, some of them are run very well and provide tremendous benefits and I use them. I am just saying they need to live by the same standards as everyone else. And what standard would that be? DNSBLs provide a free service Nobody is obliged to use them And if a DNSBL is badly run then mail admins shouldn't use them .. > > I have dealt with the abuse desk you ran before if you remember me. I tried to respond to an e-mail from the network you ran and it was blocked. Your abuse desk told me other people on my netblock were spammers and I was supposed to go to my hosting provider and somehow make it stop. I had no idea (or power) to do anything about it and I had no idea what anyone else on the netblock was doing. When I ask for proof of the claims you never sent anything or explained further (although you did unblock me). These are some of the crazy stunts pulled by abuse departments that has no basis in law or common sense. Because of course we all make massive amounts of money from our abuse desks and running a network and protecting it from scumbags is free .. Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ops.lists at gmail.com Mon Dec 19 15:29:27 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 Dec 2011 19:59:27 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF474B.307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> Message-ID: I don't remember that incident - but yes, you don't own the larger netblock that was filtered. I, my filters or my team don't make a habit of filtering covering CIDRs unless there's massive amounts of spam spread across multiple subnets in there. And when that happens, I do like to talk to the ISP and ensure that they address those issues before I relax any filters. --srs On Mon, Dec 19, 2011 at 7:46 PM, russ at consumer.net wrote: > > I have dealt with the abuse desk you ran before if you remember me. ?I tried > to respond to an e-mail from the network you ran and it was blocked. ?Your > abuse desk told me other people on my netblock were spammers and I was > supposed to go to my hosting provider and somehow make it stop. ? ?I had no > idea (or power) to do anything about it and I had no idea what anyone else > on the netblock was doing. ?When I ask for proof of the claims you never > sent anything or explained further (although you did unblock me). ?These are > some of the crazy stunts pulled by abuse departments that has no basis in > law or common sense. -- Suresh Ramasubramanian (ops.lists at gmail.com) From thor.kottelin at turvasana.com Mon Dec 19 15:32:04 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Mon, 19 Dec 2011 16:32:04 +0200 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF474B.307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of russ at consumer.net > Sent: Monday, December 19, 2011 4:17 PM > To: anti-abuse-wg at ripe.net > I > tried to respond to an e-mail from the network you ran and it was > blocked. Your abuse desk told me other people on my netblock were > spammers and I was supposed to go to my hosting provider and > somehow > make it stop. I had no idea (or power) to do anything about it > and I > had no idea what anyone else on the netblock was doing. When I ask > for > proof of the claims you never sent anything or explained further > (although you did unblock me). These are some of the crazy stunts > pulled by abuse departments that has no basis in law or common > sense. A network accepting mail from another network is extending the latter a privilege. It is extremely common sense to block networks from which spam or other abuse is detected. If you really would like to argue that such blocking is illegal, the burden of proof is on you. -- Thor Kottelin http://www.anta.net/ From michele at blacknight.ie Mon Dec 19 15:48:10 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 19 Dec 2011 14:48:10 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> Message-ID: +1 On 19 Dec 2011, at 14:32, Thor Kottelin wrote: >> -----Original Message----- >> From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- >> bounces at ripe.net] On Behalf Of russ at consumer.net >> Sent: Monday, December 19, 2011 4:17 PM >> To: anti-abuse-wg at ripe.net > >> I >> tried to respond to an e-mail from the network you ran and it was >> blocked. Your abuse desk told me other people on my netblock were >> spammers and I was supposed to go to my hosting provider and >> somehow >> make it stop. I had no idea (or power) to do anything about it >> and I >> had no idea what anyone else on the netblock was doing. When I ask >> for >> proof of the claims you never sent anything or explained further >> (although you did unblock me). These are some of the crazy stunts >> pulled by abuse departments that has no basis in law or common >> sense. > > A network accepting mail from another network is extending the latter a > privilege. It is extremely common sense to block networks from which spam or > other abuse is detected. If you really would like to argue that such > blocking is illegal, the burden of proof is on you. > > -- > Thor Kottelin > http://www.anta.net/ > > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From russ at consumer.net Mon Dec 19 16:29:05 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 10:29:05 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> Message-ID: <4EEF5841.7000307@consumer.net> >A network accepting mail from another network is extending the latter a privilege. It is extremely common sense to block networks >from which spam or other abuse is detected. If you really would like to argue that such blocking is illegal, the burden of proof is on you. That is a simplistic argument from the early days the Internet and is often not true anymore. In many cases IPS's have contracts with users to provide certain services. In other countries Internet service is a public utility. Under US law if you block someone and tell them to make their ISP do something to get unblocked that is technically extortion. In many cases it is certainly proper and allowed to block another network but simplistic arguments will get you into trouble. The specific case I was describing where I tried to reply to someone and was probably not illegal until they told me to make my host do something. It is interesting that the network allowed e-mail to go from their network to mine yet was blocked when I responded. Does anyone check blacklists for outbound mail? >I do like to talk to the ISP and ensure that they address those issues before I relax any filters. Right, you advocate a "I know abuse when I see it" standard where you have the final say and there is no recourse. If anyone complains they must be a spammer or support spamming? I am now on a Comcast Business IP. At what point or at what level is too much abuse via the Comcast network to get all Comcast customers blocked? >And what standard would that be? The first standard would be privacy laws (In this case EU laws). Next would be compliance with the posted privacy policy. Microsoft and Cisco play all sorts of tricks here. Microsoft tells the US Government they have corporate privacy program monitored by the TRUSTe program. They tell customers that each of their services has different privacy policies and that some are covered by TRUSTe and some are not. They claim their blacklist services is a service not covered by their main privacy policy and not monitored by TRUSTe. Cisco does exactly the same thing with senderbase.org. The next standard is defamation laws that vary from country to country. From michele at blacknight.ie Mon Dec 19 16:41:56 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 19 Dec 2011 15:41:56 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF5841.7000307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> Message-ID: <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> On 19 Dec 2011, at 15:29, russ at consumer.net wrote: > >A network accepting mail from another network is extending the latter a privilege. It is extremely common sense to block networks > >from which spam or other abuse is detected. If you really would like to argue that such blocking is illegal, the burden of proof is on you. > > That is a simplistic argument from the early days the Internet and is often not true anymore. Ok, so how big is the network that you are running? > In many cases IPS's have contracts with users to provide certain services. In other countries Internet service is a public utility. Under US law if you block someone and tell them to make their ISP do something to get unblocked that is technically extortion. In many cases it is certainly proper and allowed to block another network but simplistic arguments will get you into trouble. The specific case I was describing where I tried to reply to someone and was probably not illegal until they told me to make my host do something. It is interesting that the network allowed e-mail to go from their network to mine yet was blocked when I responded. Does anyone check blacklists for outbound mail? > > >I do like to talk to the ISP and ensure that they address those issues before I relax any filters. > > Right, you advocate a "I know abuse when I see it" standard where you have the final say and there is no recourse. If anyone complains they must be a spammer or support spamming? I am now on a Comcast Business IP. At what point or at what level is too much abuse via the Comcast network to get all Comcast customers blocked? > > >And what standard would that be? > > The first standard would be privacy laws (In this case EU laws). How is that even relevant? > > Next would be compliance with the posted privacy policy. Microsoft and Cisco play all sorts of tricks here. Microsoft tells the US Government they have corporate privacy program monitored by the TRUSTe program. They tell customers that each of their services has different privacy policies and that some are covered by TRUSTe and some are not. They claim their blacklist services is a service not covered by their main privacy policy and not monitored by TRUSTe. Cisco does exactly the same thing with senderbase.org. > > The next standard is defamation laws that vary from country to country. Huh? How is listing an IP or netblock as a source of network abuse defamatory? That's the kind of defence used by spammers > > > > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ripe-anti-spam-wg at powerweb.de Mon Dec 19 17:30:37 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 19 Dec 2011 17:30:37 +0100 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> Message-ID: <4EEF66AD.50406@powerweb.de> >> In many cases it is certainly proper and allowed to block another network Should be allowed in all cases. I guess there is no law wherever in the world that disallows me to protect my own services from abuse. And no law whatsoever that pushes me, that I have to communicate with everybody in the world, even if I dont want to. That will make every antivirus- or firewall-software illegal. Dont simply think of abuse as spam, abuse is more (e.g. every day, we have idiots, that are trying to guess mailbox passwords or that try to log into network appliances, wich only have an IP and no domain pointing to them, surely until their IPs get captured and blocked, our IDS and firewall logs are full of this crap). And how could it be defamation, if we try to reach the responsible network abuse contact, to inform them, that they have a security breach and that one of their servers or dialin clients got hi-jacked ? Blacklist do not accuse anybody, they are simply informative and tell people that there might be a problem ... > Huh? > > How is listing an IP or netblock as a source of network abuse defamatory? > > That's the kind of defence used by spammers ... and harvesters :o) Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From thor.kottelin at turvasana.com Mon Dec 19 17:31:34 2011 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Mon, 19 Dec 2011 18:31:34 +0200 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF5841.7000307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of russ at consumer.net > Sent: Monday, December 19, 2011 5:29 PM > To: > Under US law if you block someone and tell them to > make > their ISP do something to get unblocked that is technically > extortion. As an online discussion about network abuse grows longer, the probability of someone comparing blacklisting to extortion approaches 1. (With apologies to Mike Godwin.) Under the law over here, extortion involves a threat as well as a benefit to which the recipient has no legal right. -- Thor Kottelin http://www.anta.net/ From michele at blacknight.ie Mon Dec 19 17:33:41 2011 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Mon, 19 Dec 2011 16:33:41 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: <4EEF66AD.50406@powerweb.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> <4EEF66AD.50406@powerweb.de> Message-ID: <81137812-9EF7-4BC1-B677-8988D8A2A5BB@blacknight.ie> Frank Most of us run private networks. I can't see why or how we could be "obliged" to grant anyone free access. It makes no sense to me. None Regards Michele On 19 Dec 2011, at 16:30, Frank Gadegast wrote: >>> In many cases it is certainly proper and allowed to block another network > > Should be allowed in all cases. > > I guess there is no law wherever in the world that disallows me to > protect my own services from abuse. > And no law whatsoever that pushes me, that I have to communicate > with everybody in the world, even if I dont want to. > That will make every antivirus- or firewall-software illegal. > > Dont simply think of abuse as spam, abuse is more > (e.g. every day, we have idiots, that are trying to guess > mailbox passwords or that try to log into network > appliances, wich only have an IP and no domain pointing to them, > surely until their IPs get captured and blocked, our IDS > and firewall logs are full of this crap). > > And how could it be defamation, if we try to reach the responsible network abuse contact, to inform them, that they have a security > breach and that one of their servers or dialin clients got > hi-jacked ? > > Blacklist do not accuse anybody, they are simply informative > and tell people that there might be a problem ... > >> Huh? >> >> How is listing an IP or netblock as a source of network abuse defamatory? >> >> That's the kind of defence used by spammers > > ... and harvesters :o) > > > Kind regards, Frank > > -- > PHADE Software - PowerWeb http://www.powerweb.de > Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de > Schinkelstrasse 17 fon: +49 33200 52920 > 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 > ====================================================================== > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.biz http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From dhc at dcrocker.net Mon Dec 19 17:11:35 2011 From: dhc at dcrocker.net (Dave CROCKER) Date: Mon, 19 Dec 2011 08:11:35 -0800 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> Message-ID: <4EEF6237.2030402@dcrocker.net> On 12/19/2011 5:30 AM, Suresh Ramasubramanian wrote: > But that isn't any reason to tar all spam filtering with the same brush. Perhaps you are underestimating some people's requirement for absolute perfection in the world? (Their version of perfection, not yours or mine, of course...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ripe-anti-spam-wg at powerweb.de Mon Dec 19 18:39:46 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 19 Dec 2011 18:39:46 +0100 Subject: [anti-abuse-wg] size DOES matter (sorry, had to use this subject :o) In-Reply-To: <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> Message-ID: <4EEF76E2.2090502@powerweb.de> Michele Neylon :: Blacknight wrote: Hi Michele, > On 19 Dec 2011, at 15:29, russ at consumer.net wrote: > >> That is a simplistic argument from the early days the Internet and is often not true anymore. > > Ok, so how big is the network that you are running? > Hm. Lets use Russ' own tools at network-tools.com to estimate that: TraceRoute to 67.222.132.203 [consumer.net] Hop (ms) (ms) (ms) IP Address Host name 1 0 0 0 67.222.132.203 67.222.132.203.tailormadeservers.com Trace complete badly enough this whois service does not show any networks, well lets look those up myself: Comcast Business Communications, LLC CBC-PHILADELPHIA-29 (NET-70-90-0-0-1) 70.90.0.0 - 70.90.31.255 and THEKEYWORDFACTORYLLC THEKEYWORDFACTORYLLCNET (NET-67-222-132-192-1) 67.222.132.192 - 67.222.132.254 and a whois for one of those domains Whois query for nwtools.com... Results returned from whois.internic.net: ... (the usual internic stuff) ... Domain Name: NWTOOLS.COM Registrar: TUCOWS.COM CO. Whois Server: whois.tucows.com Referral URL: http://domainhelp.opensrs.net Name Server: DNS.CONSUMER.NET Name Server: DNS2.CONSUMER.NET Status: ok Updated Date: 12-dec-2011 Creation Date: 23-feb-2005 Expiration Date: 23-feb-2015 ... (the usual disclaimer) ... Results returned from whois.tucows.com: IP Address: 67.222.132.193 Maximum Daily connection limit reached. Lookup refused. **** Daily limit reached, looks like Tucows is trying to protect their own service, those bad, bad boys :o ) **** Hm, so I have to use our own whois at Tucows (we are reseller of Tucows :o) Registrant: Consumer.net, LLC PO Box 1860 Ocean City, NJ 08226 US Domain name: CONSUMER.NET Administrative Contact: Domain Administrator, Consumer.net whois222 at consumer.net PO Box 1860 Ocean City, NJ 08226 US +1.6093983301 consumer.net is an LCC. It calls itself "web development company", but does not seem to have any customers. consumer.net seems to simply bake a few network tools and copyright and privacy website (wich mostly consist of a handfull "tweets" from twitter without even an own "design" or own software installed on the own servers (so it looks like, if those sites are giving all http-logs completly over to twitter !) and places adverts all over them (even on the own homepage !) to make money from it. consumer.net is no IANA or ARIN (or other RIR) member (as far as I could search the net), does not own a own network and seems to simply rent a few housing server at two different provider. Furthermore, all "web design customers" share the same few IPs and the same "design". Finally directly from www.consumer.net: " The types of advertisements displayed are based on a number of factors such as this site's content and your Internet browsing and search history. See the Privacy Policy for more information. This information is collected if a purchases are made, advertising services are purchased, or an inquiry is made. No third party marketers are used. " So: consumer.net should not have any data about me visiting his site :o) But this "service" is giving my data already to third parties, e.g google and twitter Great ... BTW: there are 27 links pointing to www.consumer.net in google and they are mostly from its other own sites. So my estimation is: - one person - two servers - 5 IPs - no customers at all - makes profit from collecting services from third parties (what is probably not allowed from those parties at all, otherwise consumer.net would have no access limits :o) - gives all visitors data to third parties I can only hope that this silly discussion will stop now. Brian: please do something, that we are coming back to mails regarding abuse AND ripe ... Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From russ at consumer.net Mon Dec 19 18:41:23 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 12:41:23 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: <4EEF66AD.50406@powerweb.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> <4EEF66AD.50406@powerweb.de> Message-ID: <4EEF7743.5080104@consumer.net> >I guess there is no law wherever in the world that disallows me to protect my own services from abuse. ... >And how could it be defamation, if we try to reach the responsible network abuse contact, to inform them, that they have a security >breach and that one of their servers or dialin clients got >hi-jacked ? >Blacklist do not accuse anybody, they are simply informative >and tell people that there might be a problem ... ... >Perhaps you are underestimating some people's requirement for absolute perfection in the world? >(Their version of perfection, not yours or mine, of course...) ... >As an online discussion about network abuse grows longer, the probability of >someone comparing blacklisting to extortion approaches 1. ... All of the above comments are pretty much worthless. They are meant to twist what I said and try to ridicule me while avoiding the issues I raised. These types of response make abuse groups look like a small group of arrogant individuals who could not care less about other issues or other people's rights. This is exactly what Spamhaus did when they got sued and they posted all those child-like messages on their web site. In the end the court found they lied and they paid all kinds of legal fees because of it. I don't completely disagree with the points made above but the treatment is way too simplistic. Just like the worst criminals, spammers have rights too and sometimes abuse people accuse the wrong people, make mistakes, or are too busy to fix flaws in their system. Nobody requires "perfection" but to completely ignore issues and ridicule people when they raise the issues is negligence. The operation of a blacklist on its own is not extortion until you start telling people to do certain things (like pay money or demand action from your ISP) does it fall into the area of extortion. You also run into iisues of running ancillary paid services. I wonder if you have a much easier time getting off a Microsoft or Cisco blacklist if you subscribe to their services? >That's the kind of defence used by spammers >... and harvesters :o) Every time someone says abuse staff should adhere to standards this is the response. It shows how clueless some people can be. People get so hyped up when someone mentions this type of stuff they fail to realized these standards will greatly improve things like blacklists. Thank You From vesely at tana.it Mon Dec 19 20:03:20 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 19 Dec 2011 20:03:20 +0100 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <99BA5770-50C4-4669-A982-1E18E63BB3D2@blacknight.ie> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <99BA5770-50C4-4669-A982-1E18E63BB3D2@blacknight.ie> Message-ID: <4EEF8A78.1060704@tana.it> On 17/Dec/11 17:49, Michele Neylon :: Blacknight wrote: > > And if you want to access a European database then you are going to > have to deal with us nasty Europeans. Even that may not be enough. IANAL, but when I read RIPE Database Terms and Conditions[1], its "Article 3 - Purpose of the RIPE Database" doesn't seem to be designed to provide abuse contacts info to anyone. The nearest point is its fifth bullet, which says: * Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. Do users have to take special actions in order to become "authorized under the law"? [1] http://www.ripe.net/db/support/db-terms-conditions.pdf From niall at blacknight.com Mon Dec 19 21:45:16 2011 From: niall at blacknight.com (Niall Donegan) Date: Mon, 19 Dec 2011 20:45:16 +0000 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EECC532.2040609@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> Message-ID: <4EEFA25C.7040602@blacknight.com> On 17/12/11 16:37, russ at consumer.net wrote: > What RIPE did when they implemented this IP address blocking was they > reduced security for the sake of privacy. It is now more difficult to > get abuse contacts. Sure people can go directly to the database but it > makes things more difficult and time comsuming. Several users of my web > site took the time to write to me to complain about the block. These > were mostly system administrators and abuse staff, not people looking to > harvest RIPE e-mail addresses. I get contacted all the time from > security companies and law enforcement entities who use the site. No > consideration is given to them and the fact that they are users of RIPE > services when this block system was implemented. What you're forgetting it that RIPE NCC have finite resources. They have documented the block system at http://www.ripe.net/ripe/docs/ripe-358#211 These restrictions were put in place in order to make sure that everyone has fair access to the system. You are clearly hitting limits, and they have provisions for your case in order to allow Bulk Access. Have a look at http://www.ripe.net/data-tools/support/documentation/bulk-access-agreement Yes, there is a fee, but again, that's because you're using more resources than average. There's also services like http://www.radb.net who mirror the data from all the IRRs who you might like to deal with! > I believe the whois access issues needs to handled at the level of the > Address Council because it is a universal service and any access > restrictions need to be coordinated with IANA who, in turn, should > coordinate with the US Government as they are required to do under their > contract. Certainly I should not have to join a European mailing list > to discuss the services I use from North America. You're trying to use a service that's based in Europe and hence operates under EU law. Where does American law come into this? This is purely an implementation matter for Ripe NCC. Niall -- Niall Donegan ---------------- http://www.blacknight.com Blacknight Internet Solutions Ltd, Unit 12A, Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From linford at spamhaus.org Mon Dec 19 21:47:11 2011 From: linford at spamhaus.org (Steve Linford) Date: Mon, 19 Dec 2011 20:47:11 +0000 Subject: [anti-abuse-wg] Spam FAQs need revision In-Reply-To: <4EEF7743.5080104@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> <1B2CF262-02D4-40BF-A8F4-EF2CA1B76F97@blacknight.ie> <4EEF66AD.50406@powerweb.de> <4EEF7743.5080104@consumer.net> Message-ID: On 19 Dec 2011, at 18:41, russ at consumer.net wrote: > This is exactly what Spamhaus did when they got sued and they posted all those > child-like messages on their web site. In the end the court found they lied and they paid all kinds of > legal fees because of it. OK people, I know I've been cryogenically frozen for the last 10 years but you really need to tell me these things... We were found to have lied by a court? When? And we paid "all kinds of legal fees" because of it? Why doesn't anybody tell me these things! Steve Linford The Spamhaus Project http://www.spamhaus.org From russ at consumer.net Mon Dec 19 21:48:08 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 15:48:08 -0500 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EEF8A78.1060704@tana.it> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <99BA5770-50C4-4669-A982-1E18E63BB3D2@blacknight.ie> <4EEF8A78.1060704@tana.it> Message-ID: <4EEFA308.8030305@consumer.net> >when I read RIPE Database Terms and Conditions ... I suspect the requirements for operating a publicly accessible whois are found in the list of requirements for opertaing an RIR. This document is referenced in the RIR MOU but I don't have copy yet. If an RIR develops something outside of these RIR requirements then I think they can set any kind of restriction they want. If the requirement is somehow superseded by EU laws then they obviously have to follow those laws. However, nobody has pointed to a specific law that would restrict access to abuse contacts to 1000 queries per day. Thank You From russ at consumer.net Mon Dec 19 21:54:56 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 15:54:56 -0500 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EEFA25C.7040602@blacknight.com> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> Message-ID: <4EEFA4A0.4080305@consumer.net> >What you're forgetting it that RIPE NCC have finite resources. I agree that RIPE has to limit access to prevent DOS attacks or slowdowns to the system. However, I am nowhere near that limit and they have told me the reason is that I cannot have unrestricted access is because EU privacy laws restrict "unlimited access." They told me I could continue making requests at my current level if I used a "-r" switch but I would not get the abuse contact info. I would run my own mirror except I would not get the abuse contact info. Thank You From joe at oregon.uoregon.edu Mon Dec 19 22:23:57 2011 From: joe at oregon.uoregon.edu (Joe St Sauver) Date: Mon, 19 Dec 2011 13:23:57 -0800 (PST) Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs Message-ID: <11121913235719_6243@oregon.uoregon.edu> Niall commented: #There's also services like http://www.radb.net who mirror the data from #all the IRRs who you might like to deal with! Unfortunately, at least in my experience, the routing registry data is often stale or inaccurate, even for things as basic as ASN information. This is not the fault of the RADB folks, it's simply that many users don't take the time to keep their routing registry objects up-to-date. Therefore, while some whois clients query the RADB for ASN information, in my experience, you really want to always check the RIRs for the "last word" when it comes to who controls a given resource (and of course, the sort of data that the RADB offers doesn't have the same coverage as the RIRs, anyhow). That's the main reason why I'm always concerned when I bump into, or I hear about others who've bumped into, well-intentioned but operationally-problematic whois rate limits or anti-harvesting provisions. If systems are old and underprovisioned for modern loads, my recommendation would be to make upgrading them an operational priority, or work on plans to mirror/replicate the data so that normal operational traffic isn't going to result in systems becoming slow or overloaded. Regards, Joe From ops.lists at gmail.com Tue Dec 20 03:48:21 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 20 Dec 2011 08:18:21 +0530 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: <4EEF5841.7000307@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> Message-ID: Er - there's a huge difference between "cheap colo range with a /18 that's spread with snowshoe bulk mailers" and "comcast business ranges with mostly individual static IP cablemodems allotted to different businesses, with an ISP that practices what seems to be the gold standard in outbound filtering of abuse from their IP space". Our filters at least tend not to block Comcast. On Mon, Dec 19, 2011 at 8:59 PM, russ at consumer.net wrote: >>I do like to talk to the ISP and ensure that they address those issues >> before I relax any filters. > > Right, you advocate a "I know abuse when I see it" standard where you have > the final say and there is no recourse. ?If anyone complains they must be a > spammer or support spamming? ?I am now on a Comcast Business IP. ?At what > point or at what level is too much abuse via the Comcast network to get all > Comcast customers blocked? -- Suresh Ramasubramanian (ops.lists at gmail.com) From russ at consumer.net Tue Dec 20 04:33:25 2011 From: russ at consumer.net (russ at consumer.net) Date: Mon, 19 Dec 2011 22:33:25 -0500 Subject: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy In-Reply-To: References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEEF327.9050409@ja.net> <4EEEFD44.6060803@consumer.net> <4EEF474B.307@consumer.net> <4EEF5841.7000307@consumer.net> Message-ID: <4EF00205.6020008@consumer.net> >Er - there's a huge difference between "cheap colo range with a /18 that's spread with snowshoe bulk mailers" >and "comcast business ranges ... Right, those are the extremes but where do you draw the line? In my case I rented a server with an ISP operating legally. I actually checked for abuse complaints of several companies that rented servers and I found complaints about all of them. As for Comcast being the "gold standard" for filtering the only way they can do this is to violate their network policy. After the p2p throttling they claimed they have a "protocol agnostic" network policy. But you can't do that and also block specific ports. Further, if Comcast does block you they often won't tell people why. The exact quote to me was: "it doesn't matter what our privacy policy says, you are not getting the info." They also told me if I registered for a higher level of service somehow the security issues would disappear and there would no longer be blocking. Plus, last year they moved most of their privacy policies from Comcast.NET (covered by TRUSTe) to Comcast.COM (not covered by TRUSTe). If you want to be the "gold standard" for filtering then you will need to violate the privacy of your customers, keep it secret from them so they don't get pissed off, and then the system will be hijacked by the marketing department and used to increase the bottom line. This is getting off the issue of RIPE and abuse but the point is there are tradeoffs for all these actions and abuse is not the only issue in the world. Thank You From brian.nisbet at heanet.ie Tue Dec 20 11:00:00 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 20 Dec 2011 10:00:00 +0000 Subject: [anti-abuse-wg] Spam FAQs, Whois Query Restrictions etc Message-ID: <4EF05CA0.30101@heanet.ie> Morning, There's been an amount of useful discussion recently, but I think it might be all getting a little circular at this point. I'd like to thank the NCC, as others have done, for their work in updating the FAQs and I'm very glad the overall response has been positive. On the matter of network-tools.com and the whois restrictions, I think the point has been presented and argued, but it has also been argued against and I don't think we're getting anywhere. Russ, if you want to take this any further you have the option of lobbying the NCC directly either as or via a member, or seeing what's possible via the policy route. The Chairs of the working group (aa-wg-chairs at ripe.net) are happy to help you with the latter. I don't think that claims about other companies, especially those that involve judicial proceedings, are useful, and they are even less useful if they cannot be backed up, so let's not have any of that on the list please. Thanks, Brian. From shane at time-travellers.org Tue Dec 20 14:46:02 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 20 Dec 2011 14:46:02 +0100 Subject: [anti-abuse-wg] Privacy requirements, was Spam FAQs In-Reply-To: <4EEFA4A0.4080305@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> Message-ID: <1324388763.2338.18.camel@shane-desktop> Russ, On Mon, 2011-12-19 at 15:54 -0500, russ at consumer.net wrote: > >What you're forgetting it that RIPE NCC have finite resources. > > I agree that RIPE has to limit access to prevent DOS attacks or > slowdowns to the system. However, I am nowhere near that limit > and they have told me the reason is that I cannot have unrestricted > access is because EU privacy laws restrict "unlimited access." > They told me I could continue making requests at my current level if I > used a "-r" switch but I would not get the abuse contact info. > I would run my own mirror except I would not get the abuse contact info. See, this is what's great about the way things work in the RIPE region! If you were dealing with, say, a bank or an airline or even a governmental department and did not like one of their bureaucratic rules, you would have little or no recourse. Luckily, the RIPE NCC takes their policies from the RIPE community. So all you need to do is make a rational policy proposal directing the RIPE NCC to set their contact information publication policy as you prefer (although this must of course bow to Dutch law), and get consensus from the community on it. Unfortunately, you seem to be the only one in favor of lifting the Whois restrictions so you may have a tough time getting consensus on a policy proposal. But who knows? A carefully worded policy proposal may gain widespread support! Brian has already offered to help you create one, so I eagerly await the results. I'd be happy to read a draft if you're nervous about going forward without discussing it with someone privately first. -- Shane From ripe-anti-spam-wg at powerweb.de Tue Dec 20 15:44:03 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 20 Dec 2011 15:44:03 +0100 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <1324388763.2338.18.camel@shane-desktop> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> Message-ID: <4EF09F33.6010804@powerweb.de> Shane Kerr wrote: Hi, > Luckily, the RIPE NCC takes > their policies from the RIPE community. So all you need to do is make a > rational policy proposal directing the RIPE NCC to set their contact > information publication policy as you prefer (although this must of > course bow to Dutch law), and get consensus from the community on it. > > Unfortunately, you seem to be the only one in favor of lifting the Whois > restrictions so you may have a tough time getting consensus on a policy > proposal. > > But who knows? Raising the restrictions on personal objects isnt a bad idea at all, but it should wait until personal data and abuse contacts are seperated, like outlined by Tobias' last proposal and after most objects in the database confirm to this new model. I would love to hide all personal email addresses behind a randomly changing address @abuse.ripe.net And names, postal, fon and fax address of personal objects could be hidden behind a webpage with captcha code or thelike, maybe the abuse finder tool could be enhanced here. But again: most important is the seperation of personal and abuse data, a database cleanup and the general unrestricted access to abuse contacts. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From vesely at tana.it Tue Dec 20 17:24:30 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 20 Dec 2011 17:24:30 +0100 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <4EF09F33.6010804@powerweb.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> Message-ID: <4EF0B6BE.70906@tana.it> On 20/Dec/11 15:44, Frank Gadegast wrote: > > Raising the restrictions on personal objects isnt a bad idea at all, > but it should wait until personal data and abuse contacts are > seperated, like outlined by Tobias' last proposal and after > most objects in the database confirm to this new model. Agreed. What synchronization is exactly needed depends on the software details, so I'd leave that in RIPE NCC's hands. However, proposal 2011-06 doesn't mention relaxing access restrictions. Do we need to add such goal explicitly? > I would love to hide all personal email addresses behind > a randomly changing address @abuse.ripe.net Uh, that sounds like programming the "search" button to step aside from the cursor whenever users try to click on it :-) Abuse directed to an abuse-mailbox is like bugs caught during regression testing: still annoying, but much better than uncontrolled occurrences. > And names, postal, fon and fax address of personal objects > could be hidden behind a webpage with captcha code or thelike, > maybe the abuse finder tool could be enhanced here. Yes, personal data has to be protected. Perhaps not names. Perhaps login is easier than captcha for some users. From ripe-anti-spam-wg at powerweb.de Tue Dec 20 19:32:23 2011 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 20 Dec 2011 19:32:23 +0100 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <4EF0B6BE.70906@tana.it> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> Message-ID: <4EF0D4B7.6070103@powerweb.de> Alessandro Vesely wrote: > On 20/Dec/11 15:44, Frank Gadegast wrote: >> >> Raising the restrictions on personal objects isnt a bad idea at all, >> but it should wait until personal data and abuse contacts are >> seperated, like outlined by Tobias' last proposal and after >> most objects in the database confirm to this new model. > > Agreed. What synchronization is exactly needed depends on the > software details, so I'd leave that in RIPE NCC's hands. However, > proposal 2011-06 doesn't mention relaxing access restrictions. Do we > need to add such goal explicitly? No, thats really a different issue and should be looked at later. >> I would love to hide all personal email addresses behind >> a randomly changing address@abuse.ripe.net > > Uh, that sounds like programming the "search" button to step aside > from the cursor whenever users try to click on it :-) Yes, sounds like security by obscurity, but why not ? I like to make sure, that this should not apply to abuse contacts, wich are to my opinion the only contacts that really need to be available for automated system. Or does anybody see a reason, that a non-abuse but personal contact should be visible by whois or in whatever else automated way ? I cant think of an example here. whois could show the netrange, netname, routing and all other technical objects, surely the new abuse-c with all its data, could name the other contacts, but then simply point to a webpage for the details of the other contacts. >> And names, postal, fon and fax address of personal objects >> could be hidden behind a webpage with captcha code or thelike, >> maybe the abuse finder tool could be enhanced here. > > Yes, personal data has to be protected. Perhaps not names. Perhaps > login is easier than captcha for some users. A login for everybody that simply wants to know to whom a network belongs ? Thats maybe too much security and it should better not be possible to track, wich user is requesting wich information. That would again be personal data, thats needs to be protected inside the systems of RIPE NCC, better leave that one out. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== From blakjak at gmail.com Wed Dec 28 11:21:55 2011 From: blakjak at gmail.com (Mark Foster) Date: Wed, 28 Dec 2011 23:21:55 +1300 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <4EF0D4B7.6070103@powerweb.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> Message-ID: I realise this is a week old, but it's a holiday so perhaps that excuses my delayed contribution? On Wed, Dec 21, 2011 at 7:32 AM, Frank Gadegast < ripe-anti-spam-wg at powerweb.de> wrote: > I would love to hide all personal email addresses behind > >> a randomly changing address@abuse.ripe.net >>> >> >> Uh, that sounds like programming the "search" button to step aside >> from the cursor whenever users try to click on it :-) >> > > Yes, sounds like security by obscurity, but why not ? > > I like to make sure, that this should not apply to abuse contacts, > wich are to my opinion the only contacts that really need to be > available for automated system. > > Or does anybody see a reason, that a non-abuse but personal contact > should be visible by whois or in whatever else automated way ? > I cant think of an example here. > > whois could show the netrange, netname, routing and all > other technical objects, surely the new abuse-c with all > its data, could name the other contacts, but then simply > point to a webpage for the details of the other contacts. > > Ensuring that abuse-c details are the ones that're available unobscured highlights the very reason the issue is problematic... abuse@ needs to be the service which is _not_ filtered, and to be effective, needs real people to pay prompt attention. Half the reason organisations of a certain age or size are often seen to turn a blind eye to feedback received via that alias, is due to the sheer volume of crud directed at it. Surely leaving abuse-c details as the ones that aren't obscured is just going to magnify the affect? I like the idea of @abuse.ripe.net aliases but frankly, that'll just submit the MX records to an insane amount of abuse. Better that organisations be required to manage their own contact details appropriately enough for public listing; role based, write-off aliases which can be superceded over time if necessary, perhaps. Fact is, if you're eligible to get an IP Range direct from an RIR (as opposed to getting an ISP CIDR range, and thus being proxied through them in terms of any complaints about your conduct) you're morally (if not by policy) obliged to provide legitimate contact information. Cost of doing business, and it's not that onerous IMHO. > > And names, postal, fon and fax address of personal objects >>> could be hidden behind a webpage with captcha code or thelike, >>> maybe the abuse finder tool could be enhanced here. >>> >> >> Yes, personal data has to be protected. Perhaps not names. Perhaps >> login is easier than captcha for some users. >> > > A login for everybody that simply wants to know to whom > a network belongs ? > Thats maybe too much security and it should better not be > possible to track, wich user is requesting wich information. > That would again be personal data, thats needs to be protected > inside the systems of RIPE NCC, better leave that one out. > > If I only had to maintain a small number of Logins and I was using them regularly, i wouldn't have a problem with this.... however this will only discourage Joe-Public from actually tracking down abuse and reporting it - as the opportunity cost of taking the time to register in order to report an offense will be that much higher. Just look at how successful the mail service providers who've reverted to requiring web-form-submission complaints are finding it.... The drop in noise is no doubt coincidental to a drop in legitimate complaints from victims who now find it's easier to simply trash spam coming from Yahoo, than it is to submit complaints (that are, from the users perspective, largely ineffective, people see the abuse at dept's of most large organisations as a black hole manned by something vaguely better than trained monkeys...) Oh, is that my cynical nature coming through? whoops... My $0.02: - Compulsary abuse-c information in whois, supported. - Validation and reverification of contact information, supported. - Revoking (?) peoples IP ranges if they can't keep their contact information accurate? supported. - This is only going to get worse with IPv6. It's so big there will be large swathes of 'throw away' space and an even larger tendency for people to judge an entire netblock by the behavior of a small subset. I firmly believe that the RIRs and ISP's and Network Operators at all levels need to keep the lines of communication open, we should be able to recognise our need to mutually support eachother and to be able to deal with abuse (not just spam, either) originating from within our midst. Networks who can't take some responsibility for their customers, shouldn't expect anywhere near the same degree of professional courtesy. Mark. PS: In New Zealand where I am, It's been widely discussed that identifying an IP address holder only identifies the 'Account Holder', not the individual who's carried out an offense. So the Account Holder gets to have the responsibility associated with this. (Awareness of this point came as a by product of anti-piracy legislation introduced in the last year or two.) If the ISP won't disclose Account Holder information (under the terms of the law) they lose their 'safe harbour' provisions and essentially take that responsibility on themselves. Just throwing that out there as a possibly useful data point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at bfk.de Wed Dec 28 11:48:08 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 28 Dec 2011 10:48:08 +0000 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: (Mark Foster's message of "Wed, 28 Dec 2011 23:21:55 +1300") References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> Message-ID: <82y5txx993.fsf@mid.bfk.de> * Mark Foster: > Half the reason organisations of a certain age or size are often seen to > turn a blind eye to feedback received via that alias, is due to the sheer > volume of crud directed at it. Surely leaving abuse-c details as the ones > that aren't obscured is just going to magnify the affect? Maybe, who knows. Just make it opt-in, so that people can decide whether they want to publish their abuse contact point or not. Some of us are actually interested in receiving reports, despite the high false positive rate. Acceptance among RIPE members would probably increase if this contact point information could be a URL and not just a mailbox (but this would certainly draw ire from some potential reporters). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From russ at consumer.net Wed Dec 28 14:53:53 2011 From: russ at consumer.net (russ at consumer.net) Date: Wed, 28 Dec 2011 08:53:53 -0500 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <82y5txx993.fsf@mid.bfk.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> <82y5txx993.fsf@mid.bfk.de> Message-ID: <4EFB1F71.4050204@consumer.net> > Just make it opt-in, so that people can decide whether they want to publish their abuse contact point or not. I thought is already is "opt-in" as the contact enters the information with the knowledge it will be published. If it is opt-in the EU data protection laws do not come into play since there is an exemption for those that opt-in to their info being published. Thank You From fweimer at bfk.de Wed Dec 28 15:40:02 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 28 Dec 2011 14:40:02 +0000 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <4EFB1F71.4050204@consumer.net> (russ@consumer.net's message of "Wed, 28 Dec 2011 08:53:53 -0500") References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> <82y5txx993.fsf@mid.bfk.de> <4EFB1F71.4050204@consumer.net> Message-ID: <82aa6cyd31.fsf@mid.bfk.de> >> Just make it opt-in, so that people can decide whether they want to >> publish their abuse contact point or not. > > I thought is already is "opt-in" as the contact enters the information > with the knowledge it will be published. > > If it is opt-in the EU data protection laws do not come into play > since there is an exemption for those > that opt-in to their info being published. The RIPE NCC has decided that publication in the RIPE database does not give consent to publication (sic), at least not in bulk form as generally needed for some forms of abuse processing. I was surprised when this was announced and I believe RIPE NCC's legal counsel was and is wrong. It would have been better to advise its members that they need to make sure that they have consent from the folks whose data they've submitted to the RIPE NCC for publication. This is what DENIC did when it was discovered that the WHOIS for 9.4.e164.arpa, despite being nominally opt-in, was populated by default with personally identifiable information by several DENIC members. Anyway, I don't think RIPE NCC will give us reassurances that they won't make another u-turn on the abuse-c: attribute, particularly if it is mandatory. That's why I think the whole endeavor is rather pointless. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From russ at consumer.net Thu Dec 29 05:00:07 2011 From: russ at consumer.net (russ at consumer.net) Date: Wed, 28 Dec 2011 23:00:07 -0500 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <4EFB1F71.4050204@consumer.net> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> <82y5txx993.fsf@mid.bfk.de> <4EFB1F71.4050204@consumer.net> Message-ID: <4EFBE5C7.8080308@consumer.net> >I was surprised when this was announced and I believe RIPE NCC's legal counsel was and is wrong. >It would have been better to advise its members that they need to make sure that they have consent >from the folks whose data they've submitted to the RIPE NCC for publication. I wasn't involved in the development and this is speculation on my part ... but I suspect the policy development came about because some anti-abuse people believe it is wrong for companies to harvest public information for marketing purposes. Therefore, they came up with the blocking idea. Since there was no legitimate reason for blocking access to public information they came up with this privacy law idea. Even though it doesn't apply it sounds good so they just keep repeating over and over that privacy laws are forcing their hand. The report that is supposed to describe the situation is so vague and incomplete that it is impossible to determine how they made their decisions and it does not even identify the legal council that provided the advice: http://www.ripe.net/ripe/groups/tf/dp This stuff happens when abuse issues are treated as a "religion." Thank You From shane at time-travellers.org Thu Dec 29 14:20:34 2011 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 29 Dec 2011 14:20:34 +0100 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <82aa6cyd31.fsf@mid.bfk.de> References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> <82y5txx993.fsf@mid.bfk.de> <4EFB1F71.4050204@consumer.net> <82aa6cyd31.fsf@mid.bfk.de> Message-ID: <20111229142034.059e07a3@shane-desktop> Florian, On Wednesday, 2011-12-28 14:40:02 +0000, Florian Weimer wrote: > >> Just make it opt-in, so that people can decide whether they want > >> to publish their abuse contact point or not. > > > > I thought is already is "opt-in" as the contact enters the > > information with the knowledge it will be published. > > > > If it is opt-in the EU data protection laws do not come into play > > since there is an exemption for those > > that opt-in to their info being published. > > I was surprised when this was announced and I believe RIPE NCC's legal > counsel was and is wrong. It would have been better to advise its > members that they need to make sure that they have consent from the > folks whose data they've submitted to the RIPE NCC for publication. > This is what DENIC did when it was discovered that the WHOIS for > 9.4.e164.arpa, despite being nominally opt-in, was populated by > default with personally identifiable information by several DENIC > members. Perhaps it makes sense to create an explicitly privacy-free form of contact information in the database? While we could re-use the ROLE object type for this, maybe we should be explicit, and make a NON-PERSON-CONTACT-INFORMATION-THAT-THE-WHOLE-INTERNET-CAN-READ object type? ;) -- Shane From fweimer at bfk.de Thu Dec 29 14:30:48 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 29 Dec 2011 13:30:48 +0000 Subject: [anti-abuse-wg] Privacy requirements In-Reply-To: <20111229142034.059e07a3@shane-desktop> (Shane Kerr's message of "Thu, 29 Dec 2011 14:20:34 +0100") References: <11121607343033_5905@oregon.uoregon.edu> <4EEB72D0.8050709@consumer.net> <34B0D91F-4F57-47B7-9D09-EF2E657ED573@blacknight.ie> <4EEB7A18.9040905@consumer.net> <4EEBB8D5.6030204@consumer.net> <4EEC89C6.5000303@tana.it> <4EECC532.2040609@consumer.net> <4EEFA25C.7040602@blacknight.com> <4EEFA4A0.4080305@consumer.net> <1324388763.2338.18.camel@shane-desktop> <4EF09F33.6010804@powerweb.de> <4EF0B6BE.70906@tana.it> <4EF0D4B7.6070103@powerweb.de> <82y5txx993.fsf@mid.bfk.de> <4EFB1F71.4050204@consumer.net> <82aa6cyd31.fsf@mid.bfk.de> <20111229142034.059e07a3@shane-desktop> Message-ID: <82zkebv71z.fsf@mid.bfk.de> * Shane Kerr: > Perhaps it makes sense to create an explicitly privacy-free form of > contact information in the database? Yes, that's one way to achieve opt-in, provided that use of these objects is not required. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99