the mandatory abuse field
Hi all, I really have the feeling, that some in the community fear a mandatory abuse field, and try find any strange argument against it, but I really cannot see why. If somebody does not want to receive abuse reports or does not want to do something against abuse originating from his own resources or likes to receive them not via email or has whatever else reason, well, name it this-email-address-is-not-being-read@yourdomain.com or no-reply@example.com or send it to devnull ... Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore. On the other end, a mandatory abuse field will clean up everything in RIPEs database, remove the unparseble remarks, will help the abuse teams to receive reports only to ONE address, because sender can be educated, abuse tools can be simplified and integrated in webpages easily aso ... A mandatory abuse field has that much advantages for everybody who likes to work against abuse, that I cannot understand, why people, that do not want the same for there own reasons are against it. Let us optimize our procedures and if you do not want to participate, well set the email address to whatever or ignore every incoming mail ... Well, there is one reasons I can think of: Those people are not concerned, that they have to do something against abuse coming from there OWN resources, it must be the people that are causing the abuse problem in the first place, its there business, and so they are worried, that others find easier and better methods in preventing abuse. So, my personal summary is: --- Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion. But thats only my impression ... --- Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
They wild opinions are why this list is not a "consensus" of any sort. If someone has a certain opinion they are labeled as criminals, spammers, etc. without any legitimate reason. This type of stuff comes from a religious belief and not anything that can be explained by logic. I don't see why there is all this discussion of mandatory abuse fields when the RIR whois databases are filled with inaccuracies and false whois data. When I point these out to ARIN I never hear back and it never gets fixed and I assume RIPE is the same way. Until you take care of that problem it is useless to require mandatory fields of any sort.
So, my personal summary is: --- Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion.
But thats only my impression ... ---
Its a weird situation, that anybody from whatever country with whatever background or regulations can influence everything. Lets take ICANN as an example: do you really think that I will have >the chance to influence a vote at the ICANN >members board without being a member ? Well, they might listen, what others have to say, but finally it will be a vote. Lets have a vote asking all >RIPE members abuse this proposal instead of listening to every criminal from the world
The WHOIS service is a universal service used by people around the world and the RIR's have agreements in place to provide these services. People in other regions receive spam, abuse attempts, etc from the RIPE region and they need to use the whois just like the RIPE region needs to use other RIR whois. WHOIS policy should be set by a region, it should be universal across all RIR's. The underlysing system is paid for by the US taxpayers via the IANA contract. If your ideas were to be used RIPE members should have no say, only the US taxpayer should dictate how it is run. As for ICANN, they are paid for by a domain tax. You are correct that the people that pay the tax generally have no say whatsoever which is why ICANN is not actually an Internet "governance."
lists@help.org wrote:
The WHOIS service is a universal service used by people around the world
First, the whois service is a service from the RIPE NCC, stored in a database maintained by the RIPE NCC, programmed from people paid by the members of the RIPE NCC. Second, it looks like to me, that the format in wich the data is stored in that database, is finalized by people that do not have to be from the RIPE region and do not have to be a member of the RIPE NCC, the so-called community. And thats weird ...
and the RIR's have agreements in place to provide these services.
Based on RFCs that are finalized by people not being part of that RIR. Strange ... :People
in other regions receive spam, abuse attempts, etc from the RIPE region and they need to use the whois just like the RIPE region needs to use other RIR whois. WHOIS policy should be set by a region, it should be universal across all RIR's.
Sure, one standarized whois would be wonderfull. But, and thats my point, the format of the stored data, should be decided by the members of those RIRs.
The underlysing system is paid for by the US taxpayers via the IANA contract.
Really ? Were do you have that from ? IANA is getting its money from ICANN. And IANA is not doing any service nor maintaining the database.
If your ideas were to be used RIPE members should have no say, only the US taxpayer should dictate how it is run.
As for ICANN, they are paid for by a domain tax. You are correct that the people that pay the tax generally have no say whatsoever which is why ICANN is not actually an Internet "governance."
Ok, so: IANA is getting paid by all people all over the world, wich are buying domain names. There is no money from US taxpayers being involved. Where do you have that from ? One goal of IANA is to coordinate RFCs, so a whois standarization should be their thing, good, continue to complain to them. Until then, I like the RIPE NCC to simply ask there members, because neither the "comunity" nor non-members should have anything to say about the service the NCC offers. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
lists@help.org wrote:
They wild opinions are why this list is not a "consensus" of any sort. If someone has a certain opinion they are labeled as criminals,
Sure, they are in my country.
spammers, etc. without any legitimate reason. This type of stuff comes from a religious belief and not anything that can be explained by logic.
Its not religion, its law in a lot of countries.
I don't see why there is all this discussion of mandatory abuse fields when the RIR whois databases are filled with inaccuracies and false
How can you believe, that you can cleanup the database WITHOUT a mandatory field ? The mandory field means MORE accuracy, not less.
whois data. When I point these out to ARIN I never hear back and it never gets fixed and I assume RIPE is the same way. Until you take care of that problem it is useless to require mandatory fields of any sort.
Where is your logic here ? How can you have better data, without forcing the resource owner to enter his information just in one field instead of spreading it everywhere and have even no email address at all ? Please tell us, how you think, how the database can be cleaned up inf whatever way. Please supply a method instead of critizising the mandatory field ... Kind regards, Frank
So, my personal summary is: --- Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion.
But thats only my impression ... ---
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Please supply a method instead of critizising the mandatory field ...
Nothing wrong with a mandatory field but you need to clean up the entire database first. Once you do the major cleanup then you can focus on individual fields and it all should be coordinated with all the RIR's. For instance I recently saw a record in ARIN that says: Address: Private City: Private StateProv: NJ PostalCode: 99999 The response from ARIN was: "If you believe the information below is false, can you provide more detail regarding the information you believe is inaccurate and ARIN will research and take the appropriate action." I pointed out the whole record was false and I never heard back and it was never fixed. I don't see the point of making anything mandatory if this is how things are done. Once these things get fixed I would agree with the mandatory field.
lists@help.org wrote:
Please supply a method instead of critizising the mandatory field ...
Nothing wrong with a mandatory
Ah, there we are, more substance.
field but you need to clean up the entire database first.
Why ? The abuse-c will automatically lead to a cleanup. The members will have to alter their objects, when the abuse-c is mandatory, and surely a lot of them will clean them up. The members could receive some guidelines from the NCC, when its there, like: "remove abuse information from the remarks, remove iRT objects only used for an abuse address aso ... And how: how will you clean up the database ? btw: this is a job for the db-wg ...
individual fields and it all should be coordinated with all the RIR's.
Its a good idea and it should be IANAs work, but until then ?
For instance I recently saw a record in ARIN that says:
Address: Private City: Private StateProv: NJ PostalCode: 99999
The response from ARIN was: "If you believe the information below is false, can you provide more detail regarding the information you believe is inaccurate and ARIN will research and take the appropriate action." I pointed out the whole record was false and I never heard back and it was never fixed. I don't see the point of making anything mandatory if this is how things are done. Once these things get fixed I would agree with the mandatory field.
Why in that order ? Please make this more clear. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
I think you need to first develop 2 tables (working with other groups/RIR's). Across the top is the RIR's. The first tables should list the data fields and the second table list the queries and what data elements they return. Then you can see what the RIR's all have in common and explain the differences/reasons in the elements of the table. Then look at what is common among the RIR's and come up with a standard. Then you can focus on the individual elements and decide what to do with the eventual goal being a common standard among all RIR's. To get over the opt-in/opt-out law differences you could consider allowing "private" instead the real data, allow a link to a form web page rather than a contact person, or demand an opt-in agreement when the data is collected, etc.
lists@help.org wrote:
I think you need to first develop 2 tables (working with other groups/RIR's). Across the top is the RIR's. The first tables should list the data fields and the second table list the queries and what data elements they return. Then you can see what the RIR's all have in common and explain the differences/reasons in the elements of the table. Then look at what is common among the RIR's and come up with a standard. Then you can focus on the individual elements and decide what to do with the eventual goal being a common standard among all RIR's.
Sounds resonable, but is really somthing for the db-wg or another place where this worldwide RFC could be developed. Feel free to send a proposal, its defny welcome.
To get over the opt-in/opt-out law differences you could consider allowing "private" instead the real data, allow a link to a form web page rather than a contact person, or demand an opt-in agreement when the data is collected, etc.
I cant really see, why a development of a new whois standard needs to be first, until then I would focus on the mandatory field to help abuse reporting and the cleanup of RIPEs database. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Frank, On Saturday, 2012-07-28 21:19:38 +0200, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
I really have the feeling, that some in the community fear a mandatory abuse field, and try find any strange argument against it, but I really cannot see why.
I think the resistance comes because a number of related ideas have been tried in the past, and they have failed. So we'd like to see whatever abuse reporting changes made don't just add to the current confusion without actually improving anything.
If somebody does not want to receive abuse reports or does not want to do something against abuse originating from his own resources or likes to receive them not via email or has whatever else reason, well, name it this-email-address-is-not-being-read@yourdomain.com or no-reply@example.com or send it to devnull ...
Yes, that is correct. So the question is "why make it mandatory then?" Your answer seems to be:
On the other end, a mandatory abuse field will clean up everything in RIPEs database, remove the unparseble remarks, will help the abuse teams to receive reports only to ONE address, because sender can be educated, abuse tools can be simplified and integrated in webpages easily aso ... A mandatory abuse field has that much advantages for everybody who likes to work against abuse, that I cannot understand, why people, that do not want the same for there own reasons are against it. Let us optimize our procedures and if you do not want to participate, well set the email address to whatever or ignore every incoming mail ...
This all seems unrelated to whether a field is mandatory or not. Rather this seems more like an exercise in making the abuse reporting information in the database more rational - which seems like quite a reasonable goal.
Those people are not concerned, that they have to do something against abuse coming from there OWN resources, it must be the people that are causing the abuse problem in the first place, its there business, and so they are worried, that others find easier and better methods in preventing abuse.
So, my personal summary is: --- Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion.
But thats only my impression ... ---
I promise you I am neither a professional spammer, abuser, nor do I maintain a bot net or sell open proxies or other services used for abusing others. As I said in the beginning, I'd just like to make sure that whatever is done actually improves things. Mind you, I'm not totally opposed to a mandatory abuse field, I just don't see the point without a policy governing how it is used. I would be quite supportive of a policy which said something like: If someone reports that an abuse mailbox is unresponsive to the RIPE NCC, they will investigate. If the RIPE NCC also finds the abuse mailbox is unresponsive, then they will alert the resource holder. If the resource holder has not fixed the problem within 30 days, then the resources will be revoked. If the holder tries to hide an unresponsive abuse mailbox, for example by adding a filter that allows RIPE NCC mails through but ignores all others, then resources will be revoked immediately. I just think that such a policy has no chance of being approved. :) Cheers, -- Shane
Shane Kerr wrote:
Frank,
Hi Shane,
Yes, that is correct. So the question is "why make it mandatory then?"
The example from hovland.cz in one of the last mails was pretty good. His customers do not have a working abuse department and maybe even no email address. So: a mandatory field is a good point to start discussing this with your customers ;o) Not only to stop abuse from those networks, but wich customer likes to have his resources abused and NOT know about it ? You can even sell it as a service ... A break-in is not only a problem to others, that are abused after the break-in, is also a problem for the service itself ... and is not everybody concerned, that his data could be stolen ? Im always happy to receive whatever report. I rather receive 30 reports leading to nothing (because they are simply wrong, like the reports from spamcop, that usally are reported from users that simply forgot that they susbribed to a customers newsletter once or are to lacy to unsubscibe), when just one shows me a potential security problem with my customers services. It a service for our customers, and they all love it, when we can keep them informed about new software versions, they should update to or similar. So: why should anybody not be interested if his services are hacked ? Another (somehow funny) example I had last week with a German ISP, we reported too. He replied, that hes not doing anything about break-ins into the services he runs for his customers, simply because its too expensive and he could not compete with others in the market, if he would. One of his root servers got hacked and the hacker installed an etherner-sniffer and read all the password from his other customers. The hacker then broke into another customers server and stole a lot of data. Now, the ISP is brought to court by this other customer, because hes a "Mitstoerer" in German law, he knew about the risk and did not do anything. And the police already ask us, if we informed that ISP about the spam coming from one if his machines. We surely said: yes. They then ask, if we got a reply and said yes again. I guess, he will loose this case and will be broke afterwards loosing his business completely. And all his customers will hopefully ask their new ISPs, if they have a working abuse department (that also good education).
If someone reports that an abuse mailbox is unresponsive to the RIPE NCC, they will investigate. If the RIPE NCC also finds the abuse mailbox is unresponsive, then they will alert the resource holder. If the resource holder has not fixed the problem within 30 days, then the resources will be revoked. If the holder tries to hide an unresponsive abuse mailbox, for example by adding a filter that allows RIPE NCC mails through but ignores all others, then resources will be revoked immediately.
I just think that such a policy has no chance of being approved. :)
Your probably right, but I think, its a shame that something like this is not possible. Kidn regards, Frank -- -- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Dumb question, but does the abuse field have to be an email address? Can it be a web address instead? Regards Michele Mr Michele Neylon Blacknight Solutions ♞ Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ http://blacknight.cat http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Michele, On Tuesday, 2012-07-31 13:01:44 +0000, "\"Michele Neylon :: Blacknight\"" <michele@blacknight.ie> wrote:
Dumb question, but does the abuse field have to be an email address?
Can it be a web address instead?
I guess the idea is that some people prefer to limit the spam they get to their abuse mailboxes by requiring that people use a web form? In that case, a web address seems like a good option to me. Cheers, -- Shane
Hi,
Dumb question, but does the abuse field have to be an email address?
Not dumb, but yes it must be an email address.
Can it be a web address instead?
No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses. If there is a major need for web addresses to be published it would be another attribute that would be optional. The mandatory character of the "abuse-mailbox:" would not be changed. Thanks, Tobias
Hi Tobias, On Jul 31, 2012, at 6:33 am, Tobias Knecht <tk@abusix.com> wrote: […]
No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses.
Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement. Regards, Leo Vegoda
Leo Vegoda wrote:
Hi Tobias,
On Jul 31, 2012, at 6:33 am, Tobias Knecht <tk@abusix.com> wrote:
[…]
No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses.
Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement.
Another point for the abuse-c. It can be enhanced. An optional abuse-url field is really a good idea, if there would be an standarized ARAPI (Abuse Report API ?)
Regards,
Leo Vegoda
Kind regards, Frank -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi,
No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses.
Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement.
Right. If we are talking about an RESTful API based system that is absolutely fine. At the moment we do not have such an system in place, but as soon as we have I will be the last person to ignore it. At the moment email with it's standards like (m)ARF and x-arf and IODEF and all these are common practice. And we need a solution for this common practice.
An optional abuse-url field is really a good idea, if there would be an standarized ARAPI (Abuse Report API ?)
As soon as we have something in place, I will write the proposal. Promised ;-) Thanks, Tobias
On 31/07/2012 6:54 AM, Leo Vegoda wrote:
Hi Tobias,
On Jul 31, 2012, at 6:33 am, Tobias Knecht <tk@abusix.com> wrote:
[…]
No. We had that conversations already and decided not to accept web addresses only. The reason is, that automatic reporting can not be done with web addresses. Assuming you mean something accessible over HTTP or HTTPS, it does not have to be accessed by a person using a browser. If there was a widely adopted API, I can see the value in a URL for some kind of RESTful service for automatic reports that do not require human involvement. if it can be automated, it surely will be abused just as e-mail addresses. Why open another 'door' for SPAMMERs and then wonder why we will have to expend more effort to 'filter' what cames through.
Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml
This conversation seems to be going round and round in circles and I'm getting quite confused. My understanding was that the object / field would be used / assigned in any allocations of IP space. Can someone please explain to me how it is possible that an organisation could have IPs but not have an email address or website? And if that is the case, then shouldn't the next level up be taking responsibility for abuse of the resources? Or am I missing something? I like the suggestion that the field be a URL that can be either a mailto or a http. I don't really care if some reporters have issues with this or not - I don't work for them and they're not paying me or anyone else - in fact many of them are getting paid .. so .. I also have issues with a lot of the automated reporting tools that some people insist on using, but that's off topic :) I strongly oppose any "non responsive" type label being used. That will cause a lot of issues for LIRs and will do little to advance the anti-abuse ethic 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
Hi,
My understanding was that the object / field would be used / assigned in any allocations of IP space. Can someone please explain to me how it is possible that an organisation could have IPs but not have an email address or website? And if that is the case, then shouldn't the next level up be taking responsibility for abuse of the resources? Or am I missing something?
Fully agree. Thats why for all direct allocations the abuse-c will be mandatory. For everybody else it will be optional. The hierarchy and the mandatory abuse-c at the top of the chain will give us at least one abuse contact per ip address, which is the absolute minimum. And I fully agree to the part with the responsibility. There must be one party that can and takes responsibility for abuseive behavior. If they feel they are the wrong persons they have to explain their subdelegation that they need to publish an abuse-c and handle the traffic themselves.
I like the suggestion that the field be a URL that can be either a mailto or a http. I don't really care if some reporters have issues with this or not - I don't work for them and they're not paying me or anyone else - in fact many of them are getting paid .. so .. I also have issues with a lot of the automated reporting tools that some people insist on using, but that's off topic :)
I really like this idea, but at the moment I would rather stay with abuse-mailbox as an email and add an abuse-url: or similar later. The reason is, that we can not foresee what will happen in the near future and nobody knows if API reporting is something that will show up. At the moment all institutions (maawg, IETF, APWG, ...) are working on reporting and use email based transport. So we should stay with that and not offer for publication of things that are not even here and not nearly standardized or even used in a real world scenario.
I strongly oppose any "non responsive" type label being used. That will cause a lot of issues for LIRs and will do little to advance the anti-abuse ethic
Fully agree. Thanks, Tobias
"Michele Neylon :: Blacknight" wrote: Hi,
This conversation seems to be going round and round in circles and I'm getting quite confused.
My understanding was that the object / field would be used / assigned in any allocations of IP space.
Sure, the direct allocation will have it first. Then its up to the member to communicate the new field to the subdelegation customers to get rid of all the reports :o) Its should be the goal, than any resource holder have its own abuse mailbox address.
Can someone please explain to me how it is possible that an organisation could have IPs but not have an email address or website?
There are e.g. ISPs that provide VPN only, they tunnel everything, and there is no abuse happening at all. And there are other examples. Sure they have email themselve, but maybe they dont like to communicate it.
And if that is the case, then shouldn't the next level up be taking responsibility for abuse of the resources? Or am I missing something?
That would be ideal and our final goal, but there are lots out there, that simply do not want to take responsibility for several reasons. And they dont care about blacklists, they fear the costs, work or whatever.
I like the suggestion that the field be a URL that can be either a mailto or a http.
I really dont like to mix email address with URLs, even if they have a mailto:, email addresses are really easy to recognize, by software or by humans, its clear what to do with an email address, for everybody. Lots of end users dont even know what an URL is and might get confused. An URL should only be optional as a seperate field ... That could be another proposal ...
I don't really care if some reporters have issues with this or not - I don't work for them and they're not paying me or anyone else - in fact many of them are getting paid .. so .. I also have issues with a lot of the automated reporting tools that some people insist on using, but that's off topic :)
I strongly oppose any "non responsive" type label being used. That will cause a lot of issues for LIRs and will do little to advance the anti-abuse ethic
Good, so that idea is done. It was only a possibility to discuss ... Kind regards, Frank
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 ======================================================================
Dear Michele This is a very reasonable question. One of the technical advantages of the "abuse-c:" proposal is that it references an object in which is stored contact information. Currently the discussion is focussing on an "abuse-mailbox:" attribute in that object as the primary contact method. As Tobias said, technically, we could easily add an additional "abuse-url:" attribute if required. Or anything else like "abuse-im:" or "abuse-mobile:". If we have the framework referencing a contact object then whatever the community wants inside that object is possible. You just decide what methods you want and what should be mandatory, required, optional, this or that, etc and the RIPE NCC can build it. From the point of view of the Abuse Finder tool the important step is to have one method of finding the abuse contact from an IP address. Once we can easily find it, you can have as much variation as you like in terms of contact methods. The Abuse Finder tool can just report to the user whatever options you have supplied. Regards Denis Walker Business Analyst RIPE NCC Database Group On 31/07/2012 15:01, "Michele Neylon :: Blacknight" wrote:
Dumb question, but does the abuse field have to be an email address?
Can it be a web address instead?
Regards
Michele
Mr Michele Neylon Blacknight Solutions ♞ Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ http://blacknight.cat http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
On 31 Jul 2012, at 14:50, Denis Walker <denis@ripe.net> wrote:
Dear Michele
This is a very reasonable question. One of the technical advantages of the "abuse-c:" proposal is that it references an object in which is stored contact information. Currently the discussion is focussing on an "abuse-mailbox:" attribute in that object as the primary contact method.
As Tobias said, technically, we could easily add an additional "abuse-url:" attribute if required. Or anything else like "abuse-im:" or "abuse-mobile:". If we have the framework referencing a contact object then whatever the community wants inside that object is possible. You just decide what methods you want and what should be mandatory, required, optional, this or that, etc and the RIPE NCC can build it.
Why not leave it at abuse-url: and let people use mailto: urls? So, they can put anything in there that has a url schema. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
Dumb question, but does the abuse field have to be an email address?
Can it be a web address instead? e-mail addresses can be handled a bit more 'automatically' for SPAM reporting using available utilities. A web URL, unless it is in a standard format, it will take an lot more manual input and much more time to copy and paste
On 31/07/2012 6:01 AM, "Michele Neylon :: Blacknight" wrote: the relevant information. Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml
Hi,
I think the resistance comes because a number of related ideas have been tried in the past, and they have failed. So we'd like to see whatever abuse reporting changes made don't just add to the current confusion without actually improving anything.
And I fully understand this point. And that is one of the reasons why we wanted RIPE NCC to consult with this, to get a better view on how we can clean up the mess that is existing with a better solution. At the moment I think the proposal hits a lot of points that would make things easier and even if we figure out that we missed something or we need something more or less, we are moving in the same framework as we do with admin-c and tech-c and this will make it much more flexible for future change requests than what we have at the moment.
As I said in the beginning, I'd just like to make sure that whatever is done actually improves things.
So what is your feeling with the latest version of the proposal? Does it improve things?
Mind you, I'm not totally opposed to a mandatory abuse field, I just don't see the point without a policy governing how it is used. I would be quite supportive of a policy which said something like:
I fully agree. But we can not go all the steps at once. Believe me this is not the last proposal I'm coming up with ;-) We have the data accuracy part and some other things that we need to take care of.
If someone reports that an abuse mailbox is unresponsive to the RIPE NCC, they will investigate. If the RIPE NCC also finds the abuse mailbox is unresponsive, then they will alert the resource holder. If the resource holder has not fixed the problem within 30 days, then the resources will be revoked. If the holder tries to hide an unresponsive abuse mailbox, for example by adding a filter that allows RIPE NCC mails through but ignores all others, then resources will be revoked immediately.
I would probably not agree to that in that restrictive way, but yes there must be a way to figure these things out, but as already said, one step after the other and not everything at once.
I just think that such a policy has no chance of being approved. :)
I definitively agree on that, but that will be another box of fun to find a common accepted way. :-) Thanks, Tobias
Hi Frank, On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote: […]
If somebody does not want to receive abuse reports or does not want to do something against abuse originating from his own resources or likes to receive them not via email or has whatever else reason, well, name it this-email-address-is-not-being-read@yourdomain.com or no-reply@example.com or send it to devnull …
I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore.
I do not want to encourage the development of more business logic like this. Regards, Leo Vegoda
Leo Vegoda wrote:
Hi Frank,
On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
or no-reply@example.com or send it to devnull …
I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
Simply because its better to have ONE place for reporters. Forcing these addresses to be working and correct is not part of this proposal and could be discussed later (and fixed with another proposal). Currently there are lots of places to store the abuse-contact and a lot of them are wrong, because of a lie, lacyness, technical problems or whatsoever. In future you will have only one place to look for it, probably also with a lot of wrong addresses. Anyway, it would be better than it is now.
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore.
I do not want to encourage the development of more business logic like this.
You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting ... Kind regards, Frank
Regards,
Leo Vegoda
-- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi Frank, On Jul 31, 2012, at 7:03 am, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Leo Vegoda wrote:
Hi Frank,
On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
or no-reply@example.com or send it to devnull …
I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
Simply because its better to have ONE place for reporters.
I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
Forcing these addresses to be working and correct is not part of this proposal and could be discussed later (and fixed with another proposal).
Currently there are lots of places to store the abuse-contact and a lot of them are wrong, because of a lie, lacyness, technical problems or whatsoever.
I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
In future you will have only one place to look for it, probably also with a lot of wrong addresses.
Anyway, it would be better than it is now.
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore.
I do not want to encourage the development of more business logic like this.
You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting …
By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger. Regards, Leo Vegoda
Leo Vegoda wrote:
Hi Frank,
On Jul 31, 2012, at 7:03 am, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Leo Vegoda wrote:
Hi Frank,
On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
or no-reply@example.com or send it to devnull …
I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
Simply because its better to have ONE place for reporters.
I don't think I have been clear.
You were clear.
Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
Hm, this is estimation. There are people that are not publishing contacts, because - they dont know that they can or should, simply because nobody told them or that their RIPE member decided not to publish some - some have typing mistakes - some have deliberatly wrong format, hoping that only humans report (like @ti.ru.only or some adding a .remove.this.suffix at the end) You cannot say whats really happening. It could be that the amount of right and working contacts is increasing. Or you could be right. You cannot compare both situations (the current and the coming) right now, I would say, its getting easier for the reporter, because then you can send a report and analyse any bounces. You will see, if the resource owner wants a report, after your report bounces. Currently there are a lot of networks, that probably want a report, but you will send it to the wrong address, simply because you cannot make a decision, wich contact or remarks or IRT object you should use. A lot of reports are being send to a contact, that was not intended by the resource owner and will be ignored or unread because of the current situation.
Currently there are lots of places to store the abuse-contact and a lot of them are wrong, because of a lie, lacyness, technical problems or whatsoever.
I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger.
Like sayd before, the abuse-c will lead to an semi-automatic clean-up, because the resource owners have to re-think his situation. Surely they will remove a lot of old remarks and IRT objects used only for this purpose, simply because its right.
In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
Neat is nice ;o)
You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting …
By forcing people to tell a lie about where to send reports you just exacerbate the problem.
See above. The reporter can then 100% sure, that he picked the right address, and if it bounces, well, looks like to resource holder does not want reports ... makes things much easier for the reporter.
I do not think "but you have to do this anyway" is a good reason for making the problem bigger.
If there is something non-mandatory, you cannot decide if the resource owner deliberatly decided not to publish one, or if he simply forgot to add one (because he is not forced too). There is lots of field, that could be added, but nobody does it, because its less work (even if its useful for himself). I guess, that there are lots of old objects, that were not updated, when the abuse-mailbox field was introduced. Having it non-mandatory will lead to more confusion, because the resource owners thinks, that everything is in its place and keeps the old methods. So, having it non-mandatory will make the problem bigger like you sayd. Having it mandatory will result in a semi-automated cleanup and a real decision by the resource owner, like the NCC outlined in the proposal. An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ... Kind regards, Frank
Regards,
Leo Vegoda
-- Mit freundlichen Gruessen, -- MOTD: "have you enabled SSL on a website or mailbox today ?" -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================
Hi Frank, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote: [...]
An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ...
That seems pretty reasonable to me. Regards, Leo Vegoda
Hi,
An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ...
That seems pretty reasonable to me.
That could be an option. There is only one point I do not understand. We are talking only about the direct allocations, which in my opinion should all have an abuse address and handle their abuse. That is at least my opinion. As I understood Franks idea the resource holder would have to call himself "non-responsive" and publish this information, which will definitevely create problems in the future. Just thinking of blacklists using this information and so on, so at the end the unresponsive will add addresses that are deleting inbound messages. Which is of course not good either, but we could even proof that an unresponsive ISPs has accepted mail on his given address. This can be interesting in legal situations like Frank explained as well. So at the moment I think we have a solution that is easy and understandable for everybody and tries to solve a lot of possible scenarios. I would rather not change things into a direction that makes specific scenarios impossible just to make it "easier" for reporters to manage things from a bounce handling or deliverability perspective. And on the other hand, we (abusix) are sending more than 500k reports per day to different ISPs all over the world using whois information and yes around 30% are bouncing. So what? We are not even looking at the bounce messages. Next time we try again to deliver messages. This is at the end not a real problem for reporting parties. And I would not put to much attention on it. On the long end I would rather like to see something like ARIN is doing with wrong contact information. Tagging whois entries if the data that is provided is not accurate and resource holders are not cooperative. Thanks, Tobias
Tobias Knecht wrote:
Hi,
Hi,
An option could be the following: the possibility to set the abuse-mailbox field to something like "non-responsive", a predefined value, thats valid according to the format of the field. The cleanup will happen, the resource owner makes a decision and the reporter could see, that the resource owner does not want to have reports (via email) ...
That seems pretty reasonable to me.
That could be an option. There is only one point I do not understand. We are talking only about the direct allocations, which in my opinion should all have an abuse address and handle their abuse. That is at least my opinion.
Yes, I agree. This should only be only an option for subdelegations.
As I understood Franks idea the resource holder would have to call himself "non-responsive" and publish this information, which will definitevely create problems in the future. Just thinking of blacklists using this information and so on, so at the end the unresponsive will add addresses that are deleting inbound messages. Which is of course not
Also true, we could not hide the abuse mailbox field, if its set to "non-responsive", because lots of software depends on the presents of the field and will depend on a well-formed email address. Humans will also be confused, when its communicated, that its mandatory and it will be missing in some cases. Setting it to an a kind of generic not-used email address might not be an option too. Maybe there will be or is already a blacklist, thats collecting non-responsive resource holders, they could provide an email address ;o)
good either, but we could even proof that an unresponsive ISPs has accepted mail on his given address. This can be interesting in legal situations like Frank explained as well.
So at the moment I think we have a solution that is easy and understandable for everybody and tries to solve a lot of possible scenarios. I would rather not change things into a direction that makes specific scenarios impossible just to make it "easier" for reporters to manage things from a bounce handling or deliverability perspective.
I think so too, its was just an idea that is not really leading to anything until somebody else come up with an idea how this non-responsive address could be formed ...
And on the other hand, we (abusix) are sending more than 500k reports per day to different ISPs all over the world using whois information and yes around 30% are bouncing. So what? We are not even looking at the bounce messages. Next time we try again to deliver messages. This is at the end not a real problem for reporting parties. And I would not put to much attention on it.
On the long end I would rather like to see something like ARIN is doing with wrong contact information. Tagging whois entries if the data that is provided is not accurate and resource holders are not cooperative.
Well sayd. Kind regards, Frank
Thanks,
Tobias
-- 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 02/08/2012 4:15 AM, Tobias Knecht wrote: ------------8X--------------
On the long end I would rather like to see something like ARIN is doing with wrong contact information. Tagging whois entries if the data that is provided is not accurate and resource holders are not cooperative.
That raises the question for me: How does ARIN deal with these folks who are 'not cooperative'? Are they taking any action? Arnold -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml
That raises the question for me: How does ARIN deal with these folks who are 'not cooperative'?
You have asked a question that most entities that operate whois database will not answer. They make big presentations about warning banners and discuss "mandatory" fields but when the data gets compromised nothing gets done. This is not limited to ARIN, RIPE, etc. it is true of just about all whois operators. For instance, everybody knows DomainTools.com is harvesting and reselling the data in these whois databases yet what formal action have any of these whois operators taken in response? The result of all these rules, restrictions, blocking, and policies is that it inconveniences the people who use the services normally while the people violating the policies continue unabated. This situation is rarely considered when all the policies and procedures are developed so much of that work ends up being useless and people get all bent out of shape because there is a policy in place that is not enforced.
lists@help.org wrote:
That raises the question for me: How does ARIN deal with these folks who are 'not cooperative'?
You have asked a question that most entities that operate whois database will not answer. They make big presentations about warning banners and discuss "mandatory" fields but when the data gets compromised nothing gets done. This is not limited to ARIN, RIPE, etc. it is true of just about all whois operators. For instance, everybody knows DomainTools.com is harvesting and reselling the data in these whois databases yet what formal action have any of these whois operators taken in response?
The result of all these rules, restrictions, blocking, and policies is that it inconveniences the people who use the services normally while the people violating the policies continue unabated. This situation is rarely considered when all the policies and procedures are developed so much of that work ends up being useless and people get all bent out of shape because there is a policy in place that is not enforced.
Only half true. 2011-06 is a big step into the right direction. First: Its a role-account with a mandatory field, every maintainer has to know, NOT to enter his personal address or one of his customer in there, but use his ticket system or the address of his educated abuse team a generic mailbox or whatever else non-personal he has. This will dramatically reduce the amount of personal addresses in the database, so ? Let the harvesters do there job and let the spammers send their spam to educated and expirienced people or teams, that probably have the best filters to presort there mail, have the best antispam techniques anyway and that are educated enought not to click any dangerous link. Second: its a mandatory field and only one place where to store the abuse contact RIPE NCC could then check the format and the availibility of all abuse contacts, this is the first time they CAN do it like described lately by the the people that wrote the abuse finder tool, simply because they will know, where to look for it. Third: it will be hard work to define what "responsiveness" realy is. You can check the syntax, the domain, if it exists, you could check, if its mailserver is responsive and you could even check, if the address exists or (I think) at last step, if an email does not bounce. But then ? how do you measure responsiveness ? By inserting a link, that has to be clicked ? How many times ? In what period ? Is a resource holder allowed to go on holidays or forget about his abuse mailbox for 3 weeks ? 4 weeks ? That are questions that differ from member to member. On the other end, I know systems where you have to "renew" your offers in the database every months or they will be inactive. And if you like to use there system you simply have to accept this. Even if I would love the punishment of abuse-ignorant ISPs, even by the RIPE NCC itself, I have no idea how that all could look like ... thats a big step and will need a lot of discussion. But: now there will be the technical background to do it. Kind regards, Frank -- MOTD: "Im happy about every ISP, that does not backscatter" -- 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 ====================================================================== -- Mit freundlichen Gruessen, -- 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 ======================================================================
CIRA has received complaints about the harvesting and resale of historic whois data. While they maintain a TOS against this practice CIRA knows the policy is not being followed. CIRA would generally ignore complaints about this situation and would simply refuse to respond. Now the matter was brought up to the Privacy Commissioner's Office (along with the issue of the bogus lawsuit filed by DomainTools.com) so CIRA has finally responded and said they contacted DomainTools.com. However, CIRA is refusing to release the correspondent to the public and their lawyer is telling members of the public that if they want to see the letter they will have to take legal action against CIRA! So much for the openness and transparency claimed in their bylaws. At least ICANN publishes their correspondence. A web page has been set up to follow the issue at: http://whoissecurity.com/ca-whois-harvesting/
Dear Leo As I follow these discussion my mind keeps focussing on the Abuse Finder tool and the technical nightmare we have right now in trying to make that work. One of the many problems with it is we cannot parse remarks that (may) include abuse contacts. Even with the "abuse-c:" proposal we still cannot 'prevent' (by any technical means) users from putting an abuse contact in a remark anywhere in their data set that seems a logical place to them. Using a double negative approach (if you don't want to handle abuse, don't add an abuse contact) presents the same technical problem for the Abuse Finder tool. Not all users of the RIPE Database read the documentation and follow discussions on the mailing lists. If there is no requirement to put an "abuse-c:" in a specific place, some of these users will still add it in a remark somewhere. Technically we can't prevent them and also will not know about it if they do. So if the community chooses to make it optional (and the RIPE NCC will implement it in whatever way the community chooses), you need to accept that the Abuse Finder tool cannot then take the absence of an "abuse-c:" to mean there is no abuse contact. We are still in the same state we are in now. All the Abuse Finder tool can say is, we can't find an abuse contact, but we saw some reference to the word 'abuse' in "remarks:" or "e-mail:" attributes in these objects, go take a look yourself because we are not sure. Regards Denis Walker Business Analyst RIPE NCC Database Group On 31/07/2012 16:28, Leo Vegoda wrote:
Hi Frank,
On Jul 31, 2012, at 7:03 am, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Leo Vegoda wrote:
Hi Frank,
On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
or no-reply@example.com or send it to devnull …
I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
Simply because its better to have ONE place for reporters.
I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
Forcing these addresses to be working and correct is not part of this proposal and could be discussed later (and fixed with another proposal).
Currently there are lots of places to store the abuse-contact and a lot of them are wrong, because of a lie, lacyness, technical problems or whatsoever.
I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
In future you will have only one place to look for it, probably also with a lot of wrong addresses.
Anyway, it would be better than it is now.
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore.
I do not want to encourage the development of more business logic like this.
You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting …
By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger.
Regards,
Leo Vegoda
Hi Denis, Denis Walker <denis@ripe.net>: [...]
As I follow these discussion my mind keeps focussing on the Abuse Finder tool and the technical nightmare we have right now in trying to make that work. One of the many problems with it is we cannot parse remarks that (may) include abuse contacts.
I think you have highlighted a fundamental issue with the design of RIPE database objects. They include data that is specifically for human consumption in objects that are structured so they can be parsed by software. I do not know what the best way to combine software parsable database objects and human readability is but recognise that this is not the Database WG list and that I am not a database expert. Regards, Leo Vegoda
Hi,
I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
It's not only about the conclusion. As Frank stated there are some legal obligations in between. I do not want to go any deeper here, because I'm not a lawyer :-) The second point is that we probably only force less then 3% of the holders of direct allocations. More than 96% of them have already abuse contacts in place, unfortunately in different and ugly to parse places. I think there must be at least one abuse contact available for every ip address. And the proposal does not care about the place in hierarchy, but the "highest" place should offer one.
I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
I guess we are all neat freaks :-) I'm not sure what your definition of cleaning is. But there is a clean up planned in the impact analysis. Unfortunately the mess is too big to completely clean it up before coming up with new things. The idea is to transfer as much information as possible automatically into the new framework. The things that can't be cleaned up automatically (remarks:) must be cleaned by the resource holders themselves. But just cleaning them up would result in less maybe valuable data in the database. So it is much better than having the new thing in place and ask for a transfer from old to new. That way we will not loose data. It would not make sense to delete all old things and than come up with a new. If cleaning up in your definition means the data accuracy, even than I would prefer the proposals way. By asking to transfer the data accuracy will be increased without anything special, because all the accidentally wrong, forgotten, misspelled,... objects will be updated. In an next step we have to find ways how we can increase data accuracy and how we can keep it on a good level. Which will be another proposal. Talking now about data accuracy would bring us into the situation to left out the abuse contact information, because there are plans that it get's changed (with this proposal) and brings us into the situation of not exactly knowing what we have to handle, because we do not exactly know what we are coming up with.
Lots of resource holders are already doing the same, we keep a list of there email addresses, so we do not have to send them reports that will only fill our mail queue to bounce back. I can understand them and respect that others like to work things different and we do not send them reports anymore. I do not want to encourage the development of more business logic like this. You do need this logic already (even if that logic consist only of an reply-address for your abuse reports, that you do not read at all ;o) You already have this logic, if you have a ticket system for the reports you send out. You then have to deal with all these bounces since you started reporting …
By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger.
While thinking about the points here Frank and Denis sent their mails and the points they brought up are fitting perfectly, so I do not have to write anything here, because I agree fully with their argumentation. Thanks Frank. Thanks Denis. Thanks, Tobias
On Sat, Jul 28, 2012 at 9:19 PM, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion.
Hopefully your opinion stays where it is, and you don't start calling people criminal for not supporting a mandatory field in a database that is full of fake data. In my country, calling people criminal in public violates the law. We happen to live in the same country, don't we, Frank? I know abuse sucks, and it's natural to become bitter and angry about those *&#(@ that eat up valued resources, but we re talking about a database change that would not help at all if we'd change it from "optional" to "mandatory". Just more mails bouncing back. It's not the "abuse field" I am against, it's the "mandatory" since it would impact workflows seriously and create much more trouble than it avoids. Regards, Dan
Dan Luedtke wrote: Hi,
On Sat, Jul 28, 2012 at 9:19 PM, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Anybody, who is against a mandatory abuse field, is a professional spammer, abuser, maintains a bot net or sells open proxies or other services used for abusing others. They are criminals to my opinion.
Hopefully your opinion stays where it is, and you don't start calling people criminal for not supporting a mandatory field in a database that is full of fake data.
Well, you have either none and fake data, like it is now or you make it mandatory and will have correct data (but a lot will be unread). Whats better ?
In my country, calling people criminal in public violates the law. We happen to live in the same country, don't we, Frank?
Sure, and its always puzzeling me, that a lot of people do not know the law in their country even when its regulating their profession. (btw: this list is not public at all, open to everybody, but not public, its like a big garden party and every friend is invited)
I know abuse sucks
The abuse does not suck, the ignorance of responsible people does (next real life story below).
and it's natural to become bitter and angry about those *&#(@ that eat up valued resources, but we re talking about a database change that would not help at all if we'd change it from "optional" to "mandatory". Just more mails bouncing back. It's not the "abuse field" I am against, it's the "mandatory" since it would impact workflows seriously and
Hm, are you in trouble, that every member now has to ask his customer for an abuse address, when creating a subdelegation for them ? Thats not really changing the "workflow" a lot ... Or whatever else "workflow" do you mean ? And who cares how much additional work members and subdelegation admins have with additional abuse reports ? You have to prevent crime in a lot of countries in the RIPE region anyway, see below ...
create much more trouble than it avoids.
Please explain that somehow generic argument. Please give us a summary of your point of view. And now the real live story: 2 days ago a customers nameserver serving a good bunch of domains was DDoSed through a botnet. The attackers did send UDP packets asking for always the same hostname but faked the sender address to DDoS a third party. Surely our customers nameserver did not answer, because its was not asked for a hostname they serve, so no third party was harmed, but the load was immense and troubling the server a lot until we could filter the real source IPs via NetFlow. The bots were mostly located in the usual countries, like India, China, Korea, Kazachstan and worldwide, we did send reports to the responsible admins (well there are nearly none in Kazachstan. Who knows, why they mostly have none there ? somebody from Kazachstan on the list here ?) There were also some in Germany, but only a few. One ISP (a quite big German ISP) wrote us back, that they are only forced by law to store, wich of their customer is using what address at a given time, if they would need it for billing. But they do not need it for billing, because they only offer flatrates. Thats why they cannot find out, wich customers PC has a bot and could not help. Well, wrong. In Germany you have to prevent computer crime, when its easy to detect and easy to prevent and you have knowledge, otherwise you are a "Mitstoerer". Sure you can argue, that you do not have to log anything in general to enforce data protection, but you will defny have to turn logging on, after you have knowledge and this attack is ungoing and the IP (well the IP changes daily, but there is still one IP from this ISP part of the attack). You can easily log, wich customer is logged in at a given time using what IP and you can change his logging password easily and wait for the customer to call to explain the situation to him. So, easy to detect and easy to prevent and you can log only after you are informed about the problem and only to prevent the crime. The case is already reported to the police, lets see how quick they will have a working abuse team in place ... Kind regards, Frank
Regards,
Dan
-- 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 ======================================================================
Frank, One important point Frank Gadegast wrote the following on 03/08/2012 09:20:
(btw: this list is not public at all, open to everybody, but not public, its like a big garden party and every friend is invited)
By any reasonable measure this list is public. Anyone can join and the archives are publicly accessible without login here: http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/
participants (11)
-
"Michele Neylon :: Blacknight" -
Arnold -
Brian Nisbet -
Dan Luedtke -
Denis Walker -
Frank Gadegast -
Ian Eiloart -
Leo Vegoda -
lists＠help.org -
Shane Kerr -
Tobias Knecht