From brian.nisbet at heanet.ie Mon Jul 16 11:02:29 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 16 Jul 2012 10:02:29 +0100 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension Message-ID: <5003D8A5.9050505@heanet.ie> Colleagues, Thank you all for your discussion on 2011-06, however I will admit that the picture of how the Working Group stands in regards ton consensus is not clear. At various points in time different members of the WG have spoken up, voiced objections, agreed, asked questions or answered questions, but in several circumstances the opinions were still not clear after all the discussion. In order to try to get a clear idea of how to progress and after speaking to the NCC in regards to the PDP I have decided to extend the Review Phase by four weeks to see if that can produce some clarity. I would ask if members could raise any points that they are still uncertain about and state as clearly as possible, their current opinion on the proposal. I would encourage everyone to read the last mails from Tobias and the NCC (in the guise of Denis Walker) as they address a number of points. While I'm hoping we can get a clearer picture in less than four weeks given that we are now in mid-summer, a decent period of time seemed like a good idea. Thanks, Brian, AA-WG Co-Chair From lists at help.org Mon Jul 16 13:28:51 2012 From: lists at help.org (lists at help.org) Date: Mon, 16 Jul 2012 07:28:51 -0400 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5003D8A5.9050505@heanet.ie> References: <5003D8A5.9050505@heanet.ie> Message-ID: <5003FAF3.3010606@help.org> > I will admit that the picture of how the Working Group stands in regards ton consensus is not clear. The discussions between a small group of people on this list has nothing to do with "consensus." 99.99999% of the affected users have no idea about what is happening. Calling this a "concensus" is delusionsal and/or fraudulent. From mschmidt at ripe.net Tue Jul 17 15:25:52 2012 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 17 Jul 2012 15:25:52 +0200 Subject: [anti-abuse-wg] 2011-06 Review Period extended until 13 August 2013 (Abuse Contact Management in the RIPE NCC Database) Message-ID: Dear Colleagues, The Review Period for the proposal 2011-06 has been extended until 13 August 2012. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt on behalf of Policy Development Officer RIPE NCC From mschmidt at ripe.net Wed Jul 18 13:03:22 2012 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 18 Jul 2012 13:03:22 +0200 Subject: [anti-abuse-wg] 2011-06 Review Period extended until *14 August* 2013 (Abuse Contact Management in the RIPE NCC Database) Message-ID: Dear colleagues, Yesterday we announced that the extended Review Period for this policy proposal would end on 13 August 2012. This date was incorrect. The correct end date for the extended Review Period for policy proposal 2011-06 is *14 August* 2012. We encourage you to review this policy proposal and send your comments to . We apologies for any inconvenience this may have caused. Regards, Marco Schmidt on behalf of Policy Development Officer RIPE NCC From axel at ripe.net Mon Jul 23 16:02:19 2012 From: axel at ripe.net (Axel Pawlik) Date: Mon, 23 Jul 2012 16:02:19 +0200 Subject: [anti-abuse-wg] Due Diligence for the Quality of the RIPE NCC Registration Data Message-ID: <500D596B.9070300@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC procedural document, "Due Diligence for the Quality of the RIPE NCC Registration Data", has been published. The document is available at: https://www.ripe.net/ripe/docs/due-diligence The RIPE NCC has a mandate from the RIPE community to keep an up-to-date and correct Internet number resource registry. In order to comply with this mandate, the RIPE NCC performs due diligence on organisations the RIPE NCC registers Internet number resource for. This document outlines the minimum information and documentation the RIPE NCC requires to make sure that the registration data is valid and up-to-date. Regards, Axel Pawlik Managing Director RIPE NCC From lem at isc.org Tue Jul 24 17:34:01 2012 From: lem at isc.org (=?iso-8859-1?Q?Luis_Mu=F1oz?=) Date: Tue, 24 Jul 2012 08:34:01 -0700 Subject: [anti-abuse-wg] Manual vs automated reports Message-ID: Hi there, I've been quickly going through the archives to try to catch up in the discussion after reading the current document. It struck me as odd that the role objects will have a single abuse-mailbox object which should be used to receive both automatic and manual reports. I'm aware of this (related) exchange (from the archives): From Tobias Knecht > > Is it for high volume automated report dissemination (trap or sensor initiated > > identification of "activity")? > > > For this to work it needs automated handling on the receiving side and it should > > be clearly opt-in, so that the receiving entity can prepare for proper processing. > > Disagree from my experience in the anti-abuse industry. First of all > reporting must be easy and receiving reports must be easy as well. [...] > > Second, if you do not want to receive reports from one party, block them > or directly delete them. That is best practice and widely adopted and > really not complicated to do. [...] While this matches my experience -- and I'm sure this will also match with the experience of anybody who has had to handle a large volume anti-abuse operation -- I remember there were times where I wished there was an easier way. The automated reports tend to vastly outnumber the manual reports, which also mix with the loads of spam that are (purposely?) pointed at the abuse contacts. This complicates the task of sifting through the mail flow to direct the complaints into their proper bins for processing. There's also the case of those that don't care about abuse originating from their resources. Those are likely to simply devnull their abuse complaint flow just as they have been doing up until now. I believe that having an optional "auto-abuse-mailbox" object (that is mandatory to use when present) dealing only with automated reports, could help anti-abuse operators (both in the report sending and receiving sides). The automated, high volume generators can decide not to waste resources with entities that do not have the right objects setup (ie, if there's not an auto-abuse-mailbox, do not generate the report) and the entities that are not prepared to deal with automated reports, could signal that to the community by not defining an auto-abuse-mailbox. Note that I still support the notion of a mandatory abuse-mailbox where manual complaints can be sent. At least that takes a way a lot of (guess)work out of figuring out where to send the complaint. Best regards -lem From tk at abusix.com Tue Jul 24 19:37:44 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 24 Jul 2012 19:37:44 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: Message-ID: <500EDD68.7070303@abusix.com> Hi Luis, thanks you for your feedback. > The automated reports tend to vastly outnumber the manual reports, > which also mix with the loads of spam that are (purposely?) pointed > at the abuse contacts. This complicates the task of sifting through > the mail flow to direct the complaints into their proper bins for > processing. Why is that? My experience shows that if you have an institution that is hammering your abuse mailbox with mails you usually first of all look at the content and if the content is good and you like to work with it you already know who this is and could easily move the reports to the right bin. Even on a format base you could easily forward or move ARF, X-ARF, ... reports to the right folders/bin/scripts/... > I believe that having an optional "auto-abuse-mailbox" object (that > is mandatory to use when present) dealing only with automated > reports, could help anti-abuse operators (both in the report sending > and receiving sides). The automated, high volume generators can > decide not to waste resources with entities that do not have the > right objects setup (ie, if there's not an auto-abuse-mailbox, do > not generate the report) and the entities that are not prepared to > deal with automated reports, could signal that to the community by > not defining an auto-abuse-mailbox. That is a good idea, I have thought about something similar already. The main problem I see is that everybody thinks their reports are the most important, which might be right in some cases ;-) So if there is no auto-abuse-mailbox, I'm afraid people will send automatic mails to the abuse-mailbox, which does not help at all. The second point is, that we complicate things for the reporter again. Not the ones that know how to do it, but the ones that are not sure about it. And the third and biggest issue I have with it is the definition. What is automatic and what is not? Having a spamtrap system reporting in ARF for example without any user interaction is clearly automatic. But clicking a spam-button and reporting things in a feedback loop also in ARF is manual? Or automatic? Or something in between? At the end it does not care, since both scenarios are in the same format and probably run through the same scripts or into the same mailbox/folder/bin/... What I was afraid what would happen is that processes that are defined in the abuse department, for example processing of ARF could be impaired by the reporter just by having another definition. Keeping these definitions up2date is not an option, since this will never lead to a consensus and what would happen if somebody just does not care about it? Imho the easier way is to move and forward (Divide) the reports on a receiver side exactly in the way the receiver wants to process (conquer) them. This way the receiver has its processes completely under control. I hope I was able to phrase my concerns in an understandable way. But never the less thank you very much for your input and please feel free to destroy my concerns. Thanks, Tobias From peter at hk.ipsec.se Tue Jul 24 19:59:29 2012 From: peter at hk.ipsec.se (peter h) Date: Tue, 24 Jul 2012 19:59:29 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: Message-ID: <201207241959.30137.peter@hk.ipsec.se> On Tuesday 24 July 2012 17.34, Luis Mu?oz wrote: > Hi there, > > I've been quickly going through the archives to try to catch up in the discussion after reading the current document. It struck me as odd that the role objects will have a single abuse-mailbox object which should be used to receive both automatic and manual reports. I'm aware of this (related) exchange (from the archives): > > >From Tobias Knecht > > > Is it for high volume automated report dissemination (trap or sensor initiated > > > identification of "activity")? > > > > > For this to work it needs automated handling on the receiving side and it should > > > be clearly opt-in, so that the receiving entity can prepare for proper processing. > > > > Disagree from my experience in the anti-abuse industry. First of all > > reporting must be easy and receiving reports must be easy as well. [...] > > > > Second, if you do not want to receive reports from one party, block them > > or directly delete them. That is best practice and widely adopted and > > really not complicated to do. [...] > > > While this matches my experience -- and I'm sure this will also match with the experience of anybody who has > had to handle a large volume anti-abuse operation -- I remember there were times where I wished there was an > easier way. > > The automated reports tend to vastly outnumber the manual reports, which also mix with the loads of spam > that are (purposely?) pointed at the abuse contacts. This complicates the task of sifting through the mail > flow to direct the complaints into their proper bins for processing. There's also the case of those that > don't care about abuse originating from their resources. Those are likely to simply devnull their abuse c > omplaint flow just as they have been doing up until now. > > I believe that having an optional "auto-abuse-mailbox" object (that is mandatory to use when present) > dealing only with automated reports, could help anti-abuse operators (both in the report sending and > receiving sides). The automated, high volume generators can decide not to waste resources with entities > that do not have the right objects setup (ie, if there's not an auto-abuse-mailbox, do not generate the > report) and the entities that are not prepared to deal with automated reports, could signal that to the > community by not defining an auto-abuse-mailbox. This would send the wrong signal to the community ( that we only deal with the easy cases and with less and less resources) Spam has been the plague that it is since ISP's have ignored abuse reports about their customers. The way to reduce work with abuse reports is NOT to ignore some of them ( or make life easier for the abuse staff) but to reduce the amount of abuse originating from it's own adresses. Blacklisting is the only thing that really bites ignorant ISP's, and that's what happens. > > Note that I still support the notion of a mandatory abuse-mailbox where manual complaints can be sent. At > least that takes a way a lot of (guess)work out of figuring out where to send the complaint. > > Best regards > > -lem > > > > > > -- 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 vesely at tana.it Tue Jul 24 20:22:32 2012 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 24 Jul 2012 20:22:32 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: Message-ID: <500EE7E8.8030502@tana.it> On Tue 24/Jul/2012 17:34:01 +0200 Luis Mu?oz wrote: > I believe that having an optional "auto-abuse-mailbox" object (that > is mandatory to use when present) dealing only with automated > reports, could help anti-abuse operators (both in the report > sending and receiving sides). Let me add one consideration to what Tobias wrote: RFC 6650 splits abuse complaints between "solicited" and "unsolicited" ones. Also known as feedback loops, the former can be automated according to the underlying agreement. One can use a different reporting addresses for each subscription. Unsolicited complaints deserve a bit of thought: Who is sending them? Why? When such questions are cleared, the stream of reports from that operator can be directed to the appropriate bin, possibly by negotiating a different address with the report generator. In fact, that is the same as establishing a feedback loop, and it cannot be automated fully for the same reasons why subscriptions to the early kind of feedback loops cannot. See http://tools.ietf.org/html/rfc6650#section-5.5 From rezaf at mindspring.com Tue Jul 24 20:39:44 2012 From: rezaf at mindspring.com (Reza Farzan) Date: Tue, 24 Jul 2012 14:39:44 -0400 (GMT-04:00) Subject: [anti-abuse-wg] Manual vs automated reports Message-ID: <3699943.1343155184587.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> To complement what Alessandro said, it is good that RFC 6650 splits abuse complaints between "solicited" and "unsolicited" ones, even though it may confuse common users. The "solicited" should be reserved for Spam Cop, and other administrators who are trying to report Abuse/Spam activities to a network. The "unsolicited" channel could be like a web form that encourages users to report Abuse/Spam activities to a network like the one that GoDaddy has: https://supportcenter.godaddy.com/Abuse/SpamReport.aspx?ci=22420. This way, the "solicited" channel (abuse at domain-name.com) would remain free of unsolicited inquiries, and network administrators could mange it more efficiently and process legitimate reports promptly. Thank you, Reza Farzan =========== -----Original Message----- >From: Alessandro Vesely >Sent: Jul 24, 2012 2:22 PM >To: anti-abuse-wg at ripe.net >Subject: Re: [anti-abuse-wg] Manual vs automated reports > >On Tue 24/Jul/2012 17:34:01 +0200 Luis Mu?oz wrote: >> I believe that having an optional "auto-abuse-mailbox" object (that >> is mandatory to use when present) dealing only with automated >> reports, could help anti-abuse operators (both in the report >> sending and receiving sides). > >Let me add one consideration to what Tobias wrote: > >RFC 6650 splits abuse complaints between "solicited" and "unsolicited" >ones. Also known as feedback loops, the former can be automated >according to the underlying agreement. One can use a different >reporting addresses for each subscription. > >Unsolicited complaints deserve a bit of thought: Who is sending them? > Why? When such questions are cleared, the stream of reports from >that operator can be directed to the appropriate bin, possibly by >negotiating a different address with the report generator. In fact, >that is the same as establishing a feedback loop, and it cannot be >automated fully for the same reasons why subscriptions to the early >kind of feedback loops cannot. > >See http://tools.ietf.org/html/rfc6650#section-5.5 From jorgen at hovland.cx Tue Jul 24 20:55:33 2012 From: jorgen at hovland.cx (Jørgen Hovland) Date: 24 Jul 2012 18:55:33 +0000 (GMT) Subject: [anti-abuse-wg] Manual vs automated reports Message-ID: <500eefa566c42555770025ef81d5.jorgen@hovland.cx> An HTML attachment was scrubbed... URL: From wiegert at telus.net Tue Jul 24 20:39:01 2012 From: wiegert at telus.net (Arnold) Date: Tue, 24 Jul 2012 11:39:01 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: Message-ID: <500EEBC5.7010804@telus.net> On 24/07/2012 8:34 AM, Luis Mu?oz wrote: > > > The automated reports tend to vastly outnumber the manual reports, which also mix with the loads of spam that are (purposely?) pointed at the abuse contacts. This complicates the task of sifting through the mail flow to direct the complaints into their proper bins for processing. There's also the case of those that don't care about abuse originating from their resources. Those are likely to simply devnull their abuse complaint flow just as they have been doing up until now. If I may, from my perspective as an 'amateur' SPAM reporter of all the ends up in my mailbox, I don't see what difference an additional "auto-abuse-mailbox" would make versus a regular abuse-mailbox. The receivers would still have to do the same work - now on two mail boxes, rather just than one, because for the second 'auto' mailbox to be useful would still depend on everyone's goodwill and cooperation which is exactly what you won't be able to depend on in the world of SPAM :-( > > I believe that having an optional "auto-abuse-mailbox" object (that is mandatory to use when present) dealing only with automated reports, could help anti-abuse operators (both in the report sending and receiving sides). The automated, high volume generators can decide not to waste resources with entities that do not have the right objects setup (ie, if there's not an auto-abuse-mailbox, do not generate the report) and the entities that are not prepared to deal with automated reports, could signal that to the community by not defining an auto-abuse-mailbox. > > Note that I still support the notion of a mandatory abuse-mailbox where manual complaints can be sent. At least that takes a way a lot of (guess)work out of figuring out where to send the complaint. > > Best regards > > -lem Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From tk at abusix.com Wed Jul 25 04:05:28 2012 From: tk at abusix.com (Tobias Knecht) Date: Wed, 25 Jul 2012 04:05:28 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500eefa566c42555770025ef81d5.jorgen@hovland.cx> References: <500eefa566c42555770025ef81d5.jorgen@hovland.cx> Message-ID: <500F5468.3070706@abusix.com> Hi, > I'm not trying to start a discussion about defining solicited. I'm only > trying to tell you that it can't be defined. Therefore you can't in > generally separate complaints into 2 different categories in the ripe db. That is exactly what I meant when I was talking about not being able to find clear definitions. Looking at reports and decide how to handle them is something that has to be done by every receiver on his own. It's a matter of trustbuilding and we should not let the reporter decide what is solicited or unsolicited. Thanks, Tobias From lem at isc.org Wed Jul 25 08:29:55 2012 From: lem at isc.org (=?iso-8859-1?Q?Luis_Mu=F1oz?=) Date: Tue, 24 Jul 2012 23:29:55 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500EDD68.7070303@abusix.com> References: <500EDD68.7070303@abusix.com> Message-ID: <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> On Jul 24, 2012, at 10:37 AM, Tobias Knecht wrote: > Why is that? My experience shows that if you have an institution that is hammering your abuse mailbox with mails you usually first of all look at the content and if the content is good and you like to work with it you already know who this is and could easily move the reports to the right bin. Even on a format base you could easily forward or move ARF, X-ARF, ... reports to the right folders/bin/scripts/... I know this is what I did when my turn came (pre-ARF days). That, and assigning a credibility score to many type of reports, so that we could automatically introduce air-gaps into the appropriate cables so as to stop the malicious traffic with minimal human intervention. Now, to this day and age, we still get to learn about a network whose abuse complaint address is spam-filtered or whatever. They have to resort to this because the humans cannot sift through the amount of traffic. I think having separate addresses (one for automatic, one for manual) would tend to reduce the amount of noise into the channel that is more closely supervised by real people, thus improving chances of the message being seen and acted upon. Of course, this presumes some level of willingness and competence. > That is a good idea, I have thought about something similar already. The main problem I see is that everybody thinks their reports are the most important, which might be right in some cases ;-) Yes, indeed. > So if there is no auto-abuse-mailbox, I'm afraid people will send automatic mails to the abuse-mailbox, which does not help at all. I agree, however that will leave us mostly where we are today -- so the worst case is this, the best case is a win in the overall abuse workflow. > The second point is, that we complicate things for the reporter again. Not the ones that know how to do it, but the ones that are not sure about it. I think we'll just keep educating them -- but we'll have better tools at our disposal. > And the third and biggest issue I have with it is the definition. What is automatic and what is not? Having a spamtrap system reporting in ARF for example without any user interaction is clearly automatic. But clicking a spam-button and reporting things in a feedback loop also in ARF is manual? Or automatic? Or something in between? True, perhaps "automatic" is not the right term -- perhaps "bulk" or "high volume" lends itself to an easier to apply scenario. What I wanted to encode with my choice of words was the fact that the recipient would be getting a large number of reports with similar structure -- either machine readable or not. > At the end it does not care, since both scenarios are in the same format and probably run through the same scripts or into the same mailbox/folder/bin/... Perhaps, perhaps not. We cannot assume anything about the abuse report processing workflow. For instance, you might give more credence to SpamCop reports than to AOL FBLs (or the other way around) so the processing might be different. > Imho the easier way is to move and forward (Divide) the reports on a receiver side exactly in the way the receiver wants to process (conquer) them. This way the receiver has its processes completely under control. > > I hope I was able to phrase my concerns in an understandable way. But never the less thank you very much for your input and please feel free to destroy my concerns. I think your concerns are valid and were easy to understand. I also think that there's value in providing a better mechanism for the receiver. Receivers who want to do everything through a single channel, could set the two addresses to the same value. Receivers who want to action them through separate pipelines, now will have a way to do that. Receivers who prefer not to receive bulk abuse reports, can signal that. Best regards -lem From lem at isc.org Wed Jul 25 08:37:00 2012 From: lem at isc.org (=?iso-8859-1?Q?Luis_Mu=F1oz?=) Date: Tue, 24 Jul 2012 23:37:00 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <201207241959.30137.peter@hk.ipsec.se> References: <201207241959.30137.peter@hk.ipsec.se> Message-ID: <8CE798A9-4938-4F3A-A776-70B05FEDFB73@isc.org> On Jul 24, 2012, at 10:59 AM, peter h wrote: > This would send the wrong signal to the community ( that we only deal with the easy cases > and with less and less resources) Yes, I agree. And perhaps you'll agree with me that ignoring the complaints -- as many do today -- sends an even more powerful signal that ISPs are getting progressively better at detecting and responding to :-) > Spam has been the plague that it is since ISP's have ignored abuse reports about their > customers. The way to reduce work with abuse reports is NOT to ignore some of them ( or > make life easier for the abuse staff) but to reduce the amount of abuse originating from > it's own adresses. > > Blacklisting is the only thing that really bites ignorant ISP's, and that's what happens. I agree. Incompetent (or inactive) ISPs (or ESPs) will get blacklisted regardless of the signaling they send, because the abuse won't stop and the rest of the 'net will get tired of dealing with that. Still, I think there's nothing inherently wrong about having a channel for machine-to-machine (or bulk) reports vs a human-to-human lane. In fact, I believe we can all win as a community if that were an option. Having a broken ISP state "I cannot receive bulk abuse reports" simply could save resources to the complaint-senders, who might then decide to simply escalate to blacklisting faster. Best regards -lem From lists at help.org Wed Jul 25 08:52:37 2012 From: lists at help.org (lists at help.org) Date: Wed, 25 Jul 2012 02:52:37 -0400 Subject: [anti-abuse-wg] Domain Tools whois lawsuit dismissed In-Reply-To: <500D596B.9070300@ripe.net> References: <500D596B.9070300@ripe.net> Message-ID: <500F97B5.6040202@help.org> The Domain Tools lawsuit where they sought to declare that their harvesting and resale of whois information without permission is "lawful" has been dismissed by a US Federal District court judge. The decision is at: http://network-tools.com/domain-Tools-dismissal.pdf The lead attorney for the case is Derek Newman. (He is the attorney who represented mass e-mailers and defended cases brought by James Gordon and had him designated as a "vexatious litigant" and has his personal items sold at auction to pay the legal fees. Newman was also staff counsel to Seattle's "porn king" and boasts how they were good friends in published reports at Wired.com). The lawsuit was brought shortly after a complaint was filed with the privacy office of Canada about the resale of whois data from Tucows (which is in Canada) without permission. As a result the court has been asked to issue sanctions related to anti-SLAPP laws (SLAPP is "Strategic Lawsuit Against Public Participation"). (This is why some people want to post anonymously). Also, there is a post attributed to Paul Keating shortly after the lawsuit was filed (keating is a domain attorney who is on the board of investors of DomainTools.com and who is the managing director of the company that hold the DomainTools trademark) that says things such as: "...So, file an action seeking damages, serve it, claim damages not to exceed $10,000 and wait for a default. Then try to enforce the default. The reason for the damage limit is to force them into a situation of spending more than $10,000 to defend in AZ or default. ..." http://www.thedomains.com/2012/05/30/berryhill-gets-a-finding-of-reverse-domain-name-hijacking-defending-a-udrp-on-elk-com/ As a result of all this the court has been asked to award monetary judgements against Domain Tools and the law firm of Derek Newman AND have them both labeled as "vexatious litigants." There are also five different stories as to who is actually the parent company of Domain Tools so the court has been asked to require Domain Tools to explain the apparent discrepancies on the court record. From vesely at tana.it Wed Jul 25 10:14:21 2012 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 25 Jul 2012 10:14:21 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <3699943.1343155184587.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <3699943.1343155184587.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Message-ID: <500FAADD.1080502@tana.it> On Tue 24/Jul/2012 20:39:44 +0200 Reza Farzan wrote: > To complement what Alessandro said, it is good that RFC 6650 splits > abuse complaints between "solicited" and "unsolicited" ones, even > though it may confuse common users. > > The "solicited" should be reserved for Spam Cop, and other > administrators who are trying to report Abuse/Spam activities to a > network. Perhaps I wasn't clear enough. "Solicited", at least in the sense of RFC 6650, refers to private agreements, e.g. like the one you apply for at http://postmaster.aol.com/SupportRequest.FBL.php . The FBL email address involved in the agreement can be dedicated. Perhaps RFC 6650 could have chosen a better term, but the definition it gives is clear enough: The original, and still by far the most common, application of [RFC5965] is when two mail systems make a private agreement to exchange abuse reports -- usually reports due to recipients manually reporting messages as spam. We refer to these as solicited reports. > The "unsolicited" channel could be like a web form that encourages > users to report Abuse/Spam activities to a network like the one > that GoDaddy has: > https://supportcenter.godaddy.com/Abuse/SpamReport.aspx?ci=22420. Hm... yes. Although explicitly asking for reports looks very much like soliciting them, that form is more similar to an abuse-mailbox published in its own peculiar way, than to an FBL. > This way, the "solicited" channel (abuse at domain-name.com) would > remain free of unsolicited inquiries, and network administrators > could mange it more efficiently and process legitimate reports > promptly. Using an FBL address different from abuse at domain-name.com is a good way to keep it free from other stuff. From vesely at tana.it Wed Jul 25 10:52:23 2012 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 25 Jul 2012 10:52:23 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> Message-ID: <500FB3C7.6070407@tana.it> On Wed 25/Jul/2012 08:29:55 +0200 Luis Mu?oz wrote: > > I also think that there's value in providing a better mechanism for > the receiver. Receivers who want to do everything through a single > channel, could set the two addresses to the same value. I cannot publish something like "Hey, this is my bulk address; this other one is for my mother-in-law only." Well, I could. But, in Arnold's words, using the right address would still depend on everyone's goodwill... > Receivers who want to action them through separate pipelines, now > will have a way to do that. An alternative is to separate the pipelines for each and every report generator. Good abuse reporters may realize that need. They can set up a full blown abuse-reporting web shop, where senders can login, change reporting address, see statistics, and the like. Much like AOL's FBL, except that they send you an auto-subscribe link on the first abuse they report to you, rather than require you to subscribe beforehand. That way, they can run an FBL even if they are not quite the size of AOL. > Receivers who prefer not to receive bulk abuse reports, can signal > that. It is probably more effective to just redirect the abuse-mailbox to /dev/null. From esa.laitinen at iki.fi Wed Jul 25 11:51:11 2012 From: esa.laitinen at iki.fi (Esa Laitinen) Date: Wed, 25 Jul 2012 11:51:11 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500FB3C7.6070407@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> Message-ID: On Wed, Jul 25, 2012 at 10:52 AM, Alessandro Vesely wrote: > An alternative is to separate the pipelines for each and every report > generator. Good abuse reporters may realize that need. They can set > > Well, it is pretty trivial to separate the e-mail to abuse at mydomain from yahoodle.com (or any other sender) without any intervention from the reporter, so I really fail to see the need for separate addresses for various reporters. But it might be also my lack of imagination. -- Mr. Esa Laitinen Tel. +41 76 200 2870 skype/yahoo: reunaesa Blog: http://happiloppuuahistaa.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at abusix.com Wed Jul 25 12:17:13 2012 From: tk at abusix.com (Tobias Knecht) Date: Wed, 25 Jul 2012 12:17:13 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> Message-ID: <500FC7A9.3010602@abusix.com> Hi everybody, >> So if there is no auto-abuse-mailbox, I'm afraid people will send >> automatic mails to the abuse-mailbox, which does not help at all. > > I agree, however that will leave us mostly where we are today -- so > the worst case is this, the best case is a win in the overall abuse > workflow. I do not agree. Hoping for win where risk can already be foreseen is imho not a good idea. The intent of the proposal is to make it easier for both receivers to publish their information and reporters to find the right information without any decision making involved. Having 2 per fuzzy definitions divided email addresses does not make things any easier neither for the reporter nor for the receiver. And since both addresses will be published you will end up again in receiving spam on both addresses which destroys the benefit of it. The overall workflow is defined by the receiver. And how difficult is it to setup a few filters to move things into the right bin? It's what people do today and what people can adjust easily by themselves. Much more easy than write an email and hope for response to some reporter who has a different view or not understand the fuzzy definitions. >> The second point is, that we complicate things for the reporter >> again. Not the ones that know how to do it, but the ones that are >> not sure about it. > > I think we'll just keep educating them -- but we'll have better tools > at our disposal. For education you need clear definitions and even then you'll run into things that can not be cleared up 100%. >> And the third and biggest issue I have with it is the definition. >> What is automatic and what is not? Having a spamtrap system >> reporting in ARF for example without any user interaction is >> clearly automatic. But clicking a spam-button and reporting things >> in a feedback loop also in ARF is manual? Or automatic? Or >> something in between? > > True, perhaps "automatic" is not the right term -- perhaps "bulk" or > "high volume" lends itself to an easier to apply scenario. What I > wanted to encode with my choice of words was the fact that the > recipient would be getting a large number of reports with similar > structure -- either machine readable or not. To come back to definitions. Sorry for that ;-) What is high volume? What is the same structure? Only the same formats? Or the same incident type? Clearing up these definitions is not possible because of the different views of receivers and reporters. It's the same discussion as about trustworthiness of reporters. It's a personal subjective view. >> At the end it does not care, since both scenarios are in the same >> format and probably run through the same scripts or into the same >> mailbox/folder/bin/... > > Perhaps, perhaps not. We cannot assume anything about the abuse > report processing workflow. For instance, you might give more > credence to SpamCop reports than to AOL FBLs (or the other way > around) so the processing might be different. Right so the data sending part is the same and every receiver has to decide how he wants to process and has to build these mechanisms in the way he likes most. And he can change these processes as often as he wants. And he can be sure, that there is exactly one way that is not changing which is how he will get the information he needs. >> Imho the easier way is to move and forward (Divide) the reports on >> a receiver side exactly in the way the receiver wants to process >> (conquer) them. This way the receiver has its processes completely >> under control. >> >> I hope I was able to phrase my concerns in an understandable way. >> But never the less thank you very much for your input and please >> feel free to destroy my concerns. > > I think your concerns are valid and were easy to understand. I also > think that there's value in providing a better mechanism for the > receiver. Receivers who want to do everything through a single > channel, could set the two addresses to the same value. Receivers who > want to action them through separate pipelines, now will have a way > to do that. I do not see the advantage since there are the tools (filters, abuse handling software, ...) that takes care of this and make things more complicated on another part. Make it simple and keep it simple is imho more important than hoping for a benefit that might never exist. > Receivers who prefer not to receive bulk abuse reports, > can signal that. And this is not an option imho. Which has partly to do with European law, which would go to far now. Thanks, Tobias From vesely at tana.it Wed Jul 25 13:20:52 2012 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 25 Jul 2012 13:20:52 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> Message-ID: <500FD694.6060005@tana.it> On Wed 25/Jul/2012 11:51:11 +0200 Esa Laitinen wrote: > On Wed, Jul 25, 2012 at 10:52 AM, Alessandro Vesely wrote: > >> An alternative is to separate the pipelines for each and every report >> generator. Good abuse reporters may realize that need. > > Well, it is pretty trivial to separate the e-mail to > abuse at mydomain from yahoodle.com (or any other sender) without any > intervention from the reporter, so I really fail to see the need > for separate addresses for various reporters. Well, you need to have received a report from yahoodle.com before you can separate it from the rest. You also need some authentication scheme to ascertain the sender's identity, so it is not so trivial after all. OTOH, asking for the reporter's intervention lets them know that you received their complaint and are doing something about it. From tk at abusix.com Wed Jul 25 14:03:34 2012 From: tk at abusix.com (Tobias Knecht) Date: Wed, 25 Jul 2012 14:03:34 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500FD694.6060005@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> Message-ID: <500FE096.90303@abusix.com> Hi, > Well, you need to have received a report from yahoodle.com before you > can separate it from the rest. You also need some authentication > scheme to ascertain the sender's identity, so it is not so trivial > after all. This is part of the trust building process you have to do anyway. No abuse department would ever trust unknown reports blindly. And in either ways (one or two abuse-mailbox attributes) you have to proof authentication. But this is now sliding away from the main topic. The point I would make here is, that there are techniques in place that can separate reports and that can proof authentication and that abuse departments can or should use them and not not using these techniques and make things more complicated for the reporter. We have to differentiate another thing as well. We are talking here about reports that are not opt-in. So if an abuse department wants to receive all feedbackloops on a dedicated email address, they can do so, because they have the right to choose while subscribing. But it does not make any sense to publish this dedicated address in whois. > OTOH, asking for the reporter's intervention lets them know that you > received their complaint and are doing something about it. I'm not 100% sure if I completely understood what you want to say with that. If we have the case of 2 email addresses and an reporter sends them to the by receiver subjectively wrong address and the receiver contacts the reporter to tell him to send it to another address this shows that he is doing something about it? If it's that what you meant I can't follow this logic. The receiver could tell the sender to send it to another address which is dev-nulled (which the receiver will obviously not mention). And why should we build in this hoop for receivers and make it harder for them, force them to start discussions about the right address and waste time on that when they can easily separate things technically in their system? Thank, Tobias From thor.kottelin at turvasana.com Wed Jul 25 14:20:57 2012 From: thor.kottelin at turvasana.com (Thor Kottelin) Date: Wed, 25 Jul 2012 15:20:57 +0300 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500FE096.90303@abusix.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> Message-ID: > -----Original Message----- > From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- > bounces at ripe.net] On Behalf Of Tobias Knecht > Sent: Wednesday, July 25, 2012 3:04 PM > To: Alessandro Vesely; anti-abuse-wg at ripe.net > The point I would > make > here is, that there are techniques in place that can separate > reports > and that can proof authentication and that abuse departments can or > should use them I agree, especially as many reporters anyhow seem to use every @-containing string their Whois lookup returns. -- Thor Kottelin http://www.anta.net/ From vesely at tana.it Wed Jul 25 15:28:04 2012 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 25 Jul 2012 15:28:04 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500FE096.90303@abusix.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> Message-ID: <500FF464.6050803@tana.it> On Wed 25/Jul/2012 14:03:34 +0200 Tobias Knecht wrote: > > [...] But it does not make any sense to publish this dedicated > address in whois. Yup. Neither whois nor any other publicly accessible place... >> OTOH, asking for the reporter's intervention lets them know that you >> received their complaint and are doing something about it. > > I'm not 100% sure if I completely understood what you want to say with > that. If we have the case of 2 email addresses and an reporter sends > them to the by receiver subjectively wrong address and the receiver > contacts the reporter to tell him to send it to another address this > shows that he is doing something about it? If it's that what you meant > I can't follow this logic. The receiver could tell the sender to send > it to another address which is dev-nulled (which the receiver will > obviously not mention). No, I didn't mean that. After a reporter sent a complaint to my only abuse-mailbox address, I can set up a bin to handle further reports of the same kind. Rather than relying on software to discriminate reports, I can set up a new, dedicated address and connect it to that bin directly. Then, I'd ask the reporter to please send further reports to such address. That assumes they will store my data, recognize "my" mail, and send any related complaints straightaway. They get better automation, as well as I. In addition, we will have exchanged our contacts during the intercourse, and sketched an outline of reciprocal trust. From michele at blacknight.ie Wed Jul 25 15:32:32 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 25 Jul 2012 13:32:32 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, Message-ID: If they send reports to $random addresses they don't really deserve a response Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 25 Jul 2012, at 13:21, "Thor Kottelin" wrote: >> -----Original Message----- >> From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- >> bounces at ripe.net] On Behalf Of Tobias Knecht >> Sent: Wednesday, July 25, 2012 3:04 PM >> To: Alessandro Vesely; anti-abuse-wg at ripe.net > >> The point I would >> make >> here is, that there are techniques in place that can separate >> reports >> and that can proof authentication and that abuse departments can or >> should use them > > I agree, especially as many reporters anyhow seem to use every @-containing > string their Whois lookup returns. > > -- > Thor Kottelin > http://www.anta.net/ > > > From ripe-anti-spam-wg at powerweb.de Wed Jul 25 15:52:19 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Wed, 25 Jul 2012 15:52:19 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, Message-ID: <500FFA13.2030307@powerweb.de> "Michele Neylon :: Blacknight" wrote: Hi all, > If they send reports to $random addresses they don't really deserve a response Thats a true word for prefessionals, but not for not-so-skilled reporter, that are happy to find out, that there is something like RIPE and a whois showing them who is responsible for a resource, if they get abused. Anyway, I like the proposal to stay like it is with one address. Its up to the receiver to sort incoming mails, automation is easy, procmail and ticketsystems are the admins friend ... One single address (that is mandatory and will exist for every object) will make it much more easy for not-skilled users to simply report only to this address, especially, when they get whatever response or at least can see, they their reports do not bounce (and I guess that there will be less bounces. ISPs that take repsonsibility, will read them, the others will send them to devnull, but most will actually accept them and keep the address working, because they must fear, that the NCC will test them one day). Its up to the community to communicate, that reports should ONLY go to this address (and maybe up to the NCC to supply tools online, that only return the abuse-c email address). A simple "Got abused from our services ? Enter the IP here and see whos responsible" on every ISPs webpage, imprint and on www.ripe.net will surely help a lot ... Kind regards, Frank > > Mr. Michele Neylon > Blacknight > http://Blacknight.tel > > Via iPhone so excuse typos and brevity > > On 25 Jul 2012, at 13:21, "Thor Kottelin" wrote: > >>> -----Original Message----- >>> From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg- >>> bounces at ripe.net] On Behalf Of Tobias Knecht >>> Sent: Wednesday, July 25, 2012 3:04 PM >>> To: Alessandro Vesely; anti-abuse-wg at ripe.net >> >>> The point I would >>> make >>> here is, that there are techniques in place that can separate >>> reports >>> and that can proof authentication and that abuse departments can or >>> should use them >> >> I agree, especially as many reporters anyhow seem to use every @-containing >> string their Whois lookup returns. >> >> -- >> Thor Kottelin >> http://www.anta.net/ >> >> >> > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 wiegert at telus.net Wed Jul 25 17:23:50 2012 From: wiegert at telus.net (Arnold) Date: Wed, 25 Jul 2012 08:23:50 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <500FFA13.2030307@powerweb.de> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de> Message-ID: <50100F86.4000106@telus.net> On 25/07/2012 6:52 AM, Frank Gadegast wrote: > "Michele Neylon :: Blacknight" wrote: > > Hi all, > >> If they send reports to $random addresses they don't >> really deserve a response > > Thats a true word for prefessionals, but not for > not-so-skilled > reporter, that are happy to find out, that there is > something like RIPE > and a whois showing them who is responsible for a > resource, if they > get abused. I have to agree with this. As a purely 'amateur' reporter, The WhoIs record is all I can rely on as an _officially_ published record to report my complaint. There are other ways, but none are as easy to use and as official. If the people responsible for reducing SPAM won't do anything to make it easier by at least enforcing a proper abuse address in the expected and designated place, then it makes the job of reporting and reducing SPAM that much harder. No matter what you will do, publishing any address opens the door to receiving SPAM, but ... why complain about it; use the information provided by this SPAM in the same way you expect any other user to use it - except you won't need me to report it to you :-) Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From michele at blacknight.ie Wed Jul 25 17:39:49 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 25 Jul 2012 15:39:49 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50100F86.4000106@telus.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>,<50100F86.4000106@telus.net> Message-ID: <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> Arnold Do a Whois lookup on any IP in As39122 You should see an abuse contact.... Yet we still get reports sent to accounts@ sales@ etc., Regards Michele Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 25 Jul 2012, at 16:25, "Arnold" wrote: > On 25/07/2012 6:52 AM, Frank Gadegast wrote: >> "Michele Neylon :: Blacknight" wrote: >> >> Hi all, >> >>> If they send reports to $random addresses they don't really deserve a response >> >> Thats a true word for prefessionals, but not for not-so-skilled >> reporter, that are happy to find out, that there is something like RIPE >> and a whois showing them who is responsible for a resource, if they >> get abused. > I have to agree with this. > As a purely 'amateur' reporter, The WhoIs record is all I can rely on > as an _officially_ published record to report my complaint. > There are other ways, but none are as easy to use and as official. > > If the people responsible for reducing SPAM won't do anything to make > it easier by at least enforcing a proper abuse address in the expected > and designated place, then it makes the job of reporting and reducing > SPAM that much harder. > > No matter what you will do, publishing any address opens the door to > receiving SPAM, but ... why complain about it; use the information > provided by this SPAM in the same way you expect any other user > to use it - except you won't need me to report it to you :-) > > Arnold > > -- > Fight Spam - report it with wxSR > http://www.columbinehoney.net/wxSR.shtml > > From wiegert at telus.net Wed Jul 25 18:32:33 2012 From: wiegert at telus.net (Arnold) Date: Wed, 25 Jul 2012 09:32:33 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> Message-ID: <50101FA1.7020403@telus.net> On 25/07/2012 8:39 AM, "Michele Neylon :: Blacknight" wrote: > Arnold > Do a Whois lookup on any IP in As39122 > You should see an abuse contact.... Hello Michele, Using: http://whois.domaintools.com/as39122.net I cannot find any abuse contact in the whois record ============== domain: AS39122.NET expires: 2013-01-25 modified: 2011-07-25 14:22:27 owner-contact-id: 2 owner-name: Blacknight Hostmaster owner-organisation: Blacknight Internet Solutions Ltd. owner-email: owner-voice: +353.599183072 owner-fax: +353.599164239 owner-addr: Unit 12a, Barrowside Business Park owner-addr: Sleaty Road owner-city: Graiguecullen owner-province: Co. Carlow owner-postcode: - owner-country: IE admin-contact-id: 2 admin-name: Blacknight Hostmaster admin-organisation: Blacknight Internet Solutions Ltd. admin-email: admin-voice: +353.599183072 admin-fax: +353.599164239 admin-addr: Unit 12a, Barrowside Business Park admin-addr: Sleaty Road admin-city: Graiguecullen admin-province: Co. Carlow admin-postcode: - admin-country: IE tech-contact-id: 2 tech-name: Blacknight Hostmaster tech-organisation: Blacknight Internet Solutions Ltd. tech-email: tech-voice: +353.599183072 tech-fax: +353.599164239 tech-addr: Unit 12a, Barrowside Business Park tech-addr: Sleaty Road tech-city: Graiguecullen tech-province: Co. Carlow tech-postcode: - tech-country: IE billing-contact-id: 2 billing-name: Blacknight Hostmaster billing-organisation: Blacknight Internet Solutions Ltd. billing-email: billing-voice: +353.599183072 billing-fax: +353.599164239 billing-addr: Unit 12a, Barrowside Business Park billing-addr: Sleaty Road billing-city: Graiguecullen billing-province: Co. Carlow billing-postcode: - billing-country: IE nameserver: NS.BLACKNIGHTSOLUTIONS.COM nameserver: NS2.BLACKNIGHTSOLUTIONS.COM registrar-of-record: Blacknight Internet Solutions Ltd. service-provider: Blacknight Internet Solutions Ltd. service-provider-email: service-provider-control-panel: https://cp.blacknight.com/ ============== In fact, sales is the only e-mail address I can find, so no wonder the SPAM reports end up there. When I went to AS39122.net, it seems most of the links are broken and I was unable to check out much about the services the site seems/claims to provide :-( > Yet we still get reports sent to accounts@ sales@ etc., Not by me, though :-) But, .... see above Or did I miss something or misunderstand your message? Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.ie Wed Jul 25 18:37:30 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Wed, 25 Jul 2012 16:37:30 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50101FA1.7020403@telus.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>,<50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> Message-ID: Arnold I was referring to our AS number and IPs on our network, not to a website or to a domain name. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ________________________________ From: Arnold [wiegert at telus.net] Sent: 25 July 2012 17:32 To: "Michele Neylon :: Blacknight" Cc: anti-abuse-wg at ripe.net Subject: Re: [anti-abuse-wg] Manual vs automated reports On 25/07/2012 8:39 AM, "Michele Neylon :: Blacknight" wrote: Arnold Do a Whois lookup on any IP in As39122 You should see an abuse contact.... Hello Michele, Using: http://whois.domaintools.com/as39122.net I cannot find any abuse contact in the whois record ============== domain: AS39122.NET expires: 2013-01-25 modified: 2011-07-25 14:22:27 owner-contact-id: 2 owner-name: Blacknight Hostmaster owner-organisation: Blacknight Internet Solutions Ltd. owner-email: owner-voice: +353.599183072 owner-fax: +353.599164239 owner-addr: Unit 12a, Barrowside Business Park owner-addr: Sleaty Road owner-city: Graiguecullen owner-province: Co. Carlow owner-postcode: - owner-country: IE admin-contact-id: 2 admin-name: Blacknight Hostmaster admin-organisation: Blacknight Internet Solutions Ltd. admin-email: admin-voice: +353.599183072 admin-fax: +353.599164239 admin-addr: Unit 12a, Barrowside Business Park admin-addr: Sleaty Road admin-city: Graiguecullen admin-province: Co. Carlow admin-postcode: - admin-country: IE tech-contact-id: 2 tech-name: Blacknight Hostmaster tech-organisation: Blacknight Internet Solutions Ltd. tech-email: tech-voice: +353.599183072 tech-fax: +353.599164239 tech-addr: Unit 12a, Barrowside Business Park tech-addr: Sleaty Road tech-city: Graiguecullen tech-province: Co. Carlow tech-postcode: - tech-country: IE billing-contact-id: 2 billing-name: Blacknight Hostmaster billing-organisation: Blacknight Internet Solutions Ltd. billing-email: billing-voice: +353.599183072 billing-fax: +353.599164239 billing-addr: Unit 12a, Barrowside Business Park billing-addr: Sleaty Road billing-city: Graiguecullen billing-province: Co. Carlow billing-postcode: - billing-country: IE nameserver: NS.BLACKNIGHTSOLUTIONS.COM nameserver: NS2.BLACKNIGHTSOLUTIONS.COM registrar-of-record: Blacknight Internet Solutions Ltd. service-provider: Blacknight Internet Solutions Ltd. service-provider-email: service-provider-control-panel: https://cp.blacknight.com/ ============== In fact, sales is the only e-mail address I can find, so no wonder the SPAM reports end up there. When I went to AS39122.net, it seems most of the links are broken and I was unable to check out much about the services the site seems/claims to provide :-( Yet we still get reports sent to accounts@ sales@ etc., Not by me, though :-) But, .... see above Or did I miss something or misunderstand your message? Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Wed Jul 25 18:43:15 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 25 Jul 2012 09:43:15 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>,<50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34185DA5DE3C73@EXVPMBX100-1.exc.icann.org> Michele Neylon wrote: [.] > I was referring to our AS number and IPs on our network, not to a website or to a domain name. Nonetheless, I think this highlights how ordinary Internet users search and use information. I think it shows the futility of trying to push any kind of filtering out to the reporters. Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5488 bytes Desc: not available URL: From wiegert at telus.net Wed Jul 25 19:43:10 2012 From: wiegert at telus.net (Arnold) Date: Wed, 25 Jul 2012 10:43:10 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> Message-ID: <5010302E.1030103@telus.net> On 25/07/2012 9:37 AM, "Michele Neylon :: Blacknight" wrote: > Arnold > > I was referring to our AS number and IPs on our network, > not to a website or to a domain name. Sorry, I misunderstood. Once I looked up AS39122, I did find the abuse address As I said, I'm merely an 'amateur' who receives SPAM and want to do something about it, but ... it is just as difficult for me to see how I go from a SPAM message to an AS#### with any sort of ease Is there any way to get access to the RIPE data? Currently I use IANA databases, which I download to my local machine and search with my homebrew SPAM reporter. Anything equivalent from RIPE, & searchable so I can go from the IP address to find the abuse address would be very welcome. If anything like it exists already, I haven't found it, but would be most interested in further details. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at abusix.com Wed Jul 25 19:59:54 2012 From: tk at abusix.com (Tobias Knecht) Date: Wed, 25 Jul 2012 19:59:54 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34185DA5DE3C73@EXVPMBX100-1.exc.icann.org> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <41F6C547EA49EC46B4EE1EB2BC2F34185DA5DE3C73@EXVPMBX100-1.exc.icann.org> Message-ID: <5010341A.1020403@abusix.com> Hi, > Nonetheless, I think this highlights how ordinary Internet users search and > use information. I think it shows the futility of trying to push any kind of > filtering out to the reporters. I couldn't agree more. Tobias From denis at ripe.net Thu Jul 26 11:01:09 2012 From: denis at ripe.net (Denis Walker) Date: Thu, 26 Jul 2012 11:01:09 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <5010302E.1030103@telus.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> Message-ID: <50110755.6000204@ripe.net> Dear Arnold From the RIPE NCC website you can find an Abuse Finder tool http://apps.db.ripe.net/search/abuse-finder.html This is a first iteration of a user tool to help with finding abuse contact information in the RIPE Database. It tries to find the abuse contact(s) for an Internet resource on a 'best effort' basis. One of the difficulties of automating this process at the moment is many abuse contacts are in "remarks:" attributes. These cannot be parsed by a script with any degree of confidence. This was one of the starting points from which the 2011-06 policy proposal originated. Regards Denis Walker Business Analyst RIPE NCC Database Group On 25/07/2012 19:43, Arnold wrote: > On 25/07/2012 9:37 AM, "Michele Neylon :: Blacknight" wrote: >> Arnold >> >> I was referring to our AS number and IPs on our network, not to a >> website or to a domain name. > Sorry, I misunderstood. > > Once I looked up AS39122, I did find the abuse address > > As I said, I'm merely an 'amateur' who receives SPAM and > want to do something about it, but ... it is just as difficult for me > to see how I go from a SPAM message to an AS#### with any > sort of ease > > Is there any way to get access to the RIPE data? > > Currently I use IANA databases, which I download to my local machine > and search with my homebrew SPAM reporter. > > Anything equivalent from RIPE, & searchable so I can go from the IP > address to find the abuse address would be very welcome. > > If anything like it exists already, I haven't found it, but would be most > interested in further details. > > Arnold > > -- > Fight Spam - report it with wxSR > http://www.columbinehoney.net/wxSR.shtml > From michele at blacknight.ie Thu Jul 26 12:17:16 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 26 Jul 2012 10:17:16 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50110755.6000204@ripe.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: On 26 Jul 2012, at 10:01, Denis Walker wrote: > Dear Arnold > > From the RIPE NCC website you can find an Abuse Finder tool > http://apps.db.ripe.net/search/abuse-finder.html > > This is a first iteration of a user tool to help with finding abuse contact information in the RIPE Database. It tries to find the abuse contact(s) for an Internet resource on a 'best effort' basis. > > One of the difficulties of automating this process at the moment is many abuse contacts are in "remarks:" attributes. These cannot be parsed by a script with any degree of confidence. This was one of the starting points from which the 2011-06 policy proposal originated. Denis I tried that now. It's very confusing. It's not at all clear if the search box will take an IP address or not .. I tried one and got back a "result" which I could click on .. When I did I got "ERROR:115: invalid search key" > Regards Michele Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ http://blacknight.cat http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 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 ripe-anti-spam-wg at powerweb.de Thu Jul 26 12:34:55 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Thu, 26 Jul 2012 12:34:55 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: <50111D4F.1010005@powerweb.de> "Michele Neylon :: Blacknight" wrote: > > On 26 Jul 2012, at 10:01, Denis Walker > wrote: > >> Dear Arnold >> >> From the RIPE NCC website you can find an Abuse Finder tool >> http://apps.db.ripe.net/search/abuse-finder.html >> >> This is a first iteration of a user tool to help with finding abuse contact information in the RIPE Database. It tries to find the abuse contact(s) for an Internet resource on a 'best effort' basis. >> >> One of the difficulties of automating this process at the moment is many abuse contacts are in "remarks:" attributes. These cannot be parsed by a script with any degree of confidence. This was one of the starting points from which the 2011-06 policy proposal originated. > > > Denis > > I tried that now. It's very confusing. > > It's not at all clear if the search box will take an IP address or not .. Yes, thats true. There should be simple version directly on RIPEs homepage. "Got abused ? Enter IP or hostname here to find the right contact ->" And the more advanced version should be hidden behind an "Advanced search" link. Kind regards, Frank > > I tried one and got back a "result" which I could click on .. When I did I got "ERROR:115: invalid search key" >> > Regards > > Michele > > > Mr Michele Neylon > Blacknight Solutions ? > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.co > http://blog.blacknight.com/ > http://blacknight.cat > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > 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 > > > > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 aftab.siddiqui at gmail.com Thu Jul 26 12:49:52 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 26 Jul 2012 15:49:52 +0500 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> <500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: Hi Michele > > I tried that now. It's very confusing. > Agree to that. > > It's not at all clear if the search box will take an IP address or not .. > Should be mentioned clearly with ? box > > I tried one and got back a "result" which I could click on .. When I did I > got "ERROR:115: invalid search key" > Yes, you are right. It happens many times. I guess it is still in beta phase. We have found an easy way to do it. I guess that legit curl -i -H "Accept: application/json" http://apps.db.ripe.net/whois/use-cases/abuse-ripe&primary-key=+62.239.237.250| grep abuse-mail Just pass the abuser IP (here I've mentioned bt subnet and thats it. Its just a work around. Regards, Aftab A. Siddiqui -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Thu Jul 26 12:51:38 2012 From: denis at ripe.net (Denis Walker) Date: Thu, 26 Jul 2012 12:51:38 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: <5011213A.60002@ripe.net> On 26/07/2012 12:17, "Michele Neylon :: Blacknight" wrote: > > On 26 Jul 2012, at 10:01, Denis Walker > wrote: > >> Dear Arnold >> >> From the RIPE NCC website you can find an Abuse Finder tool >> http://apps.db.ripe.net/search/abuse-finder.html >> >> This is a first iteration of a user tool to help with finding abuse contact information in the RIPE Database. It tries to find the abuse contact(s) for an Internet resource on a 'best effort' basis. >> >> One of the difficulties of automating this process at the moment is many abuse contacts are in "remarks:" attributes. These cannot be parsed by a script with any degree of confidence. This was one of the starting points from which the 2011-06 policy proposal originated. > > > Denis > > I tried that now. It's very confusing. > > It's not at all clear if the search box will take an IP address or not .. That is a good point. People 'within the registration business' know what an Internet resource is and know what we mean by primary key. To more general users (including the public), these terms may not mean anything. In fact 'key' may even be interpreted as 'password'. We will make that more clear. > > I tried one and got back a "result" which I could click on .. When I did I got "ERROR:115: invalid search key" This works OK for me. What address did you search on? regards denis >> > Regards > > Michele > > > Mr Michele Neylon > Blacknight Solutions ? > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.co > http://blog.blacknight.com/ > http://blacknight.cat > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > 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 michele at blacknight.ie Thu Jul 26 12:55:35 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 26 Jul 2012 10:55:35 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> <500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: On 26 Jul 2012, at 11:49, Aftab Siddiqui wrote: > > Hi Michele > > I tried that now. It's very confusing. > Agree to that. > > > It's not at all clear if the search box will take an IP address or not .. > > Should be mentioned clearly with ? box I looked at that and got even more confused :) > > > I tried one and got back a "result" which I could click on .. When I did I got "ERROR:115: invalid search key" > > Yes, you are right. It happens many times. I guess it is still in beta phase. We have found an easy way to do it. I guess that legit > > curl -i -H "Accept: application/json" http://apps.db.ripe.net/whois/use-cases/abuse-ripe&primary-key=+62.239.237.250 | grep abuse-mail > > Just pass the abuser IP (here I've mentioned bt subnet and thats it. Its just a work around. > > Regards, > > Aftab A. Siddiqui > Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ http://blacknight.cat http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 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 rezaf at mindspring.com Thu Jul 26 13:23:09 2012 From: rezaf at mindspring.com (Reza Farzan) Date: Thu, 26 Jul 2012 07:23:09 -0400 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com><07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org><500FB3C7.6070407@tana.it><500FD694.6060005@tana.it> <500FE096.90303@abusix.com><500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net><2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com><50101FA1.7020403@telus.net><5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: Hello All, I just checked the IP in question, 62.239.237.250 in Whois and there is nothing confusing about it, especially the Abuse reporting channel. inetnum: 62.239.237.0 - 62.239.237.255 remarks: Please send abuse notification to mailto:btcertcc at bt.com role: BT Corporate Registry address: British Telecommunications address: 81 Newgate Street address: London GB e-mail: ip.manager at bt.com remarks: trouble: mailto: mailto:btcertcc at bt.com And they have even listed the contact for their security related issues: remarks: BT Security Computer Emergency Response Team mnt-by: BTENT-MNT changed: mailto:steve.a.marshall at bt.com ++++ Cheers, Reza Farzan rezaf at mindspring.com ________________________________ From: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Aftab Siddiqui Sent: Thursday, July 26, 2012 6:50 AM To: Michele Neylon :: Blacknight Cc: Denis Walker; anti-abuse-wg at ripe.net Subject: Re: [anti-abuse-wg] Manual vs automated reports Hi Michele I tried that now. It's very confusing. Agree to that. It's not at all clear if the search box will take an IP address or not ... Should be mentioned clearly with ? box I tried one and got back a "result" which I could click on .. When I did I got "ERROR:115: invalid search key" Yes, you are right. It happens many times. I guess it is still in beta phase. We have found an easy way to do it. I guess that legit curl -i -H "Accept: application/json" http://apps.db.ripe.net/whois/use-cases/abuse-ripe&primary-key=+62.239.237.2 50 | grep abuse-mail Just pass the abuser IP (here I've mentioned bt subnet and thats it. Its just a work around. Regards, Aftab A. Siddiqui From denis at ripe.net Thu Jul 26 15:02:00 2012 From: denis at ripe.net (Denis Walker) Date: Thu, 26 Jul 2012 15:02:00 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com><07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org><500FB3C7.6070407@tana.it><500FD694.6060005@tana.it> <500FE096.90303@abusix.com><500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net><2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com><50101FA1.7020403@telus.net><5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: <50113FC8.1040508@ripe.net> Dear Reza This is a nice example illustrating why the situation IS confused. With some knowledge of the RIPE Database you can dig in and see what you find. But there are three different ways of recording abuse contact information in the database and these can be used in many different object types. To find this information you need to look into objects referenced in objects referenced in....referenced in the object you are interested in. If you don't follow this chain of references far enough you may miss the contact details. If you follow it too far you find abuse contacts not intended for this resource. The information you show below includes a "remarks:" attribute with an abuse email address. This is human readable and in English. If this comment was written in another of the many languages used within the RIPE region, could you be sure it was an abuse email address? This object also has a long since deprecated "trouble:" attribute. If that had been a different email address, where is the dividing line between abuse from and trouble with an IP address? There is also an "e-mail:" attribute. Should you cc: that, just to be sure? I notice you also included the "changed:" attribute in your selection from the object and in the context of 'security related issues'. The changed details are purely administrative, virtually un-maintained and may be years out of date. It may be telling you who changed this object ten years ago. If you put this IP address in our Abuse Finder tool it also returns the abuse contact abuse at bt.net which is missing from the details below. But finding these details by script is not easy. We can program in the relationships between different objects, which is how we found abuse at bt.net. But we cannot parse any comment as we don't know what language it is in and we can't interpret a set of words around an email address. If the policy proposal 2011-06 is approved by the community we can work towards storing abuse contact details in one location, referenced in one way and easily readable by humans and scripts. Of course it won't solve all problems, as some people were hoping for. But it is the first step of what can be a journey towards a more complete solution. Regards Denis Walker Business Analyst RIPE NCC Database Group On 26/07/2012 13:23, Reza Farzan wrote: > Hello All, > > I just checked the IP in question, 62.239.237.250 in Whois and there is > nothing confusing about it, especially the Abuse reporting channel. > > > inetnum: 62.239.237.0 - 62.239.237.255 > remarks: Please send abuse notification to mailto:btcertcc at bt.com > role: BT Corporate Registry > address: British Telecommunications > address: 81 Newgate Street > address: London GB > e-mail: ip.manager at bt.com > remarks: trouble: mailto: mailto:btcertcc at bt.com > > > And they have even listed the contact for their security related issues: > > remarks: BT Security Computer Emergency Response Team > mnt-by: BTENT-MNT > changed: mailto:steve.a.marshall at bt.com > > ++++ > > Cheers, > > > Reza Farzan > rezaf at mindspring.com > > > > ________________________________ > > From: anti-abuse-wg-bounces at ripe.net > [mailto:anti-abuse-wg-bounces at ripe.net] On Behalf Of Aftab Siddiqui > Sent: Thursday, July 26, 2012 6:50 AM > To: Michele Neylon :: Blacknight > Cc: Denis Walker; anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] Manual vs automated reports > > > > Hi Michele > > > > I tried that now. It's very confusing. > > > Agree to that. > > > > It's not at all clear if the search box will take an IP > address or not ... > > > > Should be mentioned clearly with ? box > > > > I tried one and got back a "result" which I could click on > .. When I did I got "ERROR:115: invalid search key" > > > > Yes, you are right. It happens many times. I guess it is still in > beta phase. We have found an easy way to do it. I guess that legit > > curl -i -H "Accept: application/json" > http://apps.db.ripe.net/whois/use-cases/abuse-ripe&primary-key=+62.239.237.2 > 50 | grep abuse-mail > > Just pass the abuser IP (here I've mentioned bt subnet and thats it. > Its just a work around. > > Regards, > > Aftab A. Siddiqui > > > > > From peter at hk.ipsec.se Thu Jul 26 16:26:07 2012 From: peter at hk.ipsec.se (peter h) Date: Thu, 26 Jul 2012 16:26:07 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> References: <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> Message-ID: <201207261626.08400.peter@hk.ipsec.se> On Wednesday 25 July 2012 17.39, "Michele Neylon :: Blacknight" wrote: > Arnold > Do a Whois lookup on any IP in As39122 > You should see an abuse contact.... > > Yet we still get reports sent to accounts@ sales@ etc., Not that strange : > whois blacknight.tel Domain Name: BLACKNIGHT.TEL Domain ID: D591748-TEL Sponsoring Registrar: BLACKNIGHT INTERNET SOLUTIONS LTD Sponsoring Registrar IANA ID: 1448 Registrar URL (registration services): www.blacknight.com Domain Status: clientTransferProhibited Registrant ID: TUDHRH3SZ9DINEQF Registrant Name: Michele Neylon Registrant Organization: Blacknight Internet Solutions Ltd Registrant Address1: Barrowside Business Park Registrant Address2: Unit 12a Registrant Address3: Sleaty Road Registrant City: Carlow Registrant State/Province: Co Carlow Registrant Postal Code: 000000 Registrant Country: Ireland Registrant Country Code: IE Registrant Phone Number: +353.599183072 Registrant Email: management at blacknight.ie Administrative Contact ID: TURPH7M0XB4O2DZO Administrative Contact Name: Michele Neylon Administrative Contact Organization: Blacknight Internet Solutions Ltd Administrative Contact Address1: Barrowside Business Park Administrative Contact Address2: Unit 12a Administrative Contact Address3: Sleaty Road Administrative Contact City: Carlow Administrative Contact State/Province: Co Carlow Administrative Contact Postal Code: 000000 Administrative Contact Country: Ireland Administrative Contact Country Code: IE Administrative Contact Phone Number: +353.599183072 Administrative Contact Email: management at blacknight.ie Billing Contact ID: TURO0PYDHUERE11M Billing Contact Name: Michele Neylon Billing Contact Organization: Blacknight Internet Solutions Ltd Billing Contact Address1: Barrowside Business Park Billing Contact Address2: Unit 12a Billing Contact Address3: Sleaty Road Billing Contact City: Carlow Billing Contact State/Province: Co Carlow Billing Contact Postal Code: 000000 Billing Contact Country: Ireland Billing Contact Country Code: IE Billing Contact Phone Number: +353.599183072 Billing Contact Email: management at blacknight.ie Technical Contact ID: TUJJC18TGSETV3QQ Technical Contact Name: Michele Neylon Technical Contact Organization: Blacknight Internet Solutions Ltd Technical Contact Address1: Barrowside Business Park Technical Contact Address2: Unit 12a Technical Contact Address3: Sleaty Road Technical Contact City: Carlow Technical Contact State/Province: Co Carlow Technical Contact Postal Code: 000000 Technical Contact Country: Ireland Technical Contact Country Code: IE Technical Contact Phone Number: +353.599183072 Technical Contact Email: management at blacknight.ie Name Server: A0.CTH.DNS.NIC.TEL Name Server: D0.CTH.DNS.NIC.TEL Name Server: N0.CTH.DNS.NIC.TEL Name Server: S0.CTH.DNS.NIC.TEL Name Server: T0.CTH.DNS.NIC.TEL Created by Registrar: INJECTCSR Last Updated by Registrar: BLACKNIGHT INTERNET SOLUTIONS LTD Last Transferred Date: Wed Mar 02 23:46:19 GMT 2011 Domain Registration Date: Mon Mar 23 23:59:59 GMT 2009 Domain Expiration Date: Sat Mar 22 23:59:59 GMT 2014 Domain Last Updated Date: Wed Feb 15 15:43:42 GMT 2012 Registrar Fields ---------------- TrademarkRegistrationDate: 2006/10/26 >>>> Whois database was last updated on: Thu Jul 26 14:18:37 GMT 2012 <<<< There is no "abuse" address for someone searching for "blacknight.tel" > > Regards > > Michele > > Mr. Michele Neylon > Blacknight > http://Blacknight.tel > > Via iPhone so excuse typos and brevity > > On 25 Jul 2012, at 16:25, "Arnold" wrote: > > > On 25/07/2012 6:52 AM, Frank Gadegast wrote: > >> "Michele Neylon :: Blacknight" wrote: > >> > >> Hi all, > >> > >>> If they send reports to $random addresses they don't really deserve a response > >> > >> Thats a true word for prefessionals, but not for not-so-skilled > >> reporter, that are happy to find out, that there is something like RIPE > >> and a whois showing them who is responsible for a resource, if they > >> get abused. > > I have to agree with this. > > As a purely 'amateur' reporter, The WhoIs record is all I can rely on > > as an _officially_ published record to report my complaint. > > There are other ways, but none are as easy to use and as official. > > > > If the people responsible for reducing SPAM won't do anything to make > > it easier by at least enforcing a proper abuse address in the expected > > and designated place, then it makes the job of reporting and reducing > > SPAM that much harder. > > > > No matter what you will do, publishing any address opens the door to > > receiving SPAM, but ... why complain about it; use the information > > provided by this SPAM in the same way you expect any other user > > to use it - except you won't need me to report it to you :-) > > > > Arnold > > > > -- > > Fight Spam - report it with wxSR > > http://www.columbinehoney.net/wxSR.shtml > > > > > > > -- 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 michele at blacknight.ie Thu Jul 26 16:33:58 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Thu, 26 Jul 2012 14:33:58 +0000 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <201207261626.08400.peter@hk.ipsec.se> References: <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <201207261626.08400.peter@hk.ipsec.se> Message-ID: <434FD79C-2A86-499D-9E66-1605B6C10373@blacknight.com> This is the RIPE anti-abuse WG - I was referring to our _network_ NOT a domain, either ours or anyone else's Regards Michele Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 26 Jul 2012, at 15:27, "peter h" wrote: > On Wednesday 25 July 2012 17.39, "Michele Neylon :: Blacknight" wrote: >> Arnold >> Do a Whois lookup on any IP in As39122 >> You should see an abuse contact.... >> >> Yet we still get reports sent to accounts@ sales@ etc., > > Not that strange : >> whois blacknight.tel > Domain Name: BLACKNIGHT.TEL > Domain ID: D591748-TEL > Sponsoring Registrar: BLACKNIGHT INTERNET SOLUTIONS LTD > Sponsoring Registrar IANA ID: 1448 > Registrar URL (registration services): www.blacknight.com > Domain Status: clientTransferProhibited > Registrant ID: TUDHRH3SZ9DINEQF > Registrant Name: Michele Neylon > Registrant Organization: Blacknight Internet Solutions Ltd > Registrant Address1: Barrowside Business Park > Registrant Address2: Unit 12a > Registrant Address3: Sleaty Road > Registrant City: Carlow > Registrant State/Province: Co Carlow > Registrant Postal Code: 000000 > Registrant Country: Ireland > Registrant Country Code: IE > Registrant Phone Number: +353.599183072 > Registrant Email: management at blacknight.ie > Administrative Contact ID: TURPH7M0XB4O2DZO > Administrative Contact Name: Michele Neylon > Administrative Contact Organization: Blacknight Internet Solutions Ltd > Administrative Contact Address1: Barrowside Business Park > Administrative Contact Address2: Unit 12a > Administrative Contact Address3: Sleaty Road > Administrative Contact City: Carlow > Administrative Contact State/Province: Co Carlow > Administrative Contact Postal Code: 000000 > Administrative Contact Country: Ireland > Administrative Contact Country Code: IE > Administrative Contact Phone Number: +353.599183072 > Administrative Contact Email: management at blacknight.ie > Billing Contact ID: TURO0PYDHUERE11M > Billing Contact Name: Michele Neylon > Billing Contact Organization: Blacknight Internet Solutions Ltd > Billing Contact Address1: Barrowside Business Park > Billing Contact Address2: Unit 12a > Billing Contact Address3: Sleaty Road > Billing Contact City: Carlow > Billing Contact State/Province: Co Carlow > Billing Contact Postal Code: 000000 > Billing Contact Country: Ireland > Billing Contact Country Code: IE > Billing Contact Phone Number: +353.599183072 > Billing Contact Email: management at blacknight.ie > Technical Contact ID: TUJJC18TGSETV3QQ > Technical Contact Name: Michele Neylon > Technical Contact Organization: Blacknight Internet Solutions Ltd > Technical Contact Address1: Barrowside Business Park > Technical Contact Address2: Unit 12a > Technical Contact Address3: Sleaty Road > Technical Contact City: Carlow > Technical Contact State/Province: Co Carlow > Technical Contact Postal Code: 000000 > Technical Contact Country: Ireland > Technical Contact Country Code: IE > Technical Contact Phone Number: +353.599183072 > Technical Contact Email: management at blacknight.ie > Name Server: A0.CTH.DNS.NIC.TEL > Name Server: D0.CTH.DNS.NIC.TEL > Name Server: N0.CTH.DNS.NIC.TEL > Name Server: S0.CTH.DNS.NIC.TEL > Name Server: T0.CTH.DNS.NIC.TEL > Created by Registrar: INJECTCSR > Last Updated by Registrar: BLACKNIGHT INTERNET SOLUTIONS LTD > Last Transferred Date: Wed Mar 02 23:46:19 GMT 2011 > Domain Registration Date: Mon Mar 23 23:59:59 GMT 2009 > Domain Expiration Date: Sat Mar 22 23:59:59 GMT 2014 > Domain Last Updated Date: Wed Feb 15 15:43:42 GMT 2012 > Registrar Fields > ---------------- > TrademarkRegistrationDate: 2006/10/26 > >>>>> Whois database was last updated on: Thu Jul 26 14:18:37 GMT 2012 <<<< > > > > There is no "abuse" address for someone searching for "blacknight.tel" > > >> >> Regards >> >> Michele >> >> Mr. Michele Neylon >> Blacknight >> http://Blacknight.tel >> >> Via iPhone so excuse typos and brevity >> >> On 25 Jul 2012, at 16:25, "Arnold" wrote: >> >>> On 25/07/2012 6:52 AM, Frank Gadegast wrote: >>>> "Michele Neylon :: Blacknight" wrote: >>>> >>>> Hi all, >>>> >>>>> If they send reports to $random addresses they don't really deserve a response >>>> >>>> Thats a true word for prefessionals, but not for not-so-skilled >>>> reporter, that are happy to find out, that there is something like RIPE >>>> and a whois showing them who is responsible for a resource, if they >>>> get abused. >>> I have to agree with this. >>> As a purely 'amateur' reporter, The WhoIs record is all I can rely on >>> as an _officially_ published record to report my complaint. >>> There are other ways, but none are as easy to use and as official. >>> >>> If the people responsible for reducing SPAM won't do anything to make >>> it easier by at least enforcing a proper abuse address in the expected >>> and designated place, then it makes the job of reporting and reducing >>> SPAM that much harder. >>> >>> No matter what you will do, publishing any address opens the door to >>> receiving SPAM, but ... why complain about it; use the information >>> provided by this SPAM in the same way you expect any other user >>> to use it - except you won't need me to report it to you :-) >>> >>> Arnold >>> >>> -- >>> Fight Spam - report it with wxSR >>> http://www.columbinehoney.net/wxSR.shtml >>> >>> >> >> >> > > -- > 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 tk at abusix.com Thu Jul 26 16:57:59 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 26 Jul 2012 16:57:59 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50113FC8.1040508@ripe.net> References: <500EDD68.7070303@abusix.com><07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org><500FB3C7.6070407@tana.it><500FD694.6060005@tana.it> <500FE096.90303@abusix.com><500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net><2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com><50101FA1.7020403@telus.net><5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <50113FC8.1040508@ripe.net> Message-ID: <50115AF7.9080407@abusix.com> Hi everybody, > If the policy proposal 2011-06 is approved by the community we can work > towards storing abuse contact details in one location, referenced in one > way and easily readable by humans and scripts. Of course it won't solve > all problems, as some people were hoping for. But it is the first step > of what can be a journey towards a more complete solution. That is absolutely true, there are some other important things that'll need coverage step by step. Never the less this proposal is imho an important step into the right direction, so please let Brian and me know if you are on the same page or have any concerns. In both cases please let us know if you support the proposal or if you have concerns. Thanks, Tobias From rezaf at mindspring.com Thu Jul 26 17:16:14 2012 From: rezaf at mindspring.com (Reza Farzan) Date: Thu, 26 Jul 2012 11:16:14 -0400 (GMT-04:00) Subject: [anti-abuse-wg] Manual vs automated reports Message-ID: <11399715.1343315774722.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Hi Tobias, Thank you for you comments. Storing abuse contact details in one location makes perfect sense and satisfies many who are concerned about Abuse/Spam activities. Further simplifying this often confusing aspect of Abuse reporting channel in Whois directory should be one of the goals for RIPE's Anti-Abuse WG. Without any reservations, I support this practical proposal. Thank you, Reza Farzan +++++++++ -----Original Message----- >From: Tobias Knecht >Sent: Jul 26, 2012 10:57 AM >To: anti-abuse-wg at ripe.net >Cc: Denis Walker , rezaf at mindspring.com >Subject: Re: [anti-abuse-wg] Manual vs automated reports > >Hi everybody, > >> If the policy proposal 2011-06 is approved by the community we can work >> towards storing abuse contact details in one location, referenced in one >> way and easily readable by humans and scripts. Of course it won't solve >> all problems, as some people were hoping for. But it is the first step >> of what can be a journey towards a more complete solution. > >That is absolutely true, there are some other important things that'll >need coverage step by step. > >Never the less this proposal is imho an important step into the right >direction, so please let Brian and me know if you are on the same page >or have any concerns. In both cases please let us know if you support >the proposal or if you have concerns. > >Thanks, > >Tobias > From gnitzsche at netcologne.de Thu Jul 26 17:25:23 2012 From: gnitzsche at netcologne.de (Gunther Nitzsche) Date: Thu, 26 Jul 2012 17:25:23 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50113FC8.1040508@ripe.net> References: <500EDD68.7070303@abusix.com><07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org><500FB3C7.6070407@tana.it><500FD694.6060005@tana.it> <500FE096.90303@abusix.com><500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net><2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com><50101FA1.7020403@telus.net><5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <50113FC8.1040508@ripe.net> Message-ID: <321492721.20120726172523@netcologne.de> Hi, Thursday, July 26, 2012, 3:02:00 PM, Denis wrote: DW> If the policy proposal 2011-06 is approved by the community we can work DW> towards storing abuse contact details in one location, referenced in one DW> way and easily readable by humans and scripts. Of course it won't solve DW> all problems, as some people were hoping for. But it is the first step DW> of what can be a journey towards a more complete solution. I strongly support the proposal and the ideas behind. All other ways of searching RIPE databases (like the now gone (?) experimental search: http://lab.db.ripe.net/whois/use-cases/abuse-finder.xml?source=ripe&primary-key=%s ) led to too many false positives (wrongly assigned email-adresses) or ended up in empty queries. I am adding now the results of http://apps.db.ripe.net/whois/use-cases/abuse-finder.xml?primary-key=%s to my scripts but still use the results with care. Hopefully this url will stay longer :-) And just for the topic: we can be happy if there is at least *one* required anti-abuse email-address someone can find where he can send his complaints to. I do not see a need for splitting automatic and manual reports on the sender-side. The sender had trouble enough which was causing him/her to write a complaint at all; so let's make it as easy as possible for the victim. best greetings, Gunther NetCologne Systemadministration -- NetCologne Gesellschaft f?r Telekommunikation mbH Am Coloneum 9 ; 50829 K?ln Gesch?ftsf?hrer: Dr. Hans Konle (Sprecher), Karl- Heinz Zankel, Dipl. Ing. HRB 25580, AG K?ln From vesely at tana.it Thu Jul 26 17:47:51 2012 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 26 Jul 2012 17:47:51 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <5011213A.60002@ripe.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> Message-ID: <501166A7.8000600@tana.it> On Thu 26/Jul/2012 12:51:38 +0200 Denis Walker wrote: > On 26/07/2012 12:17, "Michele Neylon :: Blacknight" wrote: >> On 26 Jul 2012, at 10:01, Denis Walker wrote: >> >>> From the RIPE NCC website you can find an Abuse Finder tool >>> http://apps.db.ripe.net/search/abuse-finder.html >>> >>> This is a first iteration of a user tool to help with finding abuse >>> contact information in the RIPE Database. It tries to find the >>> abuse contact(s) for an Internet resource on a 'best effort' basis. >> >> I tried that now. It's very confusing. >> >> It's not at all clear if the search box will take an IP address or >> not .. > > That is a good point. People 'within the registration business' know > what an Internet resource is and know what we mean by primary key. To > more general users (including the public), these terms may not mean > anything. In fact 'key' may even be interpreted as 'password'. We will > make that more clear. While making things clear is always meritorious, end users should be encouraged to signal abuse to some reporting hub. They should prompt their mailbox providers to implement such service, rather than doing it themselves. In the words of RFC 6650: Rather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]). This allows centralized processing and tracking of reports, and provides training input to filtering systems. There is, however, no standard mechanism for this signaling between MUAs and Mailbox Providers to trigger abuse reports. http://tools.ietf.org/html/rfc6650#section-5.3 From tk at abusix.com Thu Jul 26 18:37:55 2012 From: tk at abusix.com (Tobias Knecht) Date: Thu, 26 Jul 2012 18:37:55 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <501166A7.8000600@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> Message-ID: <50117263.8030003@abusix.com> Hi, > While making things clear is always meritorious, end users should be > encouraged to signal abuse to some reporting hub. They should prompt > their mailbox providers to implement such service, rather than doing > it themselves. In the words of RFC 6650: Don't get me wrong, this rfc is a good one an clarifies some things, but it is written by Americans under their understanding of US law. Some things that are mentioned are not possible under European Jurisdiction. For example providing Feedbackloops is especially in Germany a very critical task. So rfc 6650 is good but unfortunately does not fit all use and legal cases. In addition to that, I do not have any problem in single persons reporting abuse incidents as long as they are useful. And even people in the registration business sometimes do not know how to report correctly, which is not bad it's just that they haven never done it before and need somebody/something that guides them through, which should be one of the next tasks for this community to define. Thanks, Tobias From wiegert at telus.net Thu Jul 26 19:00:29 2012 From: wiegert at telus.net (Arnold) Date: Thu, 26 Jul 2012 10:00:29 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <50110755.6000204@ripe.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> Message-ID: <501177AD.9010106@telus.net> On 26/07/2012 2:01 AM, Denis Walker wrote: > Dear Arnold > > From the RIPE NCC website you can find an Abuse Finder tool > http://apps.db.ripe.net/search/abuse-finder.html Thank you, Denis I believe someone had pointed me to this URL before, but because I never used it, I had forgotten about it. As you have had other comments in the mean time regarding this URL, I won't belabor the point too much, When I, or anyone else, gets SPAM, all we have to go on is the IP address and the lookup URL does not even accept IP addresses, so it is not very useful for this purpose. It may be useful for whatever the facility was built for, but it is not for my purposes :-( I have used the RIPE DB look-up URL with some success, but it is tedious and requires a lot of manual intervention and searching and following trails. From my perspective, the simplest way would be to simply put the abuse address in the place the Whois record provides, or possibly (and preferably for me) in the IANA database or else provide a service similar to Whois, for abuse only, with registration if absolutely necessary. > This is a first iteration of a user tool to help with > finding abuse contact information in the RIPE Database. It > tries to find the abuse contact(s) for an Internet > resource on a 'best effort' basis. If it is a tool under development, I would not mind giving some feedback to the developers. From waht I see and what others have also commented on, it does not look like it was developed with this purpose in mind. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From vesely at tana.it Thu Jul 26 19:35:13 2012 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 26 Jul 2012 19:35:13 +0200 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50117263.8030003@abusix.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> Message-ID: <50117FD1.5090005@tana.it> On Thu 26/Jul/2012 18:37:55 +0200 Tobias Knecht wrote: >> In the words of RFC 6650: > > Don't get me wrong, this rfc is a good one an clarifies some things, > but it is written by Americans under their understanding of US law. IMHO, it is not so much being Americans or whatever, as being versed on legal points of view. > Some things that are mentioned are not possible under European > Jurisdiction. For example providing Feedbackloops is especially in > Germany a very critical task. Is it? I guess in Italy we have more or less the same European directives. So long as the user is clearly informed about what data is being sent to who, and grants her/his consent to that, it should be legal to do FBLs. Yet, IANAL. The best thing, IMHO, would be do gather users' consent on the first time they hit a "This is Spam" button. At the same time, give them the option to redact their email address in the header. (See http://tools.ietf.org/html/rfc6590 ). > So rfc 6650 is good but unfortunately does not fit all use and legal > cases. We need to clear up this issue. Googling for that I find that ETIS, which is based in Europe, has an "Anti SPAM Co-operation Group" that "is also working on an anti-spam feedback loop project." (Quotes from http://etis.org/groups/anti-spam-task-force ). I'd guess you know them; they have a meeting on next Oktoberfest... Would they cover those legal concerns? A recurring objection in the acm-tf was that RIPE handles just a region, and therefore we'd need anti-abuse practices to be specified by some global body such as the IETF. Now we have it. We should use it as we use SMTP. And the fact that our law is better than theirs should be an aid, not a hindrance! > In addition to that, I do not have any problem in single persons > reporting abuse incidents as long as they are useful. And even people > in the registration business sometimes do not know how to report > correctly, which is not bad it's just that they haven never done it > before and need somebody/something that guides them through, which > should be one of the next tasks for this community to define. Very much agreed. We need to exchange scripts and ideas. From ops.lists at gmail.com Fri Jul 27 03:58:10 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 27 Jul 2012 07:28:10 +0530 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50117FD1.5090005@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> <500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> Message-ID: Feedback loops sent to third parties tend to have PII stripped. Based on a definition of PII that does not regard IP addresses as personal data. On Jul 26, 2012 11:05 PM, "Alessandro Vesely" wrote: > On Thu 26/Jul/2012 18:37:55 +0200 Tobias Knecht wrote: > >> In the words of RFC 6650: > > > > Don't get me wrong, this rfc is a good one an clarifies some things, > > but it is written by Americans under their understanding of US law. > > IMHO, it is not so much being Americans or whatever, as being versed > on legal points of view. > > > Some things that are mentioned are not possible under European > > Jurisdiction. For example providing Feedbackloops is especially in > > Germany a very critical task. > > Is it? I guess in Italy we have more or less the same European > directives. So long as the user is clearly informed about what data > is being sent to who, and grants her/his consent to that, it should be > legal to do FBLs. Yet, IANAL. > > The best thing, IMHO, would be do gather users' consent on the first > time they hit a "This is Spam" button. At the same time, give them > the option to redact their email address in the header. (See > http://tools.ietf.org/html/rfc6590 ). > > > So rfc 6650 is good but unfortunately does not fit all use and legal > > cases. > > We need to clear up this issue. Googling for that I find that ETIS, > which is based in Europe, has an "Anti SPAM Co-operation Group" that > "is also working on an anti-spam feedback loop project." (Quotes from > http://etis.org/groups/anti-spam-task-force ). I'd guess you know > them; they have a meeting on next Oktoberfest... Would they cover > those legal concerns? > > A recurring objection in the acm-tf was that RIPE handles just a > region, and therefore we'd need anti-abuse practices to be specified > by some global body such as the IETF. Now we have it. We should use > it as we use SMTP. And the fact that our law is better than theirs > should be an aid, not a hindrance! > > > In addition to that, I do not have any problem in single persons > > reporting abuse incidents as long as they are useful. And even people > > in the registration business sometimes do not know how to report > > correctly, which is not bad it's just that they haven never done it > > before and need somebody/something that guides them through, which > > should be one of the next tasks for this community to define. > > Very much agreed. We need to exchange scripts and ideas. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at help.org Fri Jul 27 06:45:39 2012 From: lists at help.org (lists at help.org) Date: Fri, 27 Jul 2012 00:45:39 -0400 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50117FD1.5090005@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> Message-ID: <50121CF3.9050002@help.org> >Is it? I guess in Italy we have more or less the same European directives. >So long as the user is clearly informed about what data is being sent to who, >and grants her/his consent to that, it should be legal to do FBLs. Yet, IANAL. >The best thing, IMHO, would be do gather users' consent on the first time they >hit a "This is Spam" button. At the same time, give them the option to redact their >email address in the header. (See http://tools.ietf.org/html/rfc6590 ). The real story is that RIPE staff and several people involved with this have been putting out false information and lying to people about the applicability of the EU privacy laws. They are doing this so they have an excuse to restrict access to the whois database. Now that they made up this false story they have backed themselves into a corner and they don't want to admit they lied to everybody so they keep making the same false claims over and over to save face. These are the people that treat abuse like a religion and they no longer use common sense or logic. You don't need to be a lawyer to understand that once someone gives permission to publish data related to them then the privacy laws no longer apply to that situation. From lists at help.org Fri Jul 27 06:54:36 2012 From: lists at help.org (lists at help.org) Date: Fri, 27 Jul 2012 00:54:36 -0400 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com> <500FFA13.2030307@powerweb.de> <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com> <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> Message-ID: <50121F0C.1040908@help.org> >Based on a definition of PII that does not regard IP addresses as personal data. A definition that, of course, does not make sense and is not true. You worked on an abuse desk and you traced IP addresses all the time so obvious you know better. Some people really live in some sort of fantasy land where common sense does not exist and even well-known facts are dismissed out-of-hand if it somehow affects your "religious beliefs." People are traced all the time by IP addresses. Whether a specifc IP address is PII depends upon the facts of the specific situation and you obviously don't have time to evaluate each specific situation if you are getting large number of abuse complaints. Under these circumstances you should probably treat all IP's as PII. From denis at ripe.net Fri Jul 27 11:53:51 2012 From: denis at ripe.net (Denis Walker) Date: Fri, 27 Jul 2012 11:53:51 +0200 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <501177AD.9010106@telus.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <501177AD.9010106@telus.net> Message-ID: <5012652F.1040706@ripe.net> Dear Arnold It seems there is some confusion over the wording used on the Abuse Finder web page. The input box is labelled "Resource key:". This is because, from a registration point of view, we see IP addresses and AS Numbers as "Internet resources". In the RIPE Database the primary "key" of an INET(6)NUM or AUT-NUM object is the IP address and the AS Number. So the "Resource key:" box is where you enter the IP address that is originating the spam you receive. This tool will then return the abuse contacts for this IP address based on the 'best effort' heuristics currently available in the RIPE Database. We will modify the text on the Abuse Finder page and change the help text for the '?' next to the input box to try to make this much clearer to users. Thank you for the feedback and I hope this tool will be useful to you. With a clearer definition of how to store abuse contact details in the RIPE Database, as suggested by policy proposal 2011-06 for example, we would be able to make the heuristics behind the Abuse Finder tool much more accurate. Regards, Denis Walker Business Analyst RIPE NCC Database Group On 26/07/2012 19:00, Arnold wrote: > On 26/07/2012 2:01 AM, Denis Walker wrote: >> Dear Arnold >> >> From the RIPE NCC website you can find an Abuse Finder tool >> http://apps.db.ripe.net/search/abuse-finder.html > Thank you, Denis > > I believe someone had pointed me to this URL before, but > because I never used it, I had forgotten about it. > > As you have had other comments in the mean time regarding this > URL, I won't belabor the point too much, > > When I, or anyone else, gets SPAM, all we have to go on is the IP > address and the lookup URL does not even accept IP addresses, > so it is not very useful for this purpose. > > It may be useful for whatever the facility was built for, but it is not > for my purposes :-( > > I have used the RIPE DB look-up URL with some success, but it is > tedious and requires a lot of manual intervention and searching > and following trails. > > From my perspective, the simplest way would be to simply put the > abuse address in the place the Whois record provides, or possibly > (and preferably for me) in the IANA database or else provide a > service similar to Whois, for abuse only, with registration if > absolutely necessary. > >> This is a first iteration of a user tool to help with finding abuse >> contact information in the RIPE Database. It tries to find the abuse >> contact(s) for an Internet resource on a 'best effort' basis. > If it is a tool under development, I would not mind giving some feedback > to the developers. > From waht I see and what others have also commented on, it does not > look like > it was developed with this purpose in mind. > > Arnold > From Jamie.Stallwood at imerja.com Fri Jul 27 13:01:10 2012 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Fri, 27 Jul 2012 12:01:10 +0100 Subject: [anti-abuse-wg] [policy-announce] 2011-06 Review Period extended until 13 August2013 (Abuse Contact Management in the RIPE NCC Database) References: <201207171328.q6HDSGNL013892@imx-sl2.imerjamail.com> Message-ID: <7B640CC73C18D94F83479A1D0B9A14040615822A@bhw-srv-dc1.imerja.com> Seems reasonable to me, I have no objections. Kind regards Jamie Stallwood Jamie Stallwood Security Specialist Imerja Limited Tel: 0844 225 2888 Mob: 07795 840385 Jamie.Stallwood at imerja.com NIC Handle: uk.imerja.JS7259-RIPE -----Original Message----- From: policy-announce-bounces at ripe.net [mailto:policy-announce-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 17 July 2012 14:26 To: policy-announce at ripe.net Cc: aa-wg-chairs at ripe.net; tk at abusix.com; anti-abuse-wg at ripe.net Subject: [policy-announce] 2011-06 Review Period extended until 13 August2013 (Abuse Contact Management in the RIPE NCC Database) Dear Colleagues, The Review Period for the proposal 2011-06 has been extended until 13 August 2012. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-06 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt on behalf of Policy Development Officer RIPE NCC -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. From wiegert at telus.net Fri Jul 27 17:24:10 2012 From: wiegert at telus.net (Arnold) Date: Fri, 27 Jul 2012 08:24:10 -0700 Subject: [anti-abuse-wg] Manual vs automated reports In-Reply-To: <5012652F.1040706@ripe.net> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <501177AD.9010106@telus.net> <5012652F.1040706@ripe.net> Message-ID: <5012B29A.5030001@telus.net> On 27/07/2012 2:53 AM, Denis Walker wrote: > Dear Arnold > > It seems there is some confusion over the wording used on > the Abuse Finder web page. The input box is labelled > "Resource key:". This is because, from a registration > point of view, we see IP addresses and AS Numbers as > "Internet resources". In the RIPE Database the primary > "key" of an INET(6)NUM or AUT-NUM object is the IP address > and the AS Number. Thank you, Denis for clearing up this 'mystery', but .... :-) I had assumed as much and did try to look up IP addresses, just this morning again, after receiving this message. The SPAM e-mail's IP I tried was in the RIPE DB. This much I knew both according to the Whois record and because I was able to locate the appropriate abuse address from the RIPE DB Query URL. Using the Abuse look up URL got me no results at all, aside from a small notice identifying the service as the "RIPE Database abuse finder service ...." In total I must have tried that URL about 6 - 10 times, without ever getting any data, let alone useful abuse data. I don't know what is behind this front end, but since I can find what I need using the DB Query directly, there must be something wrong with the logic or implementation, since the data evidently exists in the DB. The only problem with my current method using the direct DB query, is that it is a lot more labor intensive, involving a fair bit of copying and pasting, as well as visually searching the search results for suitable data. Arnold PS: if you need some of the 'failing' IP addresses, I can send them to you off-list. -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From pk at DENIC.DE Sat Jul 28 19:39:55 2012 From: pk at DENIC.DE (Peter Koch) Date: Sat, 28 Jul 2012 19:39:55 +0200 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5003D8A5.9050505@heanet.ie> References: <5003D8A5.9050505@heanet.ie> Message-ID: <20120728173955.GS24669@x28.adm.denic.de> On Mon, Jul 16, 2012 at 10:02:29AM +0100, Brian Nisbet wrote: > would ask if members could raise any points that they are still > uncertain about and state as clearly as possible, their current opinion > on the proposal. I have read version 3.0 of 2011-06 and the NCC's impact analysis. While I agree with some of the goals of 2011-06, I object to the proposal in its current form. In fact, I think it is not even ready for the Review Phase, even though I understand that was the way to invoke the NCC impact analysis. Here's already one reason to object: the proposal itself is hardly comprehensible without said impact analysis but since the latter is not part of the proposal it can only be considered transient. Without even remotely suggesting the NCC was driving policy here, I must say with both hesitance and regret that I am not comfortable with the role the NCC has been dragged into w.r.t 2011-06. o The proposal and impact analysis are unclear about the aspects of data protection issues for the "abuse-mailbox:" attribute. It appears it is intended to "by definition" avoid PII here. How would that work for address space allocated (or, more importantly, assigned) to a natural person? That said, the proposal is also unclear whether the abuse-c: would apply to PI space, as well. o The proposal uses unclear language w.r.t. the mandatory nature of the "abuse-c:" attribute: ``This policy introduces a new contact attribute named "abuse-c:", that can be included in inetnum, inet6num and aut-num objects. '' vs. ``The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders' networks.'' o The second paragraph quoted above expresses an expectation regarding the handling of submitted email reports (what else would it mean to be prepared for "receiving automatic and manual reports"?) o The purpose of the "e-mail:" attribute is given with "other". I do not understand that. I would suggest to separate the targets for 'manual' and 'machine readable' reports. It is natural for any object in the RIPE DB to use the 'email:' attribute for email communication. {this is listed for completeness; i have read the longthread on the topic and don't suggest to rehash. The proposal, in summary, has bigger problems.} o The proposal is unclear at least about the future of irt: objects. o Finally, and most importantly, I object to the mandatory nature of the attribute. Neither the impact analysis nor the counter arguments section assess the impact of presence of an abuse (role) object and the resulting actions on maintainers/... LIRs/NCC members. -Peter From lists at help.org Sat Jul 28 19:55:41 2012 From: lists at help.org (lists at help.org) Date: Sat, 28 Jul 2012 13:55:41 -0400 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <20120728173955.GS24669@x28.adm.denic.de> References: <5003D8A5.9050505@heanet.ie> <20120728173955.GS24669@x28.adm.denic.de> Message-ID: <5014279D.8050600@help.org> Yes. When people post these types of objections they generally get ridiculed and the issues never get put into any minutes or reports because the people involved are practicing a religion and not doing a technical/legal analysis. On 7/28/2012 1:39 PM, Peter Koch wrote: > On Mon, Jul 16, 2012 at 10:02:29AM +0100, Brian Nisbet wrote: > >> would ask if members could raise any points that they are still >> uncertain about and state as clearly as possible, their current opinion >> on the proposal. > I have read version 3.0 of 2011-06 and the NCC's impact analysis. > > While I agree with some of the goals of 2011-06, I object to the > proposal in its current form. In fact, I think it is not even ready > for the Review Phase, even though I understand that was the way to > invoke the NCC impact analysis. Here's already one reason to object: the > proposal itself is hardly comprehensible without said impact analysis > but since the latter is not part of the proposal it can only be > considered transient. Without even remotely suggesting the NCC was driving > policy here, I must say with both hesitance and regret that I am not > comfortable with the role the NCC has been dragged into w.r.t 2011-06. > > o The proposal and impact analysis are unclear about the aspects of > data protection issues for the "abuse-mailbox:" attribute. It appears > it is intended to "by definition" avoid PII here. How would that work > for address space allocated (or, more importantly, assigned) to a natural > person? That said, the proposal is also unclear whether the abuse-c: would > apply to PI space, as well. > > o The proposal uses unclear language w.r.t. the mandatory nature of the > "abuse-c:" attribute: > > ``This policy introduces a new contact attribute named "abuse-c:", that can > be included in inetnum, inet6num and aut-num objects. '' > > vs. > > ``The role objects used for abuse contact information > will be required to contain a single "abuse-mailbox:" attribute which is > intended for receiving automatic and manual reports about abusive behavior > originating in the resource holders' networks.'' > > o The second paragraph quoted above expresses an expectation regarding the > handling of submitted email reports (what else would it mean to be prepared for > "receiving automatic and manual reports"?) > > o The purpose of the "e-mail:" attribute is given with "other". I do not > understand that. I would suggest to separate the targets for 'manual' and > 'machine readable' reports. It is natural for any object in the RIPE DB to > use the 'email:' attribute for email communication. {this is listed for > completeness; i have read the longthread on the topic and don't suggest > to rehash. The proposal, in summary, has bigger problems.} > > o The proposal is unclear at least about the future of irt: objects. > > o Finally, and most importantly, I object to the mandatory nature of the attribute. > Neither the impact analysis nor the counter arguments section assess the impact > of presence of an abuse (role) object and the resulting actions on maintainers/... > LIRs/NCC members. > > -Peter > > > From ripe-anti-spam-wg at powerweb.de Sat Jul 28 21:19:38 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sat, 28 Jul 2012 21:19:38 +0200 Subject: [anti-abuse-wg] the mandatory abuse field Message-ID: <50143B4A.6020006@powerweb.de> Hi all, I really have the feeling, that some in the community fear a mandatory abuse field, and try find any strange argument against it, but I really cannot see why. If somebody does not want to receive abuse reports or does not want to do something against abuse originating from his own resources or likes to receive them not via email or has whatever else reason, well, name it this-email-address-is-not-being-read at yourdomain.com or no-reply at example.com or send it to devnull ... Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore. On the other end, a mandatory abuse field will clean up everything in RIPEs database, remove the unparseble remarks, will help the abuse teams to receive reports only to ONE address, because sender can be educated, abuse tools can be simplified and integrated in webpages easily aso ... A mandatory abuse field has that much advantages for everybody who likes to work against abuse, that I cannot understand, why people, that do not want the same for there own reasons are against it. Let us optimize our procedures and if you do not want to participate, well set the email address to whatever or ignore every incoming mail ... Well, there is one reasons I can think of: Those people are not concerned, that they have to do something against abuse coming from there OWN resources, it must be the people that are causing the abuse problem in the first place, its there business, and so they are worried, that others find easier and better methods in preventing abuse. So, my personal summary is: --- Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion. But thats only my impression ... --- 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 ripe-anti-spam-wg at powerweb.de Sat Jul 28 22:06:21 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sat, 28 Jul 2012 22:06:21 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <8B5DF7B6-9751-4214-AE60-1E38DE6C4F0D@anytimechinese.com> References: <50143B4A.6020006@powerweb.de> <8B5DF7B6-9751-4214-AE60-1E38DE6C4F0D@anytimechinese.com> Message-ID: <5014463D.3090608@powerweb.de> H.Lu wrote: > Hi > Hi, >> So, my personal summary is: >> --- >> Anybody, who is against a mandatory abuse field, >> is a professional spammer, abuser, maintains >> a bot net or sells open proxies or other services >> used for abusing others. >> They are criminals to my opinion. >> > > I think this is a bit too absolute... Not at all. There is only four types: 1 people that do like to do something against abuse originating from there resources 2 people that do like to do something against abuse reaching there networks 3 people that do not like to do anything against abuse originating from there networks Some of those interest could be combinated. (and all those will have no problem with the mandatory abuse field, they will either love it or they can ignore it) and: 4 people that dont want that others have it easier to work against spam THEY cause > > But even they are, identify them as criminal might not be true as in some country spam might not even consider as offense. Well, its illegal in my country, so I can call them criminals. (please do me a favor and name one country in the RIPE region, where its legal to abuse computers and services) The big question is: - should we stop any progress in spam reporting and the cleanup of the database because of people, that are criminals in most member countries ? - and that are not even located in the RIPE region ? - and that are no members ? The following always puzzled me anyway: how can people influence the regulations without being members or without bing located in the RIPE region ? The members pay the service and to my opinion, paying members should be the only ones, we should listen too. Its a weird situation, that anybody from whatever country with whatever background or regulations can influence everything. Lets take ICANN as an example: do you really think that I will have the chance to influence a vote at the ICANN members board without being a member ? Well, they might listen, what others have to say, but finally it will be a vote. Lets have a vote asking all RIPE members abuse this proposal instead of listening to every criminal from the world ... Kind regards, Frank >> But thats only my impression ... >> --- >> >> >> 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 lists at help.org Sun Jul 29 01:03:05 2012 From: lists at help.org (lists at help.org) Date: Sat, 28 Jul 2012 19:03:05 -0400 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50143B4A.6020006@powerweb.de> References: <50143B4A.6020006@powerweb.de> Message-ID: <50146FA9.4040503@help.org> They wild opinions are why this list is not a "consensus" of any sort. If someone has a certain opinion they are labeled as criminals, spammers, etc. without any legitimate reason. This type of stuff comes from a religious belief and not anything that can be explained by logic. I don't see why there is all this discussion of mandatory abuse fields when the RIR whois databases are filled with inaccuracies and false whois data. When I point these out to ARIN I never hear back and it never gets fixed and I assume RIPE is the same way. Until you take care of that problem it is useless to require mandatory fields of any sort. > > So, my personal summary is: > --- > Anybody, who is against a mandatory abuse field, > is a professional spammer, abuser, maintains > a bot net or sells open proxies or other services > used for abusing others. > They are criminals to my opinion. > > But thats only my impression ... > --- From lists at help.org Sun Jul 29 01:13:25 2012 From: lists at help.org (lists at help.org) Date: Sat, 28 Jul 2012 19:13:25 -0400 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50146FA9.4040503@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> Message-ID: <50147215.10303@help.org> >Its a weird situation, that anybody from whatever country with whatever background or regulations can influence everything. Lets take ICANN as an example: do you really think that I will have >the chance to influence a vote at the ICANN >members board without being a member ? Well, they might listen, what others have to say, but finally it will be a vote. Lets have a vote asking all >RIPE members abuse this proposal instead of listening to every criminal from the world The WHOIS service is a universal service used by people around the world and the RIR's have agreements in place to provide these services. People in other regions receive spam, abuse attempts, etc from the RIPE region and they need to use the whois just like the RIPE region needs to use other RIR whois. WHOIS policy should be set by a region, it should be universal across all RIR's. The underlysing system is paid for by the US taxpayers via the IANA contract. If your ideas were to be used RIPE members should have no say, only the US taxpayer should dictate how it is run. As for ICANN, they are paid for by a domain tax. You are correct that the people that pay the tax generally have no say whatsoever which is why ICANN is not actually an Internet "governance." From ripe-anti-spam-wg at powerweb.de Sun Jul 29 09:18:53 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sun, 29 Jul 2012 09:18:53 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50146FA9.4040503@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> Message-ID: <5014E3DD.7020300@powerweb.de> lists at help.org wrote: > > They wild opinions are why this list is not a "consensus" of any sort. > If someone has a certain opinion they are labeled as criminals, Sure, they are in my country. > spammers, etc. without any legitimate reason. This type of stuff comes > from a religious belief and not anything that can be explained by logic. Its not religion, its law in a lot of countries. > I don't see why there is all this discussion of mandatory abuse fields > when the RIR whois databases are filled with inaccuracies and false How can you believe, that you can cleanup the database WITHOUT a mandatory field ? The mandory field means MORE accuracy, not less. > whois data. When I point these out to ARIN I never hear back and it > never gets fixed and I assume RIPE is the same way. Until you take care > of that problem it is useless to require mandatory fields of any sort. Where is your logic here ? How can you have better data, without forcing the resource owner to enter his information just in one field instead of spreading it everywhere and have even no email address at all ? Please tell us, how you think, how the database can be cleaned up inf whatever way. Please supply a method instead of critizising the mandatory field ... Kind regards, Frank > > > > >> >> So, my personal summary is: >> --- >> Anybody, who is against a mandatory abuse field, >> is a professional spammer, abuser, maintains >> a bot net or sells open proxies or other services >> used for abusing others. >> They are criminals to my opinion. >> >> But thats only my impression ... >> --- > > > > -- 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 ripe-anti-spam-wg at powerweb.de Sun Jul 29 09:41:53 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sun, 29 Jul 2012 09:41:53 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50147215.10303@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> <50147215.10303@help.org> Message-ID: <5014E941.5010708@powerweb.de> lists at help.org wrote: > The WHOIS service is a universal service used by people around the world First, the whois service is a service from the RIPE NCC, stored in a database maintained by the RIPE NCC, programmed from people paid by the members of the RIPE NCC. Second, it looks like to me, that the format in wich the data is stored in that database, is finalized by people that do not have to be from the RIPE region and do not have to be a member of the RIPE NCC, the so-called community. And thats weird ... > and the RIR's have agreements in place to provide these services. Based on RFCs that are finalized by people not being part of that RIR. Strange ... :People > in other regions receive spam, abuse attempts, etc from the RIPE region > and they need to use the whois just like the RIPE region needs to use > other RIR whois. WHOIS policy should be set by a region, it should be > universal across all RIR's. Sure, one standarized whois would be wonderfull. But, and thats my point, the format of the stored data, should be decided by the members of those RIRs. > The underlysing system is paid for by the US > taxpayers via the IANA contract. Really ? Were do you have that from ? IANA is getting its money from ICANN. And IANA is not doing any service nor maintaining the database. > If your ideas were to be used RIPE > members should have no say, only the US taxpayer should dictate how it > is run. > > As for ICANN, they are paid for by a domain tax. You are correct that > the people that pay the tax generally have no say whatsoever which is > why ICANN is not actually an Internet "governance." Ok, so: IANA is getting paid by all people all over the world, wich are buying domain names. There is no money from US taxpayers being involved. Where do you have that from ? One goal of IANA is to coordinate RFCs, so a whois standarization should be their thing, good, continue to complain to them. Until then, I like the RIPE NCC to simply ask there members, because neither the "comunity" nor non-members should have anything to say about the service the NCC offers. 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 lists at help.org Sun Jul 29 09:44:21 2012 From: lists at help.org (lists at help.org) Date: Sun, 29 Jul 2012 03:44:21 -0400 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5014E3DD.7020300@powerweb.de> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> <5014E3DD.7020300@powerweb.de> Message-ID: <5014E9D5.5030102@help.org> >Please supply a method instead of critizising the mandatory field ... Nothing wrong with a mandatory field but you need to clean up the entire database first. Once you do the major cleanup then you can focus on individual fields and it all should be coordinated with all the RIR's. For instance I recently saw a record in ARIN that says: Address: Private City: Private StateProv: NJ PostalCode: 99999 The response from ARIN was: "If you believe the information below is false, can you provide more detail regarding the information you believe is inaccurate and ARIN will research and take the appropriate action." I pointed out the whole record was false and I never heard back and it was never fixed. I don't see the point of making anything mandatory if this is how things are done. Once these things get fixed I would agree with the mandatory field. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-anti-spam-wg at powerweb.de Sun Jul 29 09:58:51 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sun, 29 Jul 2012 09:58:51 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <8B5DF7B6-9751-4214-AE60-1E38DE6C4F0D@anytimechinese.com> <5014463D.3090608@powerweb.de> Message-ID: <5014ED3B.2050707@powerweb.de> Lu Heng wrote: >> region, where its legal to abuse computers and services) >> > > Every country has different legal definition about spam, or "abuse", Again, "every country" does not count. Its illegal in my country, and they are harming me personal as well as my business, so I can call them criminals. > spam and abuse are very broad term, without court judgement of the Thats right, but as for the RIPE region, it will only count, whats law in the RIPE region and most countries have very similar laws here, specially those in the EU. > activity, I will be very careful calling anybody criminal--as I don't > have the rights to identify them(I am not sure which country you came > from, ( that why I usally do not hide and add a sig) > at least the countries I ever heard of in my life, the rights of > identify someone as criminal are only hold by judges. not even police > has rights to call someone criminal--they can call "suspect"). So I can call those criminals, that are already in jail ? Well, happening every day in Germany. > Ripe region cross wide range of culture and countries, I don't believe > anybody in any specific region has rights to define what is "abuse" > for another very different country. and especially regarding the legal > terms like "criminal" is very serious term that I don't believe > anybody has rights to identify the entire ripe region's population, > not even EU, as Ripe covers wider area than EU does. Sad enough, what a stupid idea to set up an organization without common law ... > But again, Ripe is only a registration service, No RIPE is a community. RIPE NCC is offering the services. > Ripe NCC has no rights > either the entire community has no rights to identify any body in a > legal term, if a spammer need an IP range for a technical term, Ripe > NCC has to give to them--It is not Ripe NCC's position to judge Never said and sure not. The NCC can give the resources to any MEMBER ! They are not giving them to the community ! Only to members. So: why should the community decide about the format of the database ? > anybody's action if legal, seems to me so many times people forget > that Ripe NCC is only a registration service, they are not government > of the internet, either they need a police force to regulate the > internet. Well, the police IS regulating the internet, according to the laws of several countries and every day criminals are being send to jail for some computer crime. Worldwide. And if they are allowed to use an internet terminal in their cell, they could even post here, that a mandatory field is stupid, without any good reson against it. And the so-called "community" then does not have any consensus ... Oh, Im fantazising know ... 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 ripe-anti-spam-wg at powerweb.de Sun Jul 29 10:10:24 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Sun, 29 Jul 2012 10:10:24 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5014E9D5.5030102@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> <5014E3DD.7020300@powerweb.de> <5014E9D5.5030102@help.org> Message-ID: <5014EFF0.6010702@powerweb.de> lists at help.org wrote: > >Please supply a method instead of critizising the mandatory field ... > > Nothing wrong with a mandatory Ah, there we are, more substance. > field but you need to clean up the entire > database first. Why ? The abuse-c will automatically lead to a cleanup. The members will have to alter their objects, when the abuse-c is mandatory, and surely a lot of them will clean them up. The members could receive some guidelines from the NCC, when its there, like: "remove abuse information from the remarks, remove iRT objects only used for an abuse address aso ... And how: how will you clean up the database ? btw: this is a job for the db-wg ... > individual fields and it all should be coordinated with all the RIR's. Its a good idea and it should be IANAs work, but until then ? > For instance I recently saw a record in ARIN that says: > > Address: Private > City: Private > StateProv: NJ > PostalCode: 99999 > > The response from ARIN was: "If you believe the information below is false, can you provide more detail regarding the information you believe is inaccurate and > ARIN will research and take the appropriate action." I pointed out the whole record was false and I never heard back and it was never fixed. I don't see the point > of making anything mandatory if this is how things are done. Once these things get fixed I would agree with the mandatory field. Why in that order ? Please make this more clear. 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 tk at abusix.com Sun Jul 29 18:47:52 2012 From: tk at abusix.com (Tobias Knecht) Date: Sun, 29 Jul 2012 18:47:52 +0200 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50117FD1.5090005@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> Message-ID: <50156938.9070204@abusix.com> Hi, > IMHO, it is not so much being Americans or whatever, as being versed > on legal points of view. It's the US legal system vs. the European legal system. Since Europe has an opt-in system and the US have an opt-out system in the US the FBL generation is a necessary way to support US laws. >> Some things that are mentioned are not possible under European >> Jurisdiction. For example providing Feedbackloops is especially in >> Germany a very critical task. > > Is it? I guess in Italy we have more or less the same European > directives. So long as the user is clearly informed about what data > is being sent to who, and grants her/his consent to that, it should be > legal to do FBLs. Yet, IANAL. Exactly. Is there an FBL in Italy so far? I don't think so. The hoops ISPs have to jump through and the burden they have to put on end-users are way to high. That is the problem. It's not so much about the possibility and more about usability. > The best thing, IMHO, would be do gather users' consent on the first > time they hit a "This is Spam" button. At the same time, give them > the option to redact their email address in the header. (See > http://tools.ietf.org/html/rfc6590 ). That is not the problem at all. The problem is, that a user clicking on the spam button has every time he clicks on the spam button acknowledge that his mail is being sent to a third party. And in addition to that he has explicitly acknowledge the receiver. Think about 50 spam messages per day. That would mean that the a user has to click 50 times the spam button, than 50 times "Yes I want to report this message!" and than 50 times "I'm okay that this message will be sent to X!" From a usability point this is ridiculous and exactly that is one of the main problems. And in addition to that ISPs would like to provide FBLs, but they do not want to annoy customers with this harassment, because users would not do it and as soon as there will be a way around it they will not do it because they are afraid it's getting complicated again. We first need to find a simple for end users secure way to report that does not destroy the usability and the trust and than come up with solutions. >> So rfc 6650 is good but unfortunately does not fit all use and legal >> cases. > > We need to clear up this issue. Googling for that I find that ETIS, > which is based in Europe, has an "Anti SPAM Co-operation Group" that > "is also working on an anti-spam feedback loop project." (Quotes from > http://etis.org/groups/anti-spam-task-force ). I'd guess you know > them; they have a meeting on next Oktoberfest... Would they cover > those legal concerns? Yes ETIS is exactly working on these legal issues, but imho have not found a way around it. The project that is ongoing there has nothing to do with user feedback. It's about spamtrap data provided by the ETIS members. I'll be probably at the next ETIS meeting in Munich and hopefully can help to take some next steps. > A recurring objection in the acm-tf was that RIPE handles just a > region, and therefore we'd need anti-abuse practices to be specified > by some global body such as the IETF. Now we have it. We should use > it as we use SMTP. And the fact that our law is better than theirs > should be an aid, not a hindrance! We have an IETF specification, but this does not stand over the law. We can specify as much as we want, if this is not a within the legal framework we can't use it. And that is exactly what I mean, the rfc you mention does not take in account that European legal system is opt-in and not opt-out. Same on the different direction. Most ESPs in the US don't care about opt-ins which is legally recommended in Europe. This is a basic difference between the US and Europe which can not be ironed onto the same level. The outcome must be the same, but the way to this will be different. Thanks, Tobias From wiegert at telus.net Mon Jul 30 00:39:23 2012 From: wiegert at telus.net (Arnold) Date: Sun, 29 Jul 2012 15:39:23 -0700 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50156938.9070204@abusix.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> <50156938.9070204@abusix.com> Message-ID: <5015BB9B.5040808@telus.net> On 29/07/2012 9:47 AM, Tobias Knecht wrote: ---------snip -------- > That is not the problem at all. The problem is, that a > user clicking on the spam button has every time he clicks > on the spam button acknowledge that his mail is being sent > to a third party. And in addition to that he has > explicitly acknowledge the receiver. Think about 50 spam > messages per day. That would mean that the a user has to > click 50 times the spam button, than 50 times "Yes I want > to report this message!" and than 50 times "I'm okay that > this message will be sent to X!" > > From a usability point this is ridiculous and exactly that > is one of the main problems. And in addition to that ISPs > would like to provide FBLs, but they do not want to annoy > customers with this harassment, because users would not do > it and as soon as there will be a way around it they will > not do it because they are afraid it's getting complicated > again. > > We first need to find a simple for end users secure way to > report that does not destroy the usability and the trust > and than come up with solutions. For myself, the number of clicks per report would not be the issue. Currently, if there is an abuse address in the Whois record, my utility takes about ~6-10 clicks, including some highlighting, to send a report, something that can be done in a matter of seconds - not counting the ISP response time for sending the report e-mail. If the Whois record does not contain an abuser address, then it will take considerably more clicks and time, depending on how determined I want to be - I do keep a log of reported addresses and so could follow up if it seemed expedient and/or necessary. The number of clicks here is not the real issue for me. The real issue is whether or not the receiver will actually fix the problem so that I won't have to repeat the 6-10 clicks for the next so many weeks or more. In short, I am very much in favor of _enforced mandatory fields_, but it is just as important to _enforce the action_ on these reports, otherwise they are just as useless as missing or misleading abuse addresses, no matter how 'convenient' reporting might be made. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From lists at help.org Mon Jul 30 07:51:53 2012 From: lists at help.org (lists at help.org) Date: Mon, 30 Jul 2012 01:51:53 -0400 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5014E9D5.5030102@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> <5014E3DD.7020300@powerweb.de> <5014E9D5.5030102@help.org> Message-ID: <501620F9.2080807@help.org> I think you need to first develop 2 tables (working with other groups/RIR's). Across the top is the RIR's. The first tables should list the data fields and the second table list the queries and what data elements they return. Then you can see what the RIR's all have in common and explain the differences/reasons in the elements of the table. Then look at what is common among the RIR's and come up with a standard. Then you can focus on the individual elements and decide what to do with the eventual goal being a common standard among all RIR's. To get over the opt-in/opt-out law differences you could consider allowing "private" instead the real data, allow a link to a form web page rather than a contact person, or demand an opt-in agreement when the data is collected, etc. From ripe-anti-spam-wg at powerweb.de Mon Jul 30 09:02:28 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 30 Jul 2012 09:02:28 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <501620F9.2080807@help.org> References: <50143B4A.6020006@powerweb.de> <50146FA9.4040503@help.org> <5014E3DD.7020300@powerweb.de> <5014E9D5.5030102@help.org> <501620F9.2080807@help.org> Message-ID: <50163184.5010702@powerweb.de> lists at help.org wrote: > I think you need to first develop 2 tables (working with other > groups/RIR's). Across the top is the RIR's. The first tables should list > the data fields and the second table list the queries and what data > elements they return. Then you can see what the RIR's all have in common > and explain the differences/reasons in the elements of the table. Then > look at what is common among the RIR's and come up with a standard. Then > you can focus on the individual elements and decide what to do with the > eventual goal being a common standard among all RIR's. Sounds resonable, but is really somthing for the db-wg or another place where this worldwide RFC could be developed. Feel free to send a proposal, its defny welcome. > To get over the opt-in/opt-out law differences you could consider > allowing "private" instead the real data, allow a link to a form web > page rather than a contact person, or demand an opt-in agreement when > the data is collected, etc. I cant really see, why a development of a new whois standard needs to be first, until then I would focus on the mandatory field to help abuse reporting and the cleanup of RIPEs database. 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 iane at sussex.ac.uk Mon Jul 30 12:55:09 2012 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 30 Jul 2012 10:55:09 +0000 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50121CF3.9050002@help.org> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> <50121CF3.9050002@help.org> Message-ID: <5780F09E-04F1-4145-B37C-A38AFA096AFC@sussex.ac.uk> On 27 Jul 2012, at 05:45, lists at help.org wrote: > You don't need to be a lawyer to understand that once someone gives permission to publish data related to them then the privacy laws no longer apply to that situation. Actually, that's not true. What's required is "free consent". Free consent means that there are no conditions attached. So, for example, employers have to be very careful that they don't pressure (even accidentally) their employees. Given that many employees will never say no, it's almost impossible for employers to ask for *free* consent to anything. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From iane at sussex.ac.uk Mon Jul 30 13:02:41 2012 From: iane at sussex.ac.uk (Ian Eiloart) Date: Mon, 30 Jul 2012 11:02:41 +0000 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50121CF3.9050002@help.org> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> <50121CF3.9050002@help.org> Message-ID: <6A3AC2E2-036B-4117-AE7A-F31807C25BA0@sussex.ac.uk> On 27 Jul 2012, at 05:45, lists at help.org wrote: > You don't need to be a lawyer to understand that once someone gives permission to publish data related to them then the privacy laws no longer apply to that situation. Actually, that's not true. What's required is "free consent". Free consent means that there are no conditions attached. So, for example, employers have to be very careful that they don't pressure (even accidentally) their employees. Given that many employees will never say no, it's almost impossible for employers to ask for *free* consent to anything. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From tk at abusix.com Tue Jul 31 12:42:29 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 12:42:29 +0200 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <20120728173955.GS24669@x28.adm.denic.de> References: <5003D8A5.9050505@heanet.ie> <20120728173955.GS24669@x28.adm.denic.de> Message-ID: <5017B695.6050504@abusix.com> Hi, > While I agree with some of the goals of 2011-06, I object to the > proposal in its current form. In fact, I think it is not even ready > for the Review Phase, even though I understand that was the way to > invoke the NCC impact analysis. Here's already one reason to object: the > proposal itself is hardly comprehensible without said impact analysis > but since the latter is not part of the proposal it can only be > considered transient. Without even remotely suggesting the NCC was driving > policy here, I must say with both hesitance and regret that I am not > comfortable with the role the NCC has been dragged into w.r.t 2011-06. I partly agree with you. This proposal is a bit different than what RIPE Community and RIPE NCC is usually looking at, as far as I can remember. And it is sometimes tricky to fit it into the existing processes, but the real funny thing is that there will be a lot of proposals like this in future, promised But I'm absolutely not agreeing with you about the role RIPE NCC is taking here. I think RIPE NCC is at the moment taking their role very seriously and is doing exactly what they need to do. They are consulting from a technical perspective which makes a lot of sense since RIPE NCC has to develop and maintain the system. It was the TFs and communities wish that I rewrite the proposal and keep to deep technical specifications out of it and just define the feature set I'm looking for. But since you have not specified what exactly you do not like at RIPE NCCs role at the moment it is hard to answer more specific. > o The proposal and impact analysis are unclear about the aspects of > data protection issues for the "abuse-mailbox:" attribute. It appears > it is intended to "by definition" avoid PII here. How would that work > for address space allocated (or, more importantly, assigned) to a natural > person? That said, the proposal is also unclear whether the abuse-c: would > apply to PI space, as well. I'm not sure if I really got your point here, but I will give it a try. I do not see data protection issues with the "abuse-mailbox:" attribute, because it's clearly defined that it is not personal data. And in addition to that it is part of an role object, which usually should not contain personal data either. This is one point that was wanted by me as a proposer and was supported by the TF and the community, that information required to report security incidents must be unrestricted. If IP space is allocated or assigned to a natural person and there is an abuse-c, the abuse-c should not contain the information of the natural person, because it is a role and not a person. And I found this part of Denis' explanation very interesting: "Also the original intention of the database design was to represent people by PERSON objects and to group people into roles using ROLE objects. Then only ROLE objects should be referenced in any other data objects. [...] This methodology is explained in the RIPE Database Update Reference Manual, but was never enforced in the database software." If this original intention would be enforced we would not have this conversation here and maybe this is something we should as well think of in the near future. > o The proposal uses unclear language w.r.t. the mandatory nature of the > "abuse-c:" attribute: > > ``This policy introduces a new contact attribute named "abuse-c:", that can > be included in inetnum, inet6num and aut-num objects. '' > > vs. > > ``The role objects used for abuse contact information > will be required to contain a single "abuse-mailbox:" attribute which is > intended for receiving automatic and manual reports about abusive behavior > originating in the resource holders' networks.'' What are we talking here about? The mandatory need of an "abuse-c:" or the mandatory need of an "abuse-mailbox:" attribute within the mandatory "abuse-c:" "The "abuse-c:" will be mandatory for all aut-nums." This one should be clear. "Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an "abuse-c:". Inherited objects might have their own "abuse-c:" attribute or they will be covered by the higher level objects." "abuse-c:" is mandatory for direct allocated inetnums and inet6nums. For all the others it is optional. But if there is an "abuse-c:" object, no matter where it is, it is mandatory that it has an "abuse-mailbox:" attribute. I do not see the confusion here. > o The second paragraph quoted above expresses an expectation regarding the > handling of submitted email reports (what else would it mean to be prepared for > "receiving automatic and manual reports"?) Is that a problem? Asking for an "email:" attribute in any other object expresses the expectation to receive mail. If you read the mail or not is not part of the policy and can't be forced in any way. This is nothing else than transferring a known and used best practice into a policy text. This has been done at RIPE, ARIN, ..., IETF a thousand times before and is imho the way to go with best practices and common used techniques. > o The purpose of the "e-mail:" attribute is given with "other". I do not > understand that. I would suggest to separate the targets for 'manual' and > 'machine readable' reports. It is natural for any object in the RIPE DB to > use the 'email:' attribute for email communication. {this is listed for > completeness; i have read the longthread on the topic and don't suggest > to rehash. The proposal, in summary, has bigger problems.} The address of the "e-mail:" attribute is for communication between the roles and not for receiving reports. It's intended for everything other than reports. For example verification emails, communication between abuse desk of different institutions. Maybe asking questions about reports sent between each other. Maybe exchanging technical information about things and stuff. Just for the completeness: Splitting up into different addresses didn't find imho consensus here, so I think this is not an option at all. > o The proposal is unclear at least about the future of irt: objects. Right. Because this proposals intent is not to discuss the future of the irt object. We mentioned that at the very beginning and in another thread about this subject we decided with people from the irt community being involved that the irt object is another topic and needs to be reviewed. But whatever will happen with the irt object it is not part of this proposal. > o Finally, and most importantly, I object to the mandatory nature of the attribute. The "abuse-c:" attribute or the "abuse-mailbox: attribute? Or both? As mentioned above the "abuse-c:" attribute is only mandatory in aut-nums and in direct allocated inetnums and inet6nums. And I do not see any reason that this might be a problem since some internal statistics we have made show that more than 96% of the direct allocations have already published an abuse contact in any way and we were not even able to catch them all for some of the reasons we have discussed here. Talking about the "abuse-mailbox:" attribute I found the other thread about splitting up into automatic and manual report addresses that people are comfortable with the idea of a mandatory "abuse-mailbox:" attribute. It also makes a lot of sense for me, because the "abuse-mailbox:" attribute is already known and used for this purpose, just in a little confusing way. So I'm really interested in hearing more reasons for your objection here no matter if you are talking about the "abuse-c:" or the "abuse-mailbox:" attribute. > Neither the impact analysis nor the counter arguments section assess the impact > of presence of an abuse (role) object and the resulting actions on maintainers/... > LIRs/NCC members. We have discussed these things here on the list and as far as I can remember we were able to handle counter arguments, such as the mandatory "abuse-c:" for "all" inetnums and inet6nums by changing the policy text. Same with the irt object, which will be reviewed in another step. At the moment I can't remember more than these things, but people who came up with these concerns have later on agreed that their concerns have been heard and solved by changing the policy text, that's why we do not have any more concerns that found a majority and have been accepted as concerns on this list. And I would like to stay on this path and rather find solutions to objections that make sense and find consensus within the community than mentioning them as objections and keep them as objections in the proposal. Thanks for your input and I hope I was able to clarify some things. Tobias From jorgen at hovland.cx Tue Jul 31 13:59:08 2012 From: jorgen at hovland.cx (Jørgen Hovland) Date: 31 Jul 2012 11:59:08 +0000 (GMT) Subject: [anti-abuse-wg] 2011-06 Review Phase Extension Message-ID: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> An HTML attachment was scrubbed... URL: From brian.nisbet at heanet.ie Tue Jul 31 14:04:02 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 31 Jul 2012 13:04:02 +0100 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <20120728173955.GS24669@x28.adm.denic.de> References: <5003D8A5.9050505@heanet.ie> <20120728173955.GS24669@x28.adm.denic.de> Message-ID: <5017C9B2.5080507@heanet.ie> Peter, Obviously Tobias has addressed a number of points, but I wanted to just touch on one particular thing: Peter Koch wrote the following on 28/07/2012 18:39: > On Mon, Jul 16, 2012 at 10:02:29AM +0100, Brian Nisbet wrote: > >> would ask if members could raise any points that they are still >> uncertain about and state as clearly as possible, their current opinion >> on the proposal. > > I have read version 3.0 of 2011-06 and the NCC's impact analysis. > > While I agree with some of the goals of 2011-06, I object to the > proposal in its current form. In fact, I think it is not even ready > for the Review Phase, even though I understand that was the way to > invoke the NCC impact analysis. Here's already one reason to object: the > proposal itself is hardly comprehensible without said impact analysis > but since the latter is not part of the proposal it can only be > considered transient. Without even remotely suggesting the NCC was driving > policy here, I must say with both hesitance and regret that I am not > comfortable with the role the NCC has been dragged into w.r.t 2011-06. Could you be a little more clear with regards to this discomfort? The NCC, in all the conversations we've had with them, have been very happy to assist the community in this regard and while it is acknowledged that there will be work to do, they have given us the message that it is work they will do should the policy be approved. I suppose I'm uncertain of how else we could proceed? As with any policy I want to make sure that there is no doubt the PDP was followed correctly, and while obviously there are other checks & balances, part of this is ensuring that this WG feels things have been undertaken in the correct way. Thanks, Brian. From shane at time-travellers.org Tue Jul 31 14:15:14 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 31 Jul 2012 14:15:14 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50143B4A.6020006@powerweb.de> References: <50143B4A.6020006@powerweb.de> Message-ID: <20120731141514.40cdaa43@shane-desktop> Frank, On Saturday, 2012-07-28 21:19:38 +0200, Frank Gadegast wrote: > I really have the feeling, that some in the community fear > a mandatory abuse field, and try find any strange argument > against it, but I really cannot see why. I think the resistance comes because a number of related ideas have been tried in the past, and they have failed. So we'd like to see whatever abuse reporting changes made don't just add to the current confusion without actually improving anything. > If somebody does not want to receive abuse reports or > does not want to do something against abuse originating > from his own resources or likes to receive them not via > email or has whatever else reason, well, name it > this-email-address-is-not-being-read at yourdomain.com > or > no-reply at example.com > or send it to devnull ... Yes, that is correct. So the question is "why make it mandatory then?" Your answer seems to be: > On the other end, a mandatory abuse field will > clean up everything in RIPEs database, remove > the unparseble remarks, will help the abuse teams > to receive reports only to ONE address, because > sender can be educated, abuse tools can be > simplified and integrated in webpages easily aso ... > A mandatory abuse field has that much advantages > for everybody who likes to work against abuse, > that I cannot understand, why people, that do not > want the same for there own reasons are against > it. Let us optimize our procedures and > if you do not want to participate, well > set the email address to whatever or ignore every > incoming mail ... This all seems unrelated to whether a field is mandatory or not. Rather this seems more like an exercise in making the abuse reporting information in the database more rational - which seems like quite a reasonable goal. > Those people are not concerned, that they > have to do something against abuse coming > from there OWN resources, it must be the people > that are causing the abuse problem in the first place, > its there business, and so they are worried, that > others find easier and better methods in preventing > abuse. > > So, my personal summary is: > --- > Anybody, who is against a mandatory abuse field, > is a professional spammer, abuser, maintains > a bot net or sells open proxies or other services > used for abusing others. > They are criminals to my opinion. > > But thats only my impression ... > --- I promise you I am neither a professional spammer, abuser, nor do I maintain a bot net or sell open proxies or other services used for abusing others. As I said in the beginning, I'd just like to make sure that whatever is done actually improves things. Mind you, I'm not totally opposed to a mandatory abuse field, I just don't see the point without a policy governing how it is used. I would be quite supportive of a policy which said something like: If someone reports that an abuse mailbox is unresponsive to the RIPE NCC, they will investigate. If the RIPE NCC also finds the abuse mailbox is unresponsive, then they will alert the resource holder. If the resource holder has not fixed the problem within 30 days, then the resources will be revoked. If the holder tries to hide an unresponsive abuse mailbox, for example by adding a filter that allows RIPE NCC mails through but ignores all others, then resources will be revoked immediately. I just think that such a policy has no chance of being approved. :) Cheers, -- Shane From ripe-anti-spam-wg at powerweb.de Tue Jul 31 14:16:24 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 31 Jul 2012 14:16:24 +0200 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> References: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> Message-ID: <5017CC98.2020608@powerweb.de> J?rgen Hovland wrote: > > > At 10:42 31/07/2012 (UTC), Tobias Knecht wrote: > > > > > So I'm really interested in hearing more reasons for your objection here > > no matter if you are talking about the "abuse-c:" or the > > "abuse-mailbox:" attribute. > > > Just to make things clear about real consequences of mandatory abuse-c: > > 1. > None of our customers have an abuse department or abuse contact (and > often tech person). We will therefore bulk update the abuse-c with the > value from the admin-c handle. Well, its your decision, if you like to reveal personal data via the abuse-c. In fact, you shouldnt do this. You could either: - set the abuse contact email address to abuse at customerdomain.de automatically and inform your customers, that this email address has to be read from now on - inform and educate your customers to tell you another address - you could set it to something like abuse-inetnum-x-x-x-x at hovland.cx and forward incoming mail to your (and now hidden) customers email address and if your customer does not like to have incoming mails mixed with his other mails, well, he could tell you another address - or set it to your own abuse address and handle incoming reports for your customer > 2. > The e-mail field in the role object (abuse-c requires a role object) is > mandatory. We actually have customers that do not have an email address > or haven't provided one (probably also dont want to provide one). In > these cases, I guess the e-mail field will be populated with a bogus > email address in the form "there.is.no at email.address" and perhaps insert > remarks: with company URL instead etc. What is absolutly ok. The proposol is not forcing resource owners to have a working abuse department, its simply forcing all objects to have a single place where to store abuse addresses. But: the proposal is a nice starting point to educate resource owners, so it would be really nice, if you make your customers aware of abuse problems and how your customer should deal with them. Kind regards, Frank -- -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ripe-anti-spam-wg at powerweb.de Tue Jul 31 14:52:58 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 31 Jul 2012 14:52:58 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <20120731141514.40cdaa43@shane-desktop> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <5017D52A.9050206@powerweb.de> Shane Kerr wrote: > Frank, Hi Shane, > > Yes, that is correct. So the question is "why make it mandatory then?" The example from hovland.cz in one of the last mails was pretty good. His customers do not have a working abuse department and maybe even no email address. So: a mandatory field is a good point to start discussing this with your customers ;o) Not only to stop abuse from those networks, but wich customer likes to have his resources abused and NOT know about it ? You can even sell it as a service ... A break-in is not only a problem to others, that are abused after the break-in, is also a problem for the service itself ... and is not everybody concerned, that his data could be stolen ? Im always happy to receive whatever report. I rather receive 30 reports leading to nothing (because they are simply wrong, like the reports from spamcop, that usally are reported from users that simply forgot that they susbribed to a customers newsletter once or are to lacy to unsubscibe), when just one shows me a potential security problem with my customers services. It a service for our customers, and they all love it, when we can keep them informed about new software versions, they should update to or similar. So: why should anybody not be interested if his services are hacked ? Another (somehow funny) example I had last week with a German ISP, we reported too. He replied, that hes not doing anything about break-ins into the services he runs for his customers, simply because its too expensive and he could not compete with others in the market, if he would. One of his root servers got hacked and the hacker installed an etherner-sniffer and read all the password from his other customers. The hacker then broke into another customers server and stole a lot of data. Now, the ISP is brought to court by this other customer, because hes a "Mitstoerer" in German law, he knew about the risk and did not do anything. And the police already ask us, if we informed that ISP about the spam coming from one if his machines. We surely said: yes. They then ask, if we got a reply and said yes again. I guess, he will loose this case and will be broke afterwards loosing his business completely. And all his customers will hopefully ask their new ISPs, if they have a working abuse department (that also good education). > If someone reports that an abuse mailbox is unresponsive to the RIPE > NCC, they will investigate. If the RIPE NCC also finds the abuse > mailbox is unresponsive, then they will alert the resource holder. If > the resource holder has not fixed the problem within 30 days, then > the resources will be revoked. If the holder tries to hide an > unresponsive abuse mailbox, for example by adding a filter that > allows RIPE NCC mails through but ignores all others, then resources > will be revoked immediately. > > I just think that such a policy has no chance of being approved. :) Your probably right, but I think, its a shame that something like this is not possible. Kidn regards, Frank -- -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 michele at blacknight.ie Tue Jul 31 15:01:44 2012 From: michele at blacknight.ie (Michele Neylon :: Blacknight) Date: Tue, 31 Jul 2012 13:01:44 +0000 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <20120731141514.40cdaa43@shane-desktop> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: Dumb question, but does the abuse field have to be an email address? Can it be a web address instead? Regards Michele Mr Michele Neylon Blacknight Solutions ? Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ http://blacknight.cat http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 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 tk at abusix.com Tue Jul 31 15:10:28 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 15:10:28 +0200 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5017CC98.2020608@powerweb.de> References: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> <5017CC98.2020608@powerweb.de> Message-ID: <5017D944.5050707@abusix.com> Hi, >> 1. >> None of our customers have an abuse department or abuse contact (and >> often tech person). We will therefore bulk update the abuse-c with the >> value from the admin-c handle. > > Well, its your decision, if you like to reveal personal data via > the abuse-c. In fact, you shouldnt do this. > > You could either: > - set the abuse contact email address to abuse at customerdomain.de > automatically and inform your customers, that this email address > has to be read from now on > - inform and educate your customers to tell you another address > - you could set it to something like abuse-inetnum-x-x-x-x at hovland.cx > and forward incoming mail to your (and now hidden) customers > email address and if your customer does not like to have incoming > mails mixed with his other mails, well, he could tell you > another address > - or set it to your own abuse address and handle incoming reports > for your customer And there is another even better solution. Since the "abuse-c:" will not be required for all inet(6)nums only for the direct allocations you do not have to set one up for your customer. You just leave it empty and yours or the one of your the company above you can be used. So it is not mandatory for everybody. If you decide that you want to handle abuse for all your customers do it like I said before. If you want your customers or one of your customers wants to do it by him self set up the "abuse-c:" for your/this customer. So you have to make the decision on how you want to handle things, the proposal just gives you the right tools. Thanks, Tobias From tk at abusix.com Tue Jul 31 15:22:38 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 15:22:38 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <20120731141514.40cdaa43@shane-desktop> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <5017DC1E.5080003@abusix.com> Hi, > I think the resistance comes because a number of related ideas have > been tried in the past, and they have failed. So we'd like to see > whatever abuse reporting changes made don't just add to the current > confusion without actually improving anything. And I fully understand this point. And that is one of the reasons why we wanted RIPE NCC to consult with this, to get a better view on how we can clean up the mess that is existing with a better solution. At the moment I think the proposal hits a lot of points that would make things easier and even if we figure out that we missed something or we need something more or less, we are moving in the same framework as we do with admin-c and tech-c and this will make it much more flexible for future change requests than what we have at the moment. > As I said in the beginning, I'd just like to make sure that whatever is > done actually improves things. So what is your feeling with the latest version of the proposal? Does it improve things? > Mind you, I'm not totally opposed to a mandatory abuse field, I just > don't see the point without a policy governing how it is used. I would > be quite supportive of a policy which said something like: I fully agree. But we can not go all the steps at once. Believe me this is not the last proposal I'm coming up with ;-) We have the data accuracy part and some other things that we need to take care of. > If someone reports that an abuse mailbox is unresponsive to the RIPE > NCC, they will investigate. If the RIPE NCC also finds the abuse > mailbox is unresponsive, then they will alert the resource holder. If > the resource holder has not fixed the problem within 30 days, then > the resources will be revoked. If the holder tries to hide an > unresponsive abuse mailbox, for example by adding a filter that > allows RIPE NCC mails through but ignores all others, then resources > will be revoked immediately. I would probably not agree to that in that restrictive way, but yes there must be a way to figure these things out, but as already said, one step after the other and not everything at once. > I just think that such a policy has no chance of being approved. :) I definitively agree on that, but that will be another box of fun to find a common accepted way. :-) Thanks, Tobias From shane at time-travellers.org Tue Jul 31 15:23:20 2012 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 31 Jul 2012 15:23:20 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <20120731152320.0daa0dc9@shane-desktop> Michele, On Tuesday, 2012-07-31 13:01:44 +0000, "\"Michele Neylon :: Blacknight\"" wrote: > Dumb question, but does the abuse field have to be an email address? > > Can it be a web address instead? I guess the idea is that some people prefer to limit the spam they get to their abuse mailboxes by requiring that people use a web form? In that case, a web address seems like a good option to me. Cheers, -- Shane From tk at abusix.com Tue Jul 31 15:33:23 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 15:33:23 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <5017DEA3.8000603@abusix.com> Hi, > Dumb question, but does the abuse field have to be an email address? Not dumb, but yes it must be an email address. > Can it be a web address instead? No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses. If there is a major need for web addresses to be published it would be another attribute that would be optional. The mandatory character of the "abuse-mailbox:" would not be changed. Thanks, Tobias From denis at ripe.net Tue Jul 31 15:50:18 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 31 Jul 2012 15:50:18 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <5017E29A.8020702@ripe.net> Dear Michele This is a very reasonable question. One of the technical advantages of the "abuse-c:" proposal is that it references an object in which is stored contact information. Currently the discussion is focussing on an "abuse-mailbox:" attribute in that object as the primary contact method. As Tobias said, technically, we could easily add an additional "abuse-url:" attribute if required. Or anything else like "abuse-im:" or "abuse-mobile:". If we have the framework referencing a contact object then whatever the community wants inside that object is possible. You just decide what methods you want and what should be mandatory, required, optional, this or that, etc and the RIPE NCC can build it. From the point of view of the Abuse Finder tool the important step is to have one method of finding the abuse contact from an IP address. Once we can easily find it, you can have as much variation as you like in terms of contact methods. The Abuse Finder tool can just report to the user whatever options you have supplied. Regards Denis Walker Business Analyst RIPE NCC Database Group On 31/07/2012 15:01, "Michele Neylon :: Blacknight" wrote: > Dumb question, but does the abuse field have to be an email address? > > Can it be a web address instead? > > Regards > > Michele > > > Mr Michele Neylon > Blacknight Solutions ? > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.co > http://blog.blacknight.com/ > http://blacknight.cat > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > 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 leo.vegoda at icann.org Tue Jul 31 15:50:25 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Jul 2012 06:50:25 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <50143B4A.6020006@powerweb.de> References: <50143B4A.6020006@powerweb.de> Message-ID: <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> Hi Frank, On Jul 28, 2012, at 12:19 pm, Frank Gadegast wrote: [?] > If somebody does not want to receive abuse reports or > does not want to do something against abuse originating > from his own resources or likes to receive them not via > email or has whatever else reason, well, name it > this-email-address-is-not-being-read at yourdomain.com > or > no-reply at example.com > or send it to devnull ? I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters? > Lots of resource holders are already doing the same, > we keep a list of there email addresses, so > we do not have to send them reports that > will only fill our mail queue to bounce back. > I can understand them and respect that others > like to work things different and we do not > send them reports anymore. I do not want to encourage the development of more business logic like this. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4359 bytes Desc: not available URL: From leo.vegoda at icann.org Tue Jul 31 15:54:46 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Jul 2012 06:54:46 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017DEA3.8000603@abusix.com> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> <5017DEA3.8000603@abusix.com> Message-ID: Hi Tobias, On Jul 31, 2012, at 6:33 am, Tobias Knecht wrote: [?] > No. We had that conversations already and decided not to accept web > addresses only. The reason is, that automatic reporting can not be done > with web addresses. Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4359 bytes Desc: not available URL: From ripe-anti-spam-wg at powerweb.de Tue Jul 31 16:03:12 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 31 Jul 2012 16:03:12 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> Message-ID: <5017E5A0.3020907@powerweb.de> Leo Vegoda wrote: > Hi Frank, > > On Jul 28, 2012, at 12:19 pm, Frank Gadegast wrote: > >> or >> no-reply at example.com >> or send it to devnull ? > > I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters? Simply because its better to have ONE place for reporters. Forcing these addresses to be working and correct is not part of this proposal and could be discussed later (and fixed with another proposal). Currently there are lots of places to store the abuse-contact and a lot of them are wrong, because of a lie, lacyness, technical problems or whatsoever. In future you will have only one place to look for it, probably also with a lot of wrong addresses. Anyway, it would be better than it is now. >> Lots of resource holders are already doing the same, >> we keep a list of there email addresses, so >> we do not have to send them reports that >> will only fill our mail queue to bounce back. >> I can understand them and respect that others >> like to work things different and we do not >> send them reports anymore. > > I do not want to encourage the development of more business logic like this. You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting ... Kind regards, Frank > > Regards, > > Leo Vegoda > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 ripe-anti-spam-wg at powerweb.de Tue Jul 31 16:07:37 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 31 Jul 2012 16:07:37 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> <5017DEA3.8000603@abusix.com> Message-ID: <5017E6A9.9050008@powerweb.de> Leo Vegoda wrote: > Hi Tobias, > > On Jul 31, 2012, at 6:33 am, Tobias Knecht wrote: > > [?] > >> No. We had that conversations already and decided not to accept web >> addresses only. The reason is, that automatic reporting can not be done >> with web addresses. > > Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement. > Another point for the abuse-c. It can be enhanced. An optional abuse-url field is really a good idea, if there would be an standarized ARAPI (Abuse Report API ?) > Regards, > > Leo Vegoda > Kind regards, Frank -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 leo.vegoda at icann.org Tue Jul 31 16:28:41 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Jul 2012 07:28:41 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017E5A0.3020907@powerweb.de> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> Message-ID: <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> Hi Frank, On Jul 31, 2012, at 7:03 am, Frank Gadegast wrote: > Leo Vegoda wrote: >> Hi Frank, >> >> On Jul 28, 2012, at 12:19 pm, Frank Gadegast wrote: >> > >>> or >>> no-reply at example.com >>> or send it to devnull ? >> >> I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters? > > Simply because its better to have ONE place for reporters. I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly. > Forcing these addresses to be working and correct is > not part of this proposal and could be discussed later > (and fixed with another proposal). > > Currently there are lots of places to store the abuse-contact > and a lot of them are wrong, because of a lie, lacyness, > technical problems or whatsoever. I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though. > In future you will have only one place to look for it, > probably also with a lot of wrong addresses. > > Anyway, it would be better than it is now. > >>> Lots of resource holders are already doing the same, >>> we keep a list of there email addresses, so >>> we do not have to send them reports that >>> will only fill our mail queue to bounce back. >>> I can understand them and respect that others >>> like to work things different and we do not >>> send them reports anymore. >> >> I do not want to encourage the development of more business logic like this. > > You do need this logic already (even if that logic consist only > of an reply-address for your abuse reports, that you do not read at all ;o) > You already have this logic, if you have a ticket system for the reports > you send out. You then have to deal with all these bounces since you > started reporting ? By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4359 bytes Desc: not available URL: From tk at abusix.com Tue Jul 31 16:34:28 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 16:34:28 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017E6A9.9050008@powerweb.de> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> <5017DEA3.8000603@abusix.com> <5017E6A9.9050008@powerweb.de> Message-ID: <5017ECF4.3010907@abusix.com> Hi, >>> No. We had that conversations already and decided not to accept web >>> addresses only. The reason is, that automatic reporting can not be done >>> with web addresses. >> >> Assuming you mean something accessible over HTTP or HTTPS, it does not >> have to be accessed by a person using a browser. If there was a widely >> adopted API, I can see the value in a URL for some kind of RESTful >> service for automatic reports that do not require human involvement. Right. If we are talking about an RESTful API based system that is absolutely fine. At the moment we do not have such an system in place, but as soon as we have I will be the last person to ignore it. At the moment email with it's standards like (m)ARF and x-arf and IODEF and all these are common practice. And we need a solution for this common practice. > An optional abuse-url field is really a good idea, if there would be an > standarized ARAPI (Abuse Report API ?) As soon as we have something in place, I will write the proposal. Promised ;-) Thanks, Tobias From ripe-anti-spam-wg at powerweb.de Tue Jul 31 17:14:52 2012 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Tue, 31 Jul 2012 17:14:52 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> Message-ID: <5017F66C.6030703@powerweb.de> Leo Vegoda wrote: > Hi Frank, > > On Jul 31, 2012, at 7:03 am, Frank Gadegast wrote: >> Leo Vegoda wrote: >>> Hi Frank, >>> >>> On Jul 28, 2012, at 12:19 pm, Frank Gadegast wrote: >>> >> >>>> or >>>> no-reply at example.com >>>> or send it to devnull ? >>> >>> I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters? >> >> Simply because its better to have ONE place for reporters. > > I don't think I have been clear. You were clear. > Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly. Hm, this is estimation. There are people that are not publishing contacts, because - they dont know that they can or should, simply because nobody told them or that their RIPE member decided not to publish some - some have typing mistakes - some have deliberatly wrong format, hoping that only humans report (like @ti.ru.only or some adding a .remove.this.suffix at the end) You cannot say whats really happening. It could be that the amount of right and working contacts is increasing. Or you could be right. You cannot compare both situations (the current and the coming) right now, I would say, its getting easier for the reporter, because then you can send a report and analyse any bounces. You will see, if the resource owner wants a report, after your report bounces. Currently there are a lot of networks, that probably want a report, but you will send it to the wrong address, simply because you cannot make a decision, wich contact or remarks or IRT object you should use. A lot of reports are being send to a contact, that was not intended by the resource owner and will be ignored or unread because of the current situation. >> >> Currently there are lots of places to store the abuse-contact >> and a lot of them are wrong, because of a lie, lacyness, >> technical problems or whatsoever. > > I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. > I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. Like sayd before, the abuse-c will lead to an semi-automatic clean-up, because the resource owners have to re-think his situation. Surely they will remove a lot of old remarks and IRT objects used only for this purpose, simply because its right. > In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though. Neat is nice ;o) >> You do need this logic already (even if that logic consist only >> of an reply-address for your abuse reports, that you do not read at all ;o) >> You already have this logic, if you have a ticket system for the reports >> you send out. You then have to deal with all these bounces since you >> started reporting ? > > By forcing people to tell a lie about where to send reports you just exacerbate the problem. See above. The reporter can then 100% sure, that he picked the right address, and if it bounces, well, looks like to resource holder does not want reports ... makes things much easier for the reporter. > I do not think "but you have to do this anyway" is a good reason for making the problem bigger. If there is something non-mandatory, you cannot decide if the resource owner deliberatly decided not to publish one, or if he simply forgot to add one (because he is not forced too). There is lots of field, that could be added, but nobody does it, because its less work (even if its useful for himself). I guess, that there are lots of old objects, that were not updated, when the abuse-mailbox field was introduced. Having it non-mandatory will lead to more confusion, because the resource owners thinks, that everything is in its place and keeps the old methods. So, having it non-mandatory will make the problem bigger like you sayd. Having it mandatory will result in a semi-automated cleanup and a real decision by the resource owner, like the NCC outlined in the proposal. An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ... Kind regards, Frank > > Regards, > > Leo Vegoda > -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- 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 denis at ripe.net Tue Jul 31 17:15:17 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 31 Jul 2012 17:15:17 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> Message-ID: <5017F685.3090903@ripe.net> Dear Leo As I follow these discussion my mind keeps focussing on the Abuse Finder tool and the technical nightmare we have right now in trying to make that work. One of the many problems with it is we cannot parse remarks that (may) include abuse contacts. Even with the "abuse-c:" proposal we still cannot 'prevent' (by any technical means) users from putting an abuse contact in a remark anywhere in their data set that seems a logical place to them. Using a double negative approach (if you don't want to handle abuse, don't add an abuse contact) presents the same technical problem for the Abuse Finder tool. Not all users of the RIPE Database read the documentation and follow discussions on the mailing lists. If there is no requirement to put an "abuse-c:" in a specific place, some of these users will still add it in a remark somewhere. Technically we can't prevent them and also will not know about it if they do. So if the community chooses to make it optional (and the RIPE NCC will implement it in whatever way the community chooses), you need to accept that the Abuse Finder tool cannot then take the absence of an "abuse-c:" to mean there is no abuse contact. We are still in the same state we are in now. All the Abuse Finder tool can say is, we can't find an abuse contact, but we saw some reference to the word 'abuse' in "remarks:" or "e-mail:" attributes in these objects, go take a look yourself because we are not sure. Regards Denis Walker Business Analyst RIPE NCC Database Group On 31/07/2012 16:28, Leo Vegoda wrote: > Hi Frank, > > On Jul 31, 2012, at 7:03 am, Frank Gadegast wrote: >> Leo Vegoda wrote: >>> Hi Frank, >>> >>> On Jul 28, 2012, at 12:19 pm, Frank Gadegast wrote: >>> >> >>>> or >>>> no-reply at example.com >>>> or send it to devnull ? >>> >>> I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters? >> >> Simply because its better to have ONE place for reporters. > > I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly. > >> Forcing these addresses to be working and correct is >> not part of this proposal and could be discussed later >> (and fixed with another proposal). >> >> Currently there are lots of places to store the abuse-contact >> and a lot of them are wrong, because of a lie, lacyness, >> technical problems or whatsoever. > > I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though. > >> In future you will have only one place to look for it, >> probably also with a lot of wrong addresses. >> >> Anyway, it would be better than it is now. >> >>>> Lots of resource holders are already doing the same, >>>> we keep a list of there email addresses, so >>>> we do not have to send them reports that >>>> will only fill our mail queue to bounce back. >>>> I can understand them and respect that others >>>> like to work things different and we do not >>>> send them reports anymore. >>> >>> I do not want to encourage the development of more business logic like this. >> >> You do need this logic already (even if that logic consist only >> of an reply-address for your abuse reports, that you do not read at all ;o) >> You already have this logic, if you have a ticket system for the reports >> you send out. You then have to deal with all these bounces since you >> started reporting ? > > By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger. > > Regards, > > Leo Vegoda > From tk at abusix.com Tue Jul 31 17:24:06 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 17:24:06 +0200 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> Message-ID: <5017F896.2010707@abusix.com> Hi, > I don't think I have been clear. Sorry. What I meant was that if > someone does not want reports and you force them to tell a lie about > where to send reports then you increase the burden on the reporter, > who has to parse the e-mail address and try to guess if it is a fake > address or not. If, instead, people who do not want to receive > reports do not have to publish an address then allowing them to not > publish an address allows the reporter to reach the same conclusion > more quickly. It's not only about the conclusion. As Frank stated there are some legal obligations in between. I do not want to go any deeper here, because I'm not a lawyer :-) The second point is that we probably only force less then 3% of the holders of direct allocations. More than 96% of them have already abuse contacts in place, unfortunately in different and ugly to parse places. I think there must be at least one abuse contact available for every ip address. And the proposal does not care about the place in hierarchy, but the "highest" place should offer one. > I think that standardising the place to publish an address and a > cleanup process for old data are distinct and separate problems. I > agree that the current mishmash of methods used makes life difficult > for reporters but making people add new data before a policy or > mechanism for cleaning old data has even been formally considered is > just going to make the problem bigger. In general, I support cleaning > up existing mess before making new mess. Maybe I'm just a "neat > freak", though. I guess we are all neat freaks :-) I'm not sure what your definition of cleaning is. But there is a clean up planned in the impact analysis. Unfortunately the mess is too big to completely clean it up before coming up with new things. The idea is to transfer as much information as possible automatically into the new framework. The things that can't be cleaned up automatically (remarks:) must be cleaned by the resource holders themselves. But just cleaning them up would result in less maybe valuable data in the database. So it is much better than having the new thing in place and ask for a transfer from old to new. That way we will not loose data. It would not make sense to delete all old things and than come up with a new. If cleaning up in your definition means the data accuracy, even than I would prefer the proposals way. By asking to transfer the data accuracy will be increased without anything special, because all the accidentally wrong, forgotten, misspelled,... objects will be updated. In an next step we have to find ways how we can increase data accuracy and how we can keep it on a good level. Which will be another proposal. Talking now about data accuracy would bring us into the situation to left out the abuse contact information, because there are plans that it get's changed (with this proposal) and brings us into the situation of not exactly knowing what we have to handle, because we do not exactly know what we are coming up with. >>>> Lots of resource holders are already doing the same, we keep a >>>> list of there email addresses, so we do not have to send them >>>> reports that will only fill our mail queue to bounce back. I >>>> can understand them and respect that others like to work things >>>> different and we do not send them reports anymore. >>> I do not want to encourage the development of more business logic >>> like this. >> You do need this logic already (even if that logic consist only of >> an reply-address for your abuse reports, that you do not read at >> all ;o) You already have this logic, if you have a ticket system >> for the reports you send out. You then have to deal with all these >> bounces since you started reporting ? > > By forcing people to tell a lie about where to send reports you just > exacerbate the problem. I do not think "but you have to do this > anyway" is a good reason for making the problem bigger. While thinking about the points here Frank and Denis sent their mails and the points they brought up are fitting perfectly, so I do not have to write anything here, because I agree fully with their argumentation. Thanks Frank. Thanks Denis. Thanks, Tobias From iane at sussex.ac.uk Tue Jul 31 18:12:13 2012 From: iane at sussex.ac.uk (Ian Eiloart) Date: Tue, 31 Jul 2012 16:12:13 +0000 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017E29A.8020702@ripe.net> References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> <5017E29A.8020702@ripe.net> Message-ID: On 31 Jul 2012, at 14:50, Denis Walker wrote: > Dear Michele > > This is a very reasonable question. One of the technical advantages of the "abuse-c:" proposal is that it references an object in which is stored contact information. Currently the discussion is focussing on an "abuse-mailbox:" attribute in that object as the primary contact method. > > As Tobias said, technically, we could easily add an additional "abuse-url:" attribute if required. Or anything else like "abuse-im:" or "abuse-mobile:". If we have the framework referencing a contact object then whatever the community wants inside that object is possible. You just decide what methods you want and what should be mandatory, required, optional, this or that, etc and the RIPE NCC can build it. Why not leave it at abuse-url: and let people use mailto: urls? So, they can put anything in there that has a url schema. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 From wiegert at telus.net Tue Jul 31 19:01:46 2012 From: wiegert at telus.net (Arnold) Date: Tue, 31 Jul 2012 10:01:46 -0700 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> References: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> Message-ID: <50180F7A.4070901@telus.net> On 31/07/2012 4:59 AM, J?rgen Hovland wrote: > > > At 10:42 31/07/2012 (UTC), Tobias Knecht wrote: > > > > > So I'm really interested in hearing more reasons for > your objection here > > no matter if you are talking about the "abuse-c:" or the > > "abuse-mailbox:" attribute. > -----8X------- > 2. > The e-mail field in the role object (abuse-c requires a > role object) is mandatory. We actually have customers that > do not have an email address or haven't provided one > (probably also dont want to provide one). In these cases, > I guess the e-mail field will be populated with a bogus > email address in the form "there.is.no at email.address" and > perhaps insert remarks: with company URL instead etc. If the customer refuses to give an abuse e-mail address, then the onus should fall back on to his ISP to provide a contact and then pass on the information or take action on the customers behalf. It is not only the _customer_ who impacted by SPAM, but also the ISP and the ISP in reality is merely delegating some authority to the customer, so in the end, it ought to be the ISP who is responsible and should take action, if the customer can't or refused to. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From wiegert at telus.net Tue Jul 31 19:07:32 2012 From: wiegert at telus.net (Arnold) Date: Tue, 31 Jul 2012 10:07:32 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> Message-ID: <501810D4.5030109@telus.net> On 31/07/2012 6:01 AM, "Michele Neylon :: Blacknight" wrote: > Dumb question, but does the abuse field have to be an email address? > > Can it be a web address instead? e-mail addresses can be handled a bit more 'automatically' for SPAM reporting using available utilities. A web URL, unless it is in a standard format, it will take an lot more manual input and much more time to copy and paste the relevant information. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From wiegert at telus.net Tue Jul 31 19:11:33 2012 From: wiegert at telus.net (Arnold) Date: Tue, 31 Jul 2012 10:11:33 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: References: <50143B4A.6020006@powerweb.de> <20120731141514.40cdaa43@shane-desktop> <5017DEA3.8000603@abusix.com> Message-ID: <501811C5.6030007@telus.net> On 31/07/2012 6:54 AM, Leo Vegoda wrote: > Hi Tobias, > > On Jul 31, 2012, at 6:33 am, Tobias Knecht wrote: > > [?] > >> No. We had that conversations already and decided not to accept web >> addresses only. The reason is, that automatic reporting can not be done >> with web addresses. > Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement. if it can be automated, it surely will be abused just as e-mail addresses. Why open another 'door' for SPAMMERs and then wonder why we will have to expend more effort to 'filter' what cames through. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml From lists at help.org Tue Jul 31 19:47:14 2012 From: lists at help.org (lists at help.org) Date: Tue, 31 Jul 2012 13:47:14 -0400 Subject: [anti-abuse-wg] 2011-06 Review Phase Extension In-Reply-To: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> References: <5017c88c4093d47a57004355f8ff.jorgen@hovland.cx> Message-ID: <50181A22.2080303@help.org> > it will bypass todays whois restriction. The RIR's whois databases have already been harvested and the data is being resold in spite of the policies and procedures. The current restrictions only serve to disrupt security services that need the data. From leo.vegoda at icann.org Tue Jul 31 19:57:23 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Jul 2012 10:57:23 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017F685.3090903@ripe.net> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> <5017F685.3090903@ripe.net> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34185DB7DF56EA@EXVPMBX100-1.exc.icann.org> Hi Denis, Denis Walker : [...] > As I follow these discussion my mind keeps focussing on the Abuse Finder > tool and the technical nightmare we have right now in trying to make > that work. One of the many problems with it is we cannot parse remarks > that (may) include abuse contacts. I think you have highlighted a fundamental issue with the design of RIPE database objects. They include data that is specifically for human consumption in objects that are structured so they can be parsed by software. I do not know what the best way to combine software parsable database objects and human readability is but recognise that this is not the Database WG list and that I am not a database expert. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5488 bytes Desc: not available URL: From leo.vegoda at icann.org Tue Jul 31 19:57:29 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Jul 2012 10:57:29 -0700 Subject: [anti-abuse-wg] the mandatory abuse field In-Reply-To: <5017F66C.6030703@powerweb.de> References: <50143B4A.6020006@powerweb.de> <6D0E4F77-A92B-4F4D-9545-FAFB4ED1B4B4@icann.org> <5017E5A0.3020907@powerweb.de> <443533B4-6A72-4FC9-B8FB-8B86FCC50CF6@icann.org> <5017F66C.6030703@powerweb.de> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34185DB7DF56EB@EXVPMBX100-1.exc.icann.org> Hi Frank, Frank Gadegast wrote: [...] > An option could be the following: > the possibility to set the abuse-mailbox field to something like > "non-responsive", a predefined value, thats valid according > to the format of the field. The cleanup will happen, the resource owner > makes a decision and the reporter could see, that the > resource owner does not want to have reports (via email) ... That seems pretty reasonable to me. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5488 bytes Desc: not available URL: From vesely at tana.it Tue Jul 31 19:57:53 2012 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 31 Jul 2012 10:57:53 -0700 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50156938.9070204@abusix.com> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> <50156938.9070204@abusix.com> Message-ID: <50181CA1.5000704@tana.it> On Sun 29/Jul/2012 09:47:52 -0700 Tobias Knecht wrote: > > That would mean that the a user has to click 50 times the spam > button, than 50 times "Yes I want to report this message!" and than > 50 times "I'm okay that this message will be sent to X!" And that, of course, does not leave you anything that a court would consider a proof that consent was granted. For contractual issues, I see telcos hire call-center staff in order to ask for user's consent at the phone, taping a formal question-and-answer sequence that can be kept as a proof. > We first need to find a simple for end users secure way to report that > does not destroy the usability and the trust and than come up with > solutions. Exactly! I'm not sure to what extent can OAuth or OpenID provide useful techniques. There seems to be an original sin in privacy practices, whereby anything Internet-related is assumed to be evil. There are no established protocols to grant consent through the net. >> We need to clear up this issue. Googling for that I find that ETIS, >> which is based in Europe, has an "Anti SPAM Co-operation Group" that >> "is also working on an anti-spam feedback loop project." (Quotes from >> http://etis.org/groups/anti-spam-task-force ). I'd guess you know >> them; they have a meeting on next Oktoberfest... Would they cover >> those legal concerns? > > Yes ETIS is exactly working on these legal issues, but imho have not > found a way around it. The project that is ongoing there has nothing > to do with user feedback. It's about spamtrap data provided by the > ETIS members. I'll be probably at the next ETIS meeting in Munich and > hopefully can help to take some next steps. I wrote them, but got no answer yet. I'd be happy to participate as well, if it helps. > We have an IETF specification, but this does not stand over the law. > We can specify as much as we want, if this is not a within the legal > framework we can't use it. And that is exactly what I mean, the rfc > you mention does not take in account that European legal system is > opt-in and not opt-out. Same on the different direction. Most ESPs in > the US don't care about opt-ins which is legally recommended in Europe. Hm... yeah, something. Americans have their own conundrums, such as patents. Those legal hypes seem to be rather related to temporary idiosyncrasies originating from a particular case, than applications of a general, uniform logic. For example, SMTP-forwarding is obviously incompatible with privacy, but nobody seems to be concerned about how many times users must confirm that they want to receive a commercial newsletter. Instead, lawyers argue that the mere presence of an email address in a publicly (or privately) accessible list may imply its owner's consent. By a similarly opportunistic argument, sending a message back to one of the entities who relayed it should imply no leak of information, since that data is already known to the relay. It has to be attached as a means of identifying it. If laws can be interpreted, it is not acceptable that interpretations only favor spammers :-/ > This is a basic difference between the US and Europe which can not be > ironed onto the same level. The outcome must be the same, but the way > to this will be different. Yes, I'd hope that users signalling messages to European ISPs can be better informed of what such signal means, w.r.t. American users. From tk at abusix.com Tue Jul 31 20:32:11 2012 From: tk at abusix.com (Tobias Knecht) Date: Tue, 31 Jul 2012 20:32:11 +0200 Subject: [anti-abuse-wg] Legal concerns, was Manual vs automated reports In-Reply-To: <50181CA1.5000704@tana.it> References: <500EDD68.7070303@abusix.com> <07F26FFD-CE63-443C-A200-88F79BB96D67@isc.org> <500FB3C7.6070407@tana.it> <500FD694.6060005@tana.it> <500FE096.90303@abusix.com>, <500FFA13.2030307@powerweb.de>, <50100F86.4000106@telus.net> <2F6E914E-D9E1-4B92-BFD5-C359BD003456@blacknight.com>, <50101FA1.7020403@telus.net> <5010302E.1030103@telus.net> <50110755.6000204@ripe.net> <5011213A.60002@ripe.net> <501166A7.8000600@tana.it> <50117263.8030003@abusix.com> <50117FD1.5090005@tana.it> <50156938.9070204@abusix.com> <50181CA1.5000704@tana.it> Message-ID: <501824AB.8040304@abusix.com> Hi, > On Sun 29/Jul/2012 09:47:52 -0700 Tobias Knecht wrote: >> That would mean that the a user has to click 50 times the spam >> button, than 50 times "Yes I want to report this message!" and than >> 50 times "I'm okay that this message will be sent to X!" > > And that, of course, does not leave you anything that a court would > consider a proof that consent was granted. For contractual issues, I > see telcos hire call-center staff in order to ask for user's consent > at the phone, taping a formal question-and-answer sequence that can be > kept as a proof. And now you have to answer only one question. Why should an ISP spend tenth of thousands of Euros to give data away for free to institutions that earn millions with it and not paying for it? I think we all know that there are ways to do it, but the questions is more about how practical it is. And in this case it would even be enough to call everybody and ask for consensus. With every new FBL subscriber ISPs would have to call every customer and ask if the new subscriber is okay for them. I'm always happy about new ideas, but on the other hand we are working on this issue with ISPs, ESPs, legal institutions and all other involved parties for more than 4 years now and we made good progress. But as it is typically in politics it's taking time. > If laws can be interpreted, it is not acceptable that interpretations > only favor spammers :-/ And that is not the case. As already mentioned US legal frameworks is fundamentally different from the European legal framework and in reality it is not as spammer friendly as the US system. Thanks, Tobias