Manual vs automated reports
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
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
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
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 <a href=...>bulk address</a>; this <a href=...>other one</a> 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.
On Wed, Jul 25, 2012 at 10:52 AM, Alessandro Vesely <vesely@tana.it> 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@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
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@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.
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
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Tobias Knecht Sent: Wednesday, July 25, 2012 3:04 PM To: Alessandro Vesely; anti-abuse-wg@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/
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" <thor.kottelin@turvasana.com> wrote:
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Tobias Knecht Sent: Wednesday, July 25, 2012 3:04 PM To: Alessandro Vesely; anti-abuse-wg@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/
"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" <thor.kottelin@turvasana.com> wrote:
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Tobias Knecht Sent: Wednesday, July 25, 2012 3:04 PM To: Alessandro Vesely; anti-abuse-wg@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@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
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
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" <wiegert@telus.net> 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
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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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
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@telus.net] Sent: 25 July 2012 17:32 To: "Michele Neylon :: Blacknight" Cc: anti-abuse-wg@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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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: <http://reversewhois.domaintools.com/?email=ea02193858a428fe3690330787a724ae> 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
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
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
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
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
On 26 Jul 2012, at 10:01, Denis Walker <denis@ripe.net> 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
"Michele Neylon :: Blacknight" wrote:
On 26 Jul 2012, at 10:01, Denis Walker <denis@ripe.net> 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@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
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
On 26 Jul 2012, at 11:49, Aftab Siddiqui <aftab.siddiqui@gmail.com> 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
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@bt.com role: BT Corporate Registry address: British Telecommunications address: 81 Newgate Street address: London GB e-mail: ip.manager@bt.com remarks: trouble: mailto: mailto:btcertcc@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@bt.com ++++ Cheers, Reza Farzan rezaf@mindspring.com ________________________________ From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg-bounces@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@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
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@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@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@bt.com role: BT Corporate Registry address: British Telecommunications address: 81 Newgate Street address: London GB e-mail: ip.manager@bt.com remarks: trouble: mailto: mailto:btcertcc@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@bt.com
++++
Cheers,
Reza Farzan rezaf@mindspring.com
________________________________
From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg-bounces@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@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
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
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
On 26/07/2012 12:17, "Michele Neylon :: Blacknight" wrote:
On 26 Jul 2012, at 10:01, Denis Walker <denis@ripe.net> 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
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
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
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.
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" <vesely@tana.it> 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.
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.
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.
On 27 Jul 2012, at 05:45, lists@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
On 27 Jul 2012, at 05:45, lists@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
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
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
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.
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
On Tue 31/Jul/2012 11:32:11 -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.
Don't get me wrong, I was not suggesting that call-centers are the way to the future. I exemplified them as abnormal ways of conducts, which are the (possibly unintended) consequences of jurisprudential rules about privacy. Among their results, enterprises have powerful databases of private user data, while users have no aid whatsoever to remember when, if ever, did they grant their consent to a specific enterprise.
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.
Yet, as far as I'd tell by casual news reading, spammers collect more sentences in the US than in the EU.
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
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
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
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@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@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@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@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" <wiegert@telus.net> 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. )
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" <peter@hk.ipsec.se> 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@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@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@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@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" <wiegert@telus.net> 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. )
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.
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
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. )
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
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
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
participants (17)
-
"Michele Neylon :: Blacknight" -
Aftab Siddiqui -
Alessandro Vesely -
Arnold -
Denis Walker -
Esa Laitinen -
Frank Gadegast -
Gunther Nitzsche -
Ian Eiloart -
Leo Vegoda -
lists＠help.org -
Luis Muñoz -
peter h -
Reza Farzan -
Suresh Ramasubramanian -
Thor Kottelin -
Tobias Knecht