2010-08 New Policy Proposal (Abuse contact information)
Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-08.html We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 6 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC
* Emilio Madaio:
Could RIPE NCC indicate how they plan to prevent that IRT objects fall prey to the same public data erosion that affects other objects in the RIPE database? It would be a waste of time if the RIPE membership jumps through all kinds of hoops to create those objects, and RIPE NCC eventually decides to stop publishing them. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Am 09.11.2010 09:11, schrieb Florian Weimer:
* Emilio Madaio:
Could RIPE NCC indicate how they plan to prevent that IRT objects fall prey to the same public data erosion that affects other objects in the RIPE database?
It would be a waste of time if the RIPE membership jumps through all kinds of hoops to create those objects, and RIPE NCC eventually decides to stop publishing them.
There is another proposal coming soon which faces the data accuracy problem. Thanks, Tobias
* Tobias Knecht:
There is another proposal coming soon which faces the data accuracy problem.
I'm not concerned with data accuracy. It's with availability of the data itself, given current policies set and implemented by RIPE NCC. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Tue, Nov 9, 2010 at 14:06, Florian Weimer <fweimer@bfk.de> wrote:
I'm not concerned with data accuracy. It's with availability of the data itself, given current policies set and implemented by RIPE NCC.
I agree that the current IRT model does not scale. I, wrongly, assumed that irts could just be created without fuss as the webupdate interface pretends you can simply add them without any manual verificiation of RIPE. A staged system (created, verified, etc) might make sense for IRT. This would allow the RIPE to verify what they want to verify, yet allow the RIRs to update quickly. Alternatively, the requirements for IRTs could be losened. Finally, an unverified abuse-c could function in parallel to a verified IRT. This obviously introduces other problems. All that being said, I still feel that a mandatory, unified, non-rate-limited abuse contact Is A Good Thing. Richard
On Tue, Nov 9, 2010 at 16:07, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
A staged system (created, verified, etc) might make sense for IRT. This would allow the RIPE to verify what they want to verify, yet allow the RIRs to update quickly.
s/RIR/LIR/ I need coffee. Richard
Richard Hartmann wrote:
On Tue, Nov 9, 2010 at 14:06, Florian Weimer <fweimer@bfk.de> wrote:
I'm not concerned with data accuracy. It's with availability of the data itself, given current policies set and implemented by RIPE NCC.
I agree that the current IRT model does not scale. I, wrongly, assumed that irts could just be created without fuss as the webupdate interface pretends you can simply add them without any manual verificiation of RIPE.
A staged system (created, verified, etc) might make sense for IRT. This would allow the RIPE to verify what they want to verify, yet allow the RIRs to update quickly.
Alternatively, the requirements for IRTs could be losened.
Please remember that the IRT object was not designed for general abuse handling. It was created for Incident Response Teams (hence the name) who handle the bigger Internet network and security problems. This is why it has "encryption:" and "signature:" attributes and is referenced by a maintainer attribute that requires authorisation to add a reference to an IRT object. We have already weakened its main purpose by making the above attributes optional. For Incident Response Teams these should be mandatory attributes. Now they are required attributes, but as we cannot distinguish between the two different roles this object now serves we cannot enforce this requirement. If we loosen the requirements any further for the IRT object it will no longer serve its original purpose. Regards Denis Walker Business Analyst RIPE NCC Database Group
Finally, an unverified abuse-c could function in parallel to a verified IRT. This obviously introduces other problems.
All that being said, I still feel that a mandatory, unified, non-rate-limited abuse contact Is A Good Thing.
Richard
* Denis Walker:
Please remember that the IRT object was not designed for general abuse handling. It was created for Incident Response Teams (hence the name) who handle the bigger Internet network and security problems.
It seems to me that this statement is at odds with the current documentation. It also does not match my own recollection of history. Neither FIRST nor the Trusted Introducer framework restricted their membership to those who handle incidents of a particular significance or had a certain type of constituency. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/11/10 16:15, Florian Weimer wrote:
It seems to me that this statement is at odds with the current documentation. It also does not match my own recollection of history. Neither FIRST nor the Trusted Introducer framework restricted their membership to those who handle incidents of a particular significance or had a certain type of constituency.
Seconded. I can't speak for all CSIRT teams, most would consider it to be a usual part of the remit of an IRT, and would consider a team that only dealt with abuse as a specialized IRT (even if the team in question doesn't call itself an IRT). James - -- James Davis +44 1235 822229 PGP: 0xD1622876 Senior CSIRT Member 0300 999 2340 (+44 1235 822340) Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzZd3EACgkQhZi14NFiKHaHgACfb8HzBuDVL9XrH+SiDSkysEXb /qEAn3vZ1mFJZTV+ERqzt8RBT5yuWiRl =Muo6 -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
James Davis wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/11/10 16:15, Florian Weimer wrote:
It seems to me that this statement is at odds with the current documentation. It also does not match my own recollection of history. Neither FIRST nor the Trusted Introducer framework restricted their membership to those who handle incidents of a particular significance or had a certain type of constituency.
Seconded.
I can't speak for all CSIRT teams, most would consider it to be a usual part of the remit of an IRT, and would consider a team that only dealt with abuse as a specialized IRT (even if the team in question doesn't call itself an IRT).
Then perhaps as a parallel activity we need to (re)define what an IRT object is now. Looking at some historical and current documents: http://www.ripe.net/ripe/docs/ripe-254.html http://www.ripe.net/db/support/security/irt/irt-h2.html http://www.ripe.net/db/support/security/irt/faq.html http://www.ripe.net/db/support/update-reference-manual.html#1.2.9 they talk a lot about accredited CSIRT teams and using secure email correspondence. The RIPE NCC no longer validates CSIRT teams creating IRT objects. Use of PGP keys is all optional now. Does an end user with a PI prefix represent a CSIRT team? Does Abuse Handler mean the same thing? Do we still have Trusted Introducer accredited teams with IRT objects maintained on their behalf? The documentation is very much out of step with the way IRT objects are created and used and what they mean now. Regards Denis Walker Business Analyst RIPE NCC Database Group
James
- -- James Davis +44 1235 822229 PGP: 0xD1622876 Senior CSIRT Member 0300 999 2340 (+44 1235 822340) Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzZd3EACgkQhZi14NFiKHaHgACfb8HzBuDVL9XrH+SiDSkysEXb /qEAn3vZ1mFJZTV+ERqzt8RBT5yuWiRl =Muo6 -----END PGP SIGNATURE-----
JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
On Tue, Nov 9, 2010 at 16:45, Denis Walker <denis@ripe.net> wrote:
We have already weakened its main purpose by making the above attributes optional. For Incident Response Teams these should be mandatory attributes. Now they are required attributes, but as we cannot distinguish between the two different roles this object now serves we cannot enforce this requirement. If we loosen the requirements any further for the IRT object it will no longer serve its original purpose.
According to the technical howto [1] the irt object already has a concept of trust levels, albeit as a remark. Formalizing a level attribute would allow unverified mostly-optional irt objects to exist in parallel to unverified mostly-required and trusted introduction all-required ones. Richard [1] http://www.ripe.net/db/support/security/irt/irt-h2.html
On 8 nov 2010, at 16:14, Emilio Madaio wrote:
Dear Colleagues,
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2010-08.html
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 6 December 2010.
Regarding this proposal, people might want to have a look at the archives from 2004. I know times have changed, so it may all not be relevant anymore. But during the discussion around the introduction of abuse-c and where it should be placed a lot of comments were made, some of which might possibly still hold true today. The original idea behind abuse-c was to create a fixed format attribute instead of people using the remarks field, which was and is common practice for a lot maintainers. The main purpose for this, was to stop people using a simple grep '@' command to find contact points and thus spamming each and every contact returned, including the changed lines. At the same time it was decided to no longer show the changed attributes by default, again to guide people into the right direction on which contact to use. Minutes/presentations on this subject can be found at: http://www.ripe.net/ripe/wg/db/minutes/ripe-47.html http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-db-abusec.pdf http://www.ripe.net/ripe/wg/db/minutes/ripe-48.html http://www.ripe.net/ripe/wg/db/minutes/ripe-49.html And the relevant mailing lists (primarly db-wg, some anti-spam) for this period. I think again with this proposal the main issue is not forcing people to create and reference an IRT object. Although during the 2004 discussion some strong arguments were made against it. The big challenge is to make sure the database users actually starting to take notice and using the IRT as a contact point. This means educating them and providing easy and clear documentation on how to use the RIPE database. This is somewhat easy for the resource holders, but much harder for the community who is querying the database. Now this documentation could point to IRT, it could also simply still point to abuse-c. It is not as much as what the message contains, it's about getting it across in the first place. My personal view is this won't solve the main issue. Making IRT mandatory does not improve data quality especially not in the long run. People might just put something in to make things work or they will simply forget to update the object once it's there. I realize there is another proposal floating around to fix this by introducing a regular check. But as these are seperate there is no guarantee both will make it to implementation. And again making it mandatory for people putting stuff in the database, by no means mean people pulling data from the database will start using it. At least not unless you tell them how. MarcoH (no hats other than concerned citizen)
On 9 Nov 2010, at 12:49, Marco Hogewoning wrote: [...]
My personal view is this won't solve the main issue. Making IRT mandatory does not improve data quality especially not in the long run. People might just put something in to make things work or they will simply forget to update the object once it's there. I realize there is another proposal floating around to fix this by introducing a regular check. But as these are seperate there is no guarantee both will make it to implementation. And again making it mandatory for people putting stuff in the database, by no means mean people pulling data from the database will start using it. At least not unless you tell them how.
I think you have highlighted something very important. No policy can ensure that network operators deal with abuse reports they don't have any interest in reading or resolving. Given that situation, removing the mandatory IRT reference makes that group more visible because they will have chosen not to create an IRT. This will help people reporting abuse as they'll know the operator wouldn't take the reports seriously anyway. People interested in receiving abuse reports can already indicate that fact by creating an IRT object or adding an abuse-mailbox line to their maintainer. Making an IRT object mandatory will only enforce the form and not the intent. As such, I suspect it would add cost without value. By all means create additional educational and training material but please don't remove an indicator for how seriously a network operator will take an abuse report. Regards, Leo Vegoda
My personal view is this won't solve the main issue. Making IRT mandatory does not improve data quality especially not in the long run. People might just put something in to make things work or they will simply forget to update the object once it's there. I realize there is another proposal floating around to fix this by introducing a regular check. But as these are seperate there is no guarantee both will make it to implementation. And again making it mandatory for people putting stuff in the database, by no means mean people pulling data from the database will start using it. At least not unless you tell them how.
And the how is the big problem on both sides. What is the right way to publish abuse contact information? remark field? abuse-mailbox attribute? Or is it the IRT? There are so many options that nobody really knows how to handle it. One of my biggest concerns about the existing situation is printed here: http://bit.ly/a5PNlH "The total amount of queries the service makes to the RIPE Database may range between 30 and 150 queries. This depends largely on the amount of referenced objects the routine has to retrieve." Needing up to 150 queries to find an abuse contact shows clearly that there is a huge variety of possible places, which confuses and frustrates people.
I think you have highlighted something very important. No policy can ensure that network operators deal with abuse reports they don't have any interest in reading or resolving. Given that situation, removing the mandatory IRT reference makes that group more visible because they will have chosen not to create an IRT. This will help people reporting abuse as they'll know the operator wouldn't take the reports seriously anyway.
People interested in receiving abuse reports can already indicate that fact by creating an IRT object or adding an abuse-mailbox line to their maintainer. Making an IRT object mandatory will only enforce the form and not the intent. As such, I suspect it would add cost without value.
I absolutely agree with that and I can live with that, if we decide to make the IRT Object the only place where abuse contact information will be published in future. That means we stop using abuse-mailbox attributes outside IRT Objects and we communicate that the IRT is the "only" place to publish abuse contact information. The next step that will happen, or is already happening is that ISPs are using the reputation data you are talking about to block, for example email, which is a pretty good idea in my opinion. "As long as you do not offer a address where I can complain about your traffic I do not want your traffic." And as soon as this happens people will create IRT Objects to get their mail delivered and nobody knows if they are handling their abuse complaints or just created the IRT Object. BTW: We are receiving several request about such a reputation list every week. Thanks, Tobias abusix.org
2010/11/10 Tobias Knecht <tk@abusix.com>:
The next step that will happen, or is already happening is that ISPs are using the reputation data you are talking about to block, for example email, which is a pretty good idea in my opinion. "As long as you do not offer a address where I can complain about your traffic I do not want your traffic."
I don't see this happening; ever. Large impact triggered by a way too low metric. That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing. Richard
Am 10.11.2010 10:24, schrieb Richard Hartmann:
2010/11/10 Tobias Knecht <tk@abusix.com>:
The next step that will happen, or is already happening is that ISPs are using the reputation data you are talking about to block, for example email, which is a pretty good idea in my opinion. "As long as you do not offer a address where I can complain about your traffic I do not want your traffic."
I don't see this happening; ever. Large impact triggered by a way too low metric.
Some ISPs in Europe are already using this as a greylisting reason.
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
And that is one of my main intentions with this proposal. Thanks, Tobias
On Wed, Nov 10, 2010 at 11:22:40AM +0100, Tobias Knecht wrote:
Am 10.11.2010 10:24, schrieb Richard Hartmann:
2010/11/10 Tobias Knecht <tk@abusix.com>:
The next step that will happen, or is already happening is that ISPs are using the reputation data you are talking about to block, for example email, which is a pretty good idea in my opinion. "As long as you do not offer a address where I can complain about your traffic I do not want your traffic."
I don't see this happening; ever. Large impact triggered by a way too low metric.
Some ISPs in Europe are already using this as a greylisting reason.
And that is a problem, Tobias. You are using words like "some" or "We are receiving several request about such a reputation list every week." These are no facts which we can check. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
The next step that will happen, or is already happening is that ISPs are using the reputation data you are talking about to block, for example email, which is a pretty good idea in my opinion. "As long as you do not offer a address where I can complain about your traffic I do not want your traffic."
I don't see this happening; ever. Large impact triggered by a way too low metric.
Some ISPs in Europe are already using this as a greylisting reason.
And that is a problem, Tobias. You are using words like "some" or "We are receiving several request about such a reputation list every week." These are no facts which we can check.
I fully understand. Okay so I try to stop talking about things you are not able to prove. Sorry for that. But nevertheless the existence or the non-existence of an object will never be able to judge about the things Leo Vegoda mentioned. It is not an indicator if abuse handling is taken serious if there is an IRT Object or not. Thanks, Tobias abusix.org
On 10 Nov 2010, at 10:22, Tobias Knecht wrote:
Some ISPs in Europe are already using this as a greylisting reason.
I assume you're referring to email? If so, why is that a problem? Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon PS: Check out our latest offers on domains & hosting: http://domainoffers.me/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Some ISPs in Europe are already using this as a greylisting reason.
I assume you're referring to email?
Right.
If so, why is that a problem?
If you want to judge on the existence of the IRT if somebody is doing abuse handling or not you should not make the IRT mandatory. That was Leo Vegoda saying. As soon as people will decide to do so and add the existence of an IRT to their reputation metrics, there is pressure and pushed by this pressure people will create IRT Objects, but not with the intent to do a good abuse job, but with the intent of deliverability. So imo this is no reason to make the IRT not mandatory. Thanks, Tobias abusix.org
Um ok, but what has that got to do with greylisting??? Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 10 Nov 2010, at 11:06, "Tobias Knecht" <tk@abusix.com> wrote:
Some ISPs in Europe are already using this as a greylisting reason.
I assume you're referring to email?
Right.
If so, why is that a problem?
If you want to judge on the existence of the IRT if somebody is doing abuse handling or not you should not make the IRT mandatory. That was Leo Vegoda saying.
As soon as people will decide to do so and add the existence of an IRT to their reputation metrics, there is pressure and pushed by this pressure people will create IRT Objects, but not with the intent to do a good abuse job, but with the intent of deliverability.
So imo this is no reason to make the IRT not mandatory.
Thanks,
Tobias
abusix.org
Am 10.11.2010 12:09, schrieb Michele Neylon :: Blacknight:
Um ok, but what has that got to do with greylisting???
Greylisting was just one example of what is or could happen in future, that creates pressure. Thanks, Tobias abusix.org
Huh? Greylisting doesn't cause any real issues unless your setup is badly broken If you're trying to make a point then it's not working ... Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 10 Nov 2010, at 11:21, "Tobias Knecht" <tk@abusix.com> wrote:
Am 10.11.2010 12:09, schrieb Michele Neylon :: Blacknight:
Um ok, but what has that got to do with greylisting???
Greylisting was just one example of what is or could happen in future, that creates pressure.
Thanks,
Tobias
abusix.org
Greylisting doesn't cause any real issues unless your setup is badly broken If you're trying to make a point then it's not working ...
It does. Believe me. ISP-A is greylisting mails from ISP-B and those mails will be deferred by only 10 minutes. Over a while customers of ISP-B will wonder why mails take more than 10 minutes to be delivered and postmaster will wonder why his Qs are getting bigger and bigger. It is not hurting that much, but if you can fix it by creating an IRT, you will probably do. Thanks, Tobias abusix.org
On 10 Nov 2010, at 11:33, Tobias Knecht wrote:
Greylisting doesn't cause any real issues unless your setup is badly broken If you're trying to make a point then it's not working ...
It does. Believe me. ISP-A is greylisting mails from ISP-B and those mails will be deferred by only 10 minutes. Over a while customers of ISP-B will wonder why mails take more than 10 minutes to be delivered and postmaster will wonder why his Qs are getting bigger and bigger.
See my comment about setups .. If ISP A sends any volume of mail to ISP B then they will be in the whitelist all the time and the mail won't be delayed at all If that's not happening then either: 1 - ISP A isn't sending mail to B in any real volume OR 2 ISP B has a botched setup
It is not hurting that much, but if you can fix it by creating an IRT, you will probably do.
Why on earth would a contact object of any kind have any impact on how people handle inbound mail? It's a total non-sequitir If network A is sending junk to network B then network B will probably block network A regardless of what contact points are available Even if the contact points are available and you report the abuse chances are that a bad operator isn't going to reply anyway, so I don't see what you're actually achieving And I'm not going to start blocking mail from any of the large ISPs / Telcos .. As the impact on my customers would lead to massive headaches
Thanks,
Tobias
abusix.org
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon PS: Check out our latest offers on domains & hosting: http://domainoffers.me/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Michele Neylon :: Blacknight wrote:
Huh? Greylisting doesn't cause any real issues unless your setup is badly broken If you're trying to make a point then it's not working ...
All spambots we know, do not have a queue to start a second delivery after the first connect was blocked. Thats because you usually cut out a lot of spam by using greylisting. Greylisting surely delays email and blocks the sender queue, that why we dont like it. We prefer another method, by directing the lowest MX to a dead and not working IP. Any normal mailserver sends mail to this dead IP first, does not get a connect and selects the secondary MX (what is really the working primary MX) in seconds without having to queue it. This keeps the queue small for all good senders, has nearly no delay and still blocks out most spambots (except those that are using the 2nd or 3rd MX all the time). Kind regards, Frank
Mr. Michele Neylon Blacknight http://Blacknight.tel
Via iPhone so excuse typos and brevity
On 10 Nov 2010, at 11:21, "Tobias Knecht"<tk@abusix.com> wrote:
Am 10.11.2010 12:09, schrieb Michele Neylon :: Blacknight:
Um ok, but what has that got to do with greylisting???
Greylisting was just one example of what is or could happen in future, that creates pressure.
Thanks,
Tobias
abusix.org
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
Tobias Knecht wrote: Hi all,
Some ISPs in Europe are already using this as a greylisting reason.
I assume you're referring to email?
Right.
If so, why is that a problem?
If you want to judge on the existence of the IRT if somebody is doing abuse handling or not you should not make the IRT mandatory. That was Leo Vegoda saying.
As soon as people will decide to do so and add the existence of an IRT to their reputation metrics, there is pressure and pushed by this pressure people will create IRT Objects, but not with the intent to do a good abuse job, but with the intent of deliverability.
So imo this is no reason to make the IRT not mandatory.
Just the other way. Spammer and spammer friendly ISPs WILL create IRT objects containing a valid (but unread) email address, just to get there mails delivered. So it has to be mandatory, giving RIPE NCC the possibility to check those email addresses on a regular basis. Having it mandatory and checked will give us a working abuse contact for every ISP that IS taking care and at least a working but unread contact for those which are not taking care. Our next step with our own blacklist is then to check if there is at least ticket numbers or similar coming back from those abuse addresses, and if not, create a soft entry like "1.0 Non-responsive abuse contact" in SpamAssassin ;o) And we could even analyze, if a abusive IP re-occurs after a while and make another entry like "3.0 spamming IP re-occurs after ISPs intervention" (even if the spammer or spammer friendly ISP generates ticket numbersi or replies, but still does no do anything ;o) So, we could finally find unwilling ISPs easily and we could be sure, that they are informed about abuse, but still dont do anything. And block them completely ;o) Today we cannot be sure, if the member is informed about the problem at all and we need to change that. 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 ====================================================================== Public PGP Key available for frank@powerweb.de -- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
2010/11/10 Tobias Knecht <tk@abusix.com>:
Some ISPs in Europe are already using this as a greylisting reason.
Greylisting != blocking all traffic to and from. Using the existence of irt objects as a soft indicator for soft decisions is a neat concept. Flooding the db with irt objects might hurt this, in a way. Introducing formal levels for irt objects would keep the old system intact. Quick, informal poll: Who thinks an irt level concept would be useful? Am I overlooking any procedural, policy or technical limitations? Richard
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1 Sander
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004: - number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it. Groet, MarcoH
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I wasn't thinking about throwing away any data. A single point containing at least the same amount of information that we have now would be very nice though. The difficult part is how to migrate all that information to that single point... Sander
Am 10.11.2010 12:01, schrieb Sander Steffann:
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I wasn't thinking about throwing away any data. A single point containing at least the same amount of information that we have now would be very nice though. The difficult part is how to migrate all that information to that single point...
Full Ack. A mandatory place will help with the migration process. Asking members to create IRT Objects over a period of 2 years should migrate a huge amount. Contacting the members without a valid IRT link every 6 or 12 month will help as well. Thanks, Tobias abusix.org
On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004:
- number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"? Kostas
Groet,
MarcoH
On Wed, Nov 10, 2010 at 01:05:51PM +0200, Kostas Zorbadelos wrote:
On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004:
- number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
And how anybody could stop publishing this kind of info in remark fields? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Am 10.11.2010 12:29, schrieb Piotr Strzyzewski:
On Wed, Nov 10, 2010 at 01:05:51PM +0200, Kostas Zorbadelos wrote:
On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004:
- number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information? Thanks, Tobias abusix.org
On Wed, Nov 10, 2010 at 12:37:25PM +0100, Tobias Knecht wrote:
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information?
Since we are not going to delete that, there is huge change to have a lot of such remarks fields. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi,
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
Sorry. That was to broadly. ;-) Everybody meant, every RIPE member and everybody who wants to use abuse contact information for serious reporting or work.
is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information?
Since we are not going to delete that, there is huge change to have a lot of such remarks fields.
If there are ways to delete remark fields containing abuse@ addresses, we can do that, but I guess we will not catch stuff like remark: Please send complaints about spam to remark: abuse@domain.tld in an appropriate way. Thanks, Tobias abusix.org
On Wed, Nov 10, 2010 at 01:12:22PM +0100, Tobias Knecht wrote:
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
Sorry. That was to broadly. ;-) Everybody meant, every RIPE member and everybody who wants to use abuse contact information for serious reporting or work.
Police. They use it "for serious reporting or work". They are not so experienced and up-to-date with current policies no matter what we want. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Am 10.11.2010 13:35, schrieb Piotr Strzyzewski:
On Wed, Nov 10, 2010 at 01:12:22PM +0100, Tobias Knecht wrote:
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
Sorry. That was to broadly. ;-) Everybody meant, every RIPE member and everybody who wants to use abuse contact information for serious reporting or work.
Police. They use it "for serious reporting or work". They are not so experienced and up-to-date with current policies no matter what we want.
Sorry, but that is no reason. And I bet police would absolutely appreciate this proposal. Tell them about the RIPE Abuse Finder or any other API, where they can put in an IP and "always" get back an abuse contact and they will be absolutely happy. Thanks, Tobias abusix.org
On Wed, Nov 10, 2010 at 01:42:14PM +0100, Tobias Knecht wrote:
Tell them about the RIPE Abuse Finder or any other API, where they can
One more time - Stop joking :) There are so many of them.
put in an IP and "always" get back an abuse contact and they will be absolutely happy.
Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Tell them about the RIPE Abuse Finder or any other API, where they can put in an IP and "always" get back an abuse contact and they will be absolutely happy.
So you want to educate people. Then maybe you want to make a proposal about that instead of making things mandatory and hope it will fix itself. Groet, MarcoH (no hats)
Piotr Strzyzewski wrote:
On Wed, Nov 10, 2010 at 12:37:25PM +0100, Tobias Knecht wrote:
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
I doubt that. My personal expierience is that none of our normal users ever complained about the spam and tried something like whois nor knows what whois is. They maybe try to complain to the admin-c of the sender domain, but would never identify the IP of the sender beeing the cause of the problem. And thats why I think (but cannot proove with facts) that whois is only used by RIPE members, ISPs, sophisticated network admins or blacklists admins anyway. Maybe somebody from RIPE NCC can count how often dynamic IPs are using whois compared to fixed networks ...
is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information?
Since we are not going to delete that, there is huge change to have a lot of such remarks fields.
What could be automated easily by RIPE NCC. RIPE NCC could contact members and list ranges without IRT objects from time to time. RIPE NCC could present those ranges when logging into RIPE portal so the member could select and add the right IRT object with one click. The portal could even detect abuse contacts in remarks and offer to delete these lines in the same step. 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On Wed, Nov 10, 2010 at 01:20:38PM +0100, Frank Gadegast wrote:
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
I doubt that. My personal expierience is that none of our normal users ever complained about the spam and tried something like whois nor knows what whois is.
Police. They use whois. They use very first email which they find in the database.
Maybe somebody from RIPE NCC can count how often dynamic IPs are using whois compared to fixed networks ...
Which proove what? A lot of regular users has non-dynamic IPs. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Piotr Strzyzewski wrote:
On Wed, Nov 10, 2010 at 01:20:38PM +0100, Frank Gadegast wrote:
Unfortunately you can't. But if everybody knows that the mandatory IRT
Everybody? Stop joking. :) Every single regular not-technical user who heard about whois on facebook forum?
I doubt that. My personal expierience is that none of our normal users ever complained about the spam and tried something like whois nor knows what whois is.
Police. They use whois. They use very first email which they find in the database.
Sorry, that the police men you had contact with are that uneducated (well, educate them). The police I had contact to knew how to use whois right. A new whois output having only personal email addresses for admin-c, tech-c aso PLUS an easy identifiable IRT abuse object would be self-explaining anyway. People are usually not that stupid to identify something they are looking for, if the format is not confusing in the first place (like it is now because of several places where abuse contacts can be stored). The output format could insert a standard line, that its the abuse contact in big letters with lots of stars ;o)
Maybe somebody from RIPE NCC can count how often dynamic IPs are using whois compared to fixed networks ...
Which proove what? A lot of regular users has non-dynamic IPs.
A percentage would be helpful. Guess its only 10% of the whois queries or even less. This would clearly indicate, that only pros use whois. Specially because I think about all automated systems ... Our blacklist is doing more whois queries a day then we have customers all together ;o) Far more ... Kind regards, Frank
Piotr
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
They maybe try to complain to the admin-c of the sender domain, but would never identify the IP of the sender beeing the cause of the problem.
And thats why I think (but cannot proove with facts) that whois is only used by RIPE members, ISPs, sophisticated network admins or blacklists admins anyway.
Maybe somebody from RIPE NCC can count how often dynamic IPs are using whois compared to fixed networks ...
They do and they do it a lot. That's why since 2004 changed lines and other poossible contact points are suppressed in the default output. The problem with misdirected complaints was getting bigger than the spam problem itself. You can filter spam, but you can't easikly filter complaints. Or at least it's not very nice to filter them. Groet, MarcoH
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information?
No they don't, at least not in the next decade. It might slowly move, but it by no means will be a flag day. Tools exit and people will keep using them even when they know there is something better. I come from the IPv6 lobby, trust me I know :( Groet, MarcoH (oh and still only here as a concerned citizen, no hats)
Am 10.11.2010 13:51, schrieb Marco Hogewoning:
And how anybody could stop publishing this kind of info in remark fields?
Unfortunately you can't. But if everybody knows that the mandatory IRT is the place to publish abuse contact information, nobody will look for remark fields any further. And if you have to have an IRT, why publish a remark field with the same information?
No they don't, at least not in the next decade. It might slowly move, but it by no means will be a flag day. Tools exit and people will keep using them even when they know there is something better.
Even if its moving slowly, it's moving. And that is something, that is not happing since the introduction of the IRT Object a few years ago.
I come from the IPv6 lobby, trust me I know :(
Sincere condolences and congratulations in the same second. It took time and it will still take time, but it is moving. Thanks, Tobias abusix.org
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
And how anybody could stop publishing this kind of info in remark fields?
Yups, +1...we can discard the abuse-mailbox field but not the remarks. That's why I suggested to get the statistics done again. Most likely the majority of the objects are still covered with a remarks line and at least that is better than nothing. Groet, MarcoH
Am 10.11.2010 13:49, schrieb Marco Hogewoning:
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
And how anybody could stop publishing this kind of info in remark fields?
Yups, +1...we can discard the abuse-mailbox field but not the remarks. That's why I suggested to get the statistics done again. Most likely the majority of the objects are still covered with a remarks line and at least that is better than nothing.
Don't get me wrong. I do not want to delete data before there is a IRT. Since the IRT will be mandatory, RIPE is able to push things faster. Contact people, ask them to update, ... This will take some time. And there is no reason to say, that we will delete the existing abuse-mailbox attributes not before an IRT is setup. There is no reason not to change "end of 2012" into "end of 2013" The point is, that this discussion is going on for more than 7 years now and there is still no sufficient solution. Thanks, Tobias abusix.org
On 11/10/10 13:58, Tobias Knecht wrote:
The point is, that this discussion is going on for more than 7 years now and there is still no sufficient solution.
Some of us, me that is, doesn't think there is a problem, hence discussing a solution would seem odd. On the other hand I almost never complain as I believe it is an error not to fix the problem yourself.
Jørgen Hovland wrote:
On 11/10/10 13:58, Tobias Knecht wrote:
The point is, that this discussion is going on for more than 7 years now and there is still no sufficient solution.
Some of us, me that is, doesn't think there is a problem, hence discussing a solution would seem odd.
??? So you dont receive or send abuse emails ? Or you are such a good programmer that you can handle the current "spread" of abuse contacts in whois ?
On the other hand I almost never complain as I believe it is an error not to fix the problem yourself.
Splitting good from eval IS helpful. Simplification IS helpful (for complainants and programmers and receivers) and will help everybody to send complaints to the right person. Sending complaints raises the pressure to handle complaints. Identifying uncooperative member helps also. Or short: chaos is bad and needs to be organized ;o) 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On 11/10/10 14:31, Frank Gadegast wrote:
???
So you dont receive or send abuse emails ?
Of course I do. I have the honor of deleting automated lawyertreats and "that guy is really, really mean and I really hate him"-messages from my inbox every day. I even received a personal threat recently because the complainer had a fatal error on their system.
Or you are such a good programmer that you can handle the current "spread" of abuse contacts in whois ?
I can read english and a few other languages, but I am not ordinary Joe. This thread has more or less become a discussion about the need to send complaints as fast as possible without the need of thinking or taking any considerations or precautions. You want everyone to have a huge button that says complain and you want to click on it as many times as you want because you are so darn angry. I however, want a button that says "stop whining, click here to play Angry bird instead". Back to the topic: IRT yes, mandatory no. And that's mainly because of the word mandatory and that it would probably lead to more complaints. To be perfectly honest I don't even believe everyone should be entitled to complain. Real abuse issues usually gets through anyway.
Jørgen Hovland wrote:
On 11/10/10 14:31, Frank Gadegast wrote:
???
So you dont receive or send abuse emails ?
Of course I do. I have the honor of deleting automated lawyertreats and "that guy is really, really mean and I really hate him"-messages from my inbox every day. I even received a personal threat recently because the complainer had a fatal error on their system.
Or you are such a good programmer that you can handle the current "spread" of abuse contacts in whois ?
I can read english and a few other languages, but I am not ordinary Joe. This thread has more or less become a discussion about the need to send complaints as fast as possible without the need of thinking or taking any considerations or precautions. You want everyone to have a huge button that says complain and you want to click on it as many times as you want because you are so darn angry. I however, want a button that says "stop whining, click here to play Angry bird instead".
Thats your estimation, but not my intention :o) I simply want ONE clearly defined contact instead of the messy whois we currentyl have. I even somtimes have complains from ISPs that WANT reports, that we did not fetch the right abuse address from whois, what happens from time to time, if its really hidden in strange format somewere in the remarks ... arin's abuse-c is much nicer and less confusing for everybody. And because APNIc is witching to IRT, RIPE should do this two or select another clear way, maybe LACNIC, Afrinic and the others are following ...
Back to the topic: IRT yes, mandatory no. And that's mainly because of the word mandatory and that it would probably lead to more complaints. To be perfectly honest I don't even believe everyone should be entitled to complain. Real abuse issues usually gets through anyway.
Not at all. We report all spam our customers receive. All password-checking, sniffing and DDoS-Attacks and we automated or half-automated most of it. And we currently: - cannot find the abuse address without mistakes - cannot be sure that our complaint reached the one beeing officially responsible (simply because he filed the mandatory field or object) - and cannot detect if the receiver is not interested, lazy or spammer friendly, out of office or whatsoever And this is simply because there is no mandatory field ... 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 ======================================================================
On 11/10/10 17:42, Frank Gadegast wrote:
I simply want ONE clearly defined contact instead of the messy whois we currentyl have.
But making things mandatory doesn't solve poor design.
Not at all. We report all spam our customers receive.
My ideas about this is probably a bit drastic, but I usually never report spam unless I know the ISP/system because it doesn't make any sense. We do however block it (the spam, not the ISP). It doesn't give us any benefits to report it. We get paid to filter spam. If I reported it the spam would stop. That's bad for business.
All password-checking, Why are you reporting that? We have things like that constantly 24/7. In a perfect world, your system should be designed to filter this instead.
sniffing I'm not sure if I understand what this means, but you would probably spend your time changing passwords instead of complaining that somebody stole them. Nevertheless, this would be a case for law enforcement if it's so important.
and DDoS-Attacks
Seriously. The 90s just called. They want you back.
And we currently: - cannot find the abuse address without mistakes - cannot be sure that our complaint reached the one beeing officially responsible (simply because he filed the mandatory field or object) - and cannot detect if the receiver is not interested, lazy or spammer friendly, out of office or whatsoever
And this is simply because there is no mandatory field ...
I think people often mix contact information with abuse contact information. Sometimes it's the same, sometimes not. Some people don't understand the difference and some people don't care and mail everyone anyway. This is where the database design/language perhaps could be improved. Contact information is to me more important than abuse contact information because it lets me get in touch with the legal entity. Remember that a complaint is just a message saying you are unhappy with something. You can never expect anyone to reply or even do anything about it, and they have their fully right to do so.
Jørgen Hovland wrote:
On 11/10/10 17:42, Frank Gadegast wrote:
I simply want ONE clearly defined contact instead of the messy whois we currentyl have.
But making things mandatory doesn't solve poor design.
??? please explain, dont get it.
Not at all. We report all spam our customers receive.
My ideas about this is probably a bit drastic, but I usually never report spam unless I know the ISP/system because it doesn't make any sense. We do however block it (the spam, not the ISP). It doesn't give us any benefits to report it. We get paid to filter spam. If I reported it the spam would stop. That's bad for business.
You should report all spam. Most good working ISPs are very happy to be informed, when one of their dialin customer has a trojan installed. We also get a lot of feedback from end users, that they fixed the security hole of their housing server, after we informed them.
All password-checking, Why are you reporting that? We have things like that constantly 24/7. In a perfect world, your system should be designed to filter this instead.
Surely we block them also, but we report this, to that the end customer is informed about the trojan hes running, or his ISP is informed. Every day, we stop a couple of hundred botted PCs and servers world-wide.
sniffing I'm not sure if I understand what this means, but you would probably spend your time changing passwords instead of complaining that somebody stole them. Nevertheless, this would be a case for law enforcement if it's so important.
We detect network sniffing BEFORE it actually steals passwords, by monitoring the MAC-addresses in our network.
and DDoS-Attacks
Seriously. The 90s just called. They want you back.
???? DDoS attacks happen every day, get detected and blocked. We use advanced flow-control to detect this traffic and complain to the ISPs this traffic is really coming from. It helps a lot. Cannot see the 90er here. Not telling anybody about his security holes because of lazyness or not enough knowledge is 80th ... BTW: your mailserver does not read our SPF-records right and denies mail from us ...
I think people often mix contact information with abuse contact information. Sometimes it's the same, sometimes not. Some people don't understand the difference and some people don't care and mail everyone anyway. This is where the database design/language perhaps could be improved. Contact information is to me more important than abuse contact information because it lets me get in touch with the legal entity.
Legal issues are comunicated still via paper (and have to) or fax or phone (for the first contact). There is no need for an email address of the admin-c. Simple leave too email address via whois: routing and abuse
Remember that a complaint is just a message saying you are unhappy with something. You can never expect anyone to reply or even do anything about it, and they have their fully right to do so.
Well, I see all the mails coming back and we surely store statistics about any IP causing abuse. And we see how many of those get fixed, so a lot of people are happy about reports (I even know this from talks to major German ISPs, they all have a working abuse department and all really DO something these days). 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 ====================================================================== Public PGP Key available for frank@powerweb.de
You should report all spam.
Who has the time? :) My (old) copy of SpamAssassin caught 1,456 spam messages to me yesterday. Another few dozen were handled by ThunderBird's Bayesian detection and by hand. Rob
Rob Evans wrote:
You should report all spam.
Who has the time? :)
If you have money you can send them to SpamCop ;o) If you dont, you could send them automatically to the responsible abuse admin, with a little script, after the proposal is accepted.
My (old) copy of SpamAssassin caught 1,456 spam messages to me yesterday. Another few dozen were handled by ThunderBird's Bayesian detection and by hand.
A simple SQL-query, and a little procmail/perl/php- script could do the job and report every mail with a really big spam score easily. Currently its really complicated, because of the whois mess.
Rob
Crime does not go away, if you ignore it ... And all ISPs I talk too are happy to find infected customers PCs as quick as possible. More people reporting help a lot. Stopping infected PCs quicker help to reduce the spammers revenue. 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On 11/11/10 10:21, Frank Gadegast wrote:
But making things mandatory doesn't solve poor design.
??? please explain, dont get it.
You are unable to find the (abuse) contact because you don't know where to look, not that it isn't there because it wasn't mandatory.
We also get a lot of feedback from end users, that they fixed the security hole of their housing server, after we informed them.
This is great.
We detect network sniffing BEFORE it actually steals passwords, by monitoring the MAC-addresses in our network.
But you are talking about your own customers. You will always have their contact information.
DDoS attacks happen every day, get detected and blocked. Exactly. Just like spam.
There is no need for an email address of the admin-c.
I disagree, but it's optional and thats great.
Jørgen Hovland wrote:
On 11/11/10 10:21, Frank Gadegast wrote:
But making things mandatory doesn't solve poor design.
??? please explain, dont get it.
You are unable to find the (abuse) contact because you don't know where to look, not that it isn't there because it wasn't mandatory.
The abuse-mailbox-field is not mandatory, and it did not help at all. There are enough records, that have none (even from interested LIRs) or that hide there abuse contacts in remarks or simply think, that normal email-fields are enough, leaving the complainant with a guess, which one is right. So, it needs to be mandatory to have them all in one day. Give people a choice and they will choose to do nothing ;o)
DDoS attacks happen every day, get detected and blocked. Exactly. Just like spam.
.. continues for ever. We just had one last month, that was really enoying. About 1300 machines hammered down a customers site. Our detection blocked them all in about 20 minutes, but the traffic still reached our edge routers and firewalls. This is enoying, because our upstream providers will not block single IPs on their side and we will have to pay the traffic, just to block it straight away. flow-control detected to original IPs (most Sender-IPs where faked), but it did not stop for about 3 weeks until the PCs with a trojan finally got the order from the attacker to do something else. We tried to inform the responsible admins, but only reached about 30% of them. The rest had no email at all or no valid email address or returned with the usual mailbox full or User unknown. Would love to raise this rate.
There is no need for an email address of the admin-c.
I disagree, but it's optional and thats great.
Def right. But this cannot be true for illegal actions ... 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 ====================================================================== Public PGP Key available for frank@powerweb.de
I've been trying to follow this discussion over the last few days and am still a bit confused. We use: "descr: Abuse Contact: abuse@blacknight.ie" And apart from the really dumb we don't have any issue getting abuse reports about our IP blocks .. The problem I'm seeing with this entire thing is: 1 - Lack of a clear definition of what exactly is being impacted in simple English 2 - How / why this is necessary Responsive network operators are responsive Unresponsive ones aren't going to change Mandating a particular contact isn't going to change that .. so I'm having issues understanding what exactly people are hoping to achieve On the privacy side of things - You should be careful which email address(es) you use when setting up / maintaining records. If you insist on using a "private' email address then you'll end up suffering anyway ... I still don't understand why people keep throwing in random comments about greylisting - I can't see what that has got to do with anything and as I already stated it's outside this group's remit to fix people's badly configured mail servers. Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Twitter: http://twitter.com/mneylon PS: Check out our latest offers on domains & hosting: http://domainoffers.me/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
On Thu, Nov 11, 2010 at 13:01, Michele Neylon :: Blacknight <michele@blacknight.ie> wrote:
And apart from the really dumb we don't have any issue getting abuse reports about our IP blocks ..
You can not possibly know if you would get more reports, or reports in a more timely fashion, if there was one single canonical place to grab that information. And that is what the proposal boils down to. Richard
Jørgen Hovland wrote:
On 11/10/10 17:42, Frank Gadegast wrote:
I simply want ONE clearly defined contact instead of the messy whois we currentyl have.
But making things mandatory doesn't solve poor design.
??? please explain, dont get it.
Not at all. We report all spam our customers receive.
My ideas about this is probably a bit drastic, but I usually never report spam unless I know the ISP/system because it doesn't make any sense. We do however block it (the spam, not the ISP). It doesn't give us any benefits to report it. We get paid to filter spam. If I reported it the spam would stop. That's bad for business.
You should report all spam. Most good working ISPs are very happy to be informed, when one of their dialin customer has a trojan installed. We also get a lot of feedback from end users, that they fixed the security hole of their housing server, after we informed them.
All password-checking, Why are you reporting that? We have things like that constantly 24/7. In a perfect world, your system should be designed to filter this instead.
Surely we block them also, but we report this, to that the end customer is informed about the trojan hes running, or his ISP is informed. Every day, we stop a couple of hundred botted PCs and servers world-wide.
sniffing I'm not sure if I understand what this means, but you would probably spend your time changing passwords instead of complaining that somebody stole them. Nevertheless, this would be a case for law enforcement if it's so important.
We detect network sniffing BEFORE it actually steals passwords, by monitoring the MAC-addresses in our network.
and DDoS-Attacks
Seriously. The 90s just called. They want you back.
???? DDoS attacks happen every day, get detected and blocked. We use advanced flow-control to detect this traffic and complain to the ISPs this traffic is really coming from. It helps a lot. Cannot see the 90er here. Not telling anybody about his security holes because of lazyness or not enough knowledge is 80th ... BTW: your mailserver does not read our SPF-records right and denies mail from us ...
I think people often mix contact information with abuse contact information. Sometimes it's the same, sometimes not. Some people don't understand the difference and some people don't care and mail everyone anyway. This is where the database design/language perhaps could be improved. Contact information is to me more important than abuse contact information because it lets me get in touch with the legal entity.
Legal issues are comunicated still via paper (and have to) or fax or phone (for the first contact). There is no need for an email address of the admin-c. Simple leave too email address via whois: routing and abuse
Remember that a complaint is just a message saying you are unhappy with something. You can never expect anyone to reply or even do anything about it, and they have their fully right to do so.
Well, I see all the mails coming back and we surely store statistics about any IP causing abuse. And we see how many of those get fixed, so a lot of people are happy about reports (I even know this from talks to major German ISPs, they all have a working abuse department and all really DO something these days). 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 ====================================================================== Public PGP Key available for frank@powerweb.de -- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On Wednesday 10 November 2010 14:58:52 Tobias Knecht wrote:
Am 10.11.2010 13:49, schrieb Marco Hogewoning:
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
And how anybody could stop publishing this kind of info in remark fields?
Yups, +1...we can discard the abuse-mailbox field but not the remarks. That's why I suggested to get the statistics done again. Most likely the majority of the objects are still covered with a remarks line and at least that is better than nothing.
Don't get me wrong. I do not want to delete data before there is a IRT. Since the IRT will be mandatory, RIPE is able to push things faster. Contact people, ask them to update, ...
This will take some time. And there is no reason to say, that we will delete the existing abuse-mailbox attributes not before an IRT is setup. There is no reason not to change "end of 2012" into "end of 2013"
The point is, that this discussion is going on for more than 7 years now and there is still no sufficient solution.
I agree with Tobias point on this. From what I read in the proposal I didn't understand that anything will be deleted, or any current information get lost. It is just a direction, that in the long run will result in publishing abuse contacts in a sigle well defined way.
1) Poor data quality regarding points of contact 2) The fact that there are multiple places people store this info
Having said this, of course the proposal addresses the point no2. For the data quality a first step is the 2010-09 proposal from what I understand. Kostas
Thanks,
Tobias
abusix.org
I agree with Tobias point on this. From what I read in the proposal I didn't understand that anything will be deleted, or any current information get lost. It is just a direction, that in the long run will result in publishing abuse contacts in a sigle well defined way.
Well as you can make sure new objects can't contain abuse-mailbox, you can't easily prevent them from using remarks. So it comes down to education. Educating the maintainers will a hard task, but might be achievable. Educating the users is much harder, this was the problem back in 2007 and it's still the case. This proposal doesn't change anything on that point.
1) Poor data quality regarding points of contact 2) The fact that there are multiple places people store this info
Having said this, of course the proposal addresses the point no2. For the data quality a first step is the 2010-09 proposal from what I understand.
Yups, but as these are 2 seperate proposals so no guarantee they both make it and if they do still you run the risk that 008 will lower the data quality that 009 is trying to fix and the net result might be things stay the same. What we need is education, you want people to think about it and start using IRT voluntarily. Kills two birds with one stone, when it's there it's good and people are likely to do what you want. If it isn't there you can always try and resort to other means to find a contact And at the same time you want to make this mechanism clear to the people using the database. And maybe create an API that makes this available and try to persuade people to start using them. It's easy to force maintainers to create an IRT, but it won't get you anywhere when people don't use it. All you get is a load of extra objects with no guarantee the data is of any quality or that the people behind it (if any) will respond and do the right thing. But I am on repeat right now. Groet, MarcoH (no hats)
On 10 nov 2010, at 12:05, Kostas Zorbadelos wrote:
On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004:
- number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
Also have a look at my and Leo's response from yesterday. From the discussion I get there are 2 problems: 1) Poor data quality regarding points of contact 2) The fact that there are multiple places people store this info This is about 2010-008, and to quote the summary:
"This is a proposal to introduce a mandatory reference to irt objects in the inetnum, inet6num and aut-num objects in the RIPE Database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact and helps reporting institutions to find the correct abuse contact information more easily."
This proposal clearly addresses problem number 2 and says nothing about 1. The point I am trying to make is that although the data quality might be poor, at least it's there. You shouldn't think easily about destroying it and as Sander indicates, migrating it might be hard. Further a migration of that data will keep the errors, so you end up with the same quality data. The only difference is, it is in one place. As Leo said yesterday. At the moment, if you encounter an IRT, this is somewhat an indication those guys (or gals) take it seriously and so you can expect the data to be correct and the people behind it responsive. To a certain point the same goes for the abuse-mailbox attribute. The single that people actually added this optional attribute means at least the spent some time thinking about it. Or the other way around, if you don't want to be found you make sure to hide. Most contact fiels are optional so that is not as hard as it seems and the archives of this list contain multiple examples. Now it may seem "a good thing [tm]" go make some or all of these fiels mandatory. But this is won't give any assurance that it's quality data. In fact as an argument against this proposal one might state that this has the risk of lowering the data quality. In the current situation if it's there, it's there because somebody did care. If this one makes it, it's there because it has to be. If you pickup a broom and start sweeping the floor because you find it dirty and want things clean, it's likely you do a good job. Otherwise it would be a waste of your time and effort. In contrast, if I stick a broom in your hands and _tell_ you to sweep the floor, chances are you don't want to and do a poor job with the dirt ending under the carpet instead of in the bin where it belongs. The fact that another proposal tries to fix the quality problem does not change this argument, that's another discussion. This one addresses the place issue and I personally think there is a risk this is harmful for the data quality as it currently is. Groet, MarcoH
First of all, thank you for your great feedback.
On Wednesday 10 November 2010 12:57:31 Marco Hogewoning wrote:
On 10 nov 2010, at 11:30, Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Be careful of what you wish for, maybe somebody can produce the same stats as I did back in 2004:
- number of inet(6)num covered by IRT - number of inet(6)num covered by abuse-mailbox attributes - Number of inet(6)num containing a remarks field with the words 'complaint' or 'abuse' in it
Creating a 'single point' makes it implicit that others should disappear and you might throw away a load of data and you don't know what you will get back for it.
I am missing your point here. These might be a lot of garbage data. What is wrong about have ONE consistent way to publish abuse contacts? Don't you find this "A Good Thing"?
Also have a look at my and Leo's response from yesterday. From the discussion I get there are 2 problems:
1) Poor data quality regarding points of contact 2) The fact that there are multiple places people store this info
This is about 2010-008, and to quote the summary:
"This is a proposal to introduce a mandatory reference to irt objects in the inetnum, inet6num and aut-num objects in the RIPE Database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact and helps reporting institutions to find the correct abuse contact information more easily."
This proposal clearly addresses problem number 2 and says nothing about 1.
Right. Because number 1 is clearly an AA-WG proposal and point 2 is more a general thing. It would not make sense to put them all together and leave out data accuracy of other part of the whois database.
The point I am trying to make is that although the data quality might be poor, at least it's there. You shouldn't think easily about destroying it and as Sander indicates, migrating it might be hard. Further a migration of that data will keep the errors, so you end up with the same quality data. The only difference is, it is in one place.
Which would be positive and would solve problem number 1, the main intention of this proposal.
As Leo said yesterday. At the moment, if you encounter an IRT, this is somewhat an indication those guys (or gals) take it seriously and so you can expect the data to be correct and the people behind it responsive. To a certain point the same goes for the abuse-mailbox attribute. The single that people actually added this optional attribute means at least the spent some time thinking about it.
I disagree here. We see loads of wrong addresses in the abuse-mailbox attributes. We do not see loads of them in IRT, because 280 IRT objects do not give us a huge data base. And again, you can not judge "only" on the fact, that something is existing or not. We see as well loads of abuse@ addresses being published in abuse-mailbox attributes blocking incoming spam reports because the filter says "This is spam!". In my opinion and I have seen other people here suggesting the same things, if we are thinking about reputation, we have to think about several levels of reputation. If the IRT object would be mandatory: We could differentiate between networks having an IRT Object in place and the networks that do not have them in place. --> Policy Ignorant In the next level we could differentiate if the information is accurate and if it is not, RIPE would have the chance to ask for corrections. If they do not want to correct the wrong entries, we could say Unresponsive. And so on ... All this would give us a much better reputation.
Or the other way around, if you don't want to be found you make sure to hide. Most contact fiels are optional so that is not as hard as it seems and the archives of this list contain multiple examples.
Now it may seem "a good thing [tm]" go make some or all of these fiels mandatory. But this is won't give any assurance that it's quality data.
Full Ack, but not part of this proposal.
In fact as an argument against this proposal one might state that this has the risk of lowering the data quality. In the current situation if it's there, it's there because somebody did care. If this one makes it, it's there because it has to be.
If you pickup a broom and start sweeping the floor because you find it dirty and want things clean, it's likely you do a good job. Otherwise it would be a waste of your time and effort. In contrast, if I stick a broom in your hands and _tell_ you to sweep the floor, chances are you don't want to and do a poor job with the dirt ending under the carpet instead of in the bin where it belongs.
Seeing that it is dirty does not mean I like to clean up. And on the other hand if you are a really picky person and ask me to clean up does not mean that I am doing a bad job. It probably tells me only, that I should do my job better or different. But as long as I can not see the dirt I will not be able to decide if I need to clean up.
The fact that another proposal tries to fix the quality problem does not change this argument, that's another discussion. This one addresses the place issue and I personally think there is a risk this is harmful for the data quality as it currently is.
I do not get the part with the data quality? You said before:
Further a migration of that data will keep the errors, so you end up with the same quality data. The only difference is, it is in one place.
So where is the change for quality of data? You are talking about the quality of work done behind the mandatory object, but not about the data quality. I would go that far and say, making the IRT Object mandatory will improve data quality, because people caring about abuse, but forgot to update the whois data, will correct it and keep it up2date more easily because they have to change only one IRT object and not the remark or abuse-mailbox attribute in 1234 handles. Thanks again for your feedback, Thanks, Tobias abusix.org
As Leo said yesterday. At the moment, if you encounter an IRT, this is somewhat an indication those guys (or gals) take it seriously and so you can expect the data to be correct and the people behind it responsive. To a certain point the same goes for the abuse-mailbox attribute. The single that people actually added this optional attribute means at least the spent some time thinking about it.
I disagree here. We see loads of wrong addresses in the abuse-mailbox attributes. We do not see loads of them in IRT, because 280 IRT objects do not give us a huge data base.
And again, you can not judge "only" on the fact, that something is existing or not. We see as well loads of abuse@ addresses being published in abuse-mailbox attributes blocking incoming spam reports because the filter says "This is spam!".
In my opinion and I have seen other people here suggesting the same things, if we are thinking about reputation, we have to think about several levels of reputation.
If the IRT object would be mandatory:
We could differentiate between networks having an IRT Object in place and the networks that do not have them in place. --> Policy Ignorant
That's about the same as it is now...policy ignorant or uneducated. Insert Hanlon's razor here. So this proposal doesn't change a thing. Groet, MarcoH
Am 10.11.2010 15:06, schrieb Marco Hogewoning:
As Leo said yesterday. At the moment, if you encounter an IRT, this is somewhat an indication those guys (or gals) take it seriously and so you can expect the data to be correct and the people behind it responsive. To a certain point the same goes for the abuse-mailbox attribute. The single that people actually added this optional attribute means at least the spent some time thinking about it.
I disagree here. We see loads of wrong addresses in the abuse-mailbox attributes. We do not see loads of them in IRT, because 280 IRT objects do not give us a huge data base.
And again, you can not judge "only" on the fact, that something is existing or not. We see as well loads of abuse@ addresses being published in abuse-mailbox attributes blocking incoming spam reports because the filter says "This is spam!".
In my opinion and I have seen other people here suggesting the same things, if we are thinking about reputation, we have to think about several levels of reputation.
If the IRT object would be mandatory:
We could differentiate between networks having an IRT Object in place and the networks that do not have them in place. --> Policy Ignorant
That's about the same as it is now...policy ignorant or uneducated. Insert Hanlon's razor here. So this proposal doesn't change a thing.
Imho wrong. It takes a away confusion. One mandatory place for abuse contact information. That is it. Nothing more, nothing less. That is the main intention of this proposal. Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address. We will never be able to judge the quality of abuse handling work by the existence or non-existence of an object. Thanks, Tobias abusix.org
One mandatory place for abuse contact information. That is it. Nothing more, nothing less.
Unless you migrate or delete data that won't be the case, you still have it littered all over the place.
Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address.
Again, this proposal has the risk of lowering data quality and people should be aware of that. Anyway, you and I agree that's clear and lucky this is a consensus model so I will stop here. Pointless to keep reposting the same arguments over and over... Groet, MarcoH (still no hat, getting cold)
On Wednesday 10 November 2010 16:18:36 Marco Hogewoning wrote:
One mandatory place for abuse contact information. That is it. Nothing more, nothing less.
Unless you migrate or delete data that won't be the case, you still have it littered all over the place.
You can't migrate all data on a D-day. This will happen over time and the proposal I think addresses this by making the attribute mandatory.
Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address.
Again, this proposal has the risk of lowering data quality and people should be aware of that.
I am not sure I follow you. Of course we can say more on the subject in person, over dinner or drinks, on the coming meeting in Rome :) Kostas
Hi Tobias, On Nov 10, 2010, at 6:13 AM, Tobias Knecht wrote: […]
Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address.
We will never be able to judge the quality of abuse handling work by the existence or non-existence of an object.
I must not have written sufficiently clearly as you appear to have misunderstood me. I am not arguing that you can judge the quality of abuse handling by the presence or absence of the appropriate information in the database. I am arguing that its presence can help you judge the willingness of a network operators to take the reports seriously. I see the problem as a social one: many people do not want to receive reports or investigate them if they do. Your proposal would make it mandatory for people to publish abuse contact information but would do nothing to actually make people take the reports seriously. As such, I do not see it as significant element in making things better. Instead, I see it as a way of making lots of people do some extra administration that is unlikely to achieve anything significant. Making things better will require the people running the networks to *want* to make things better. Unless you can come up with a proposal to change people's minds about taking abuse reports seriously I don't think this proposal can add any significant value. I suggest starting with solving the social element before moving on to a piece of mandatory mass administration exercise. Regards, Leo Vegoda
Leo Vegoda wrote:
Hi Tobias,
Hi Leo,
On Nov 10, 2010, at 6:13 AM, Tobias Knecht wrote:
[…]
Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address.
We will never be able to judge the quality of abuse handling work by the existence or non-existence of an object.
I must not have written sufficiently clearly as you appear to have misunderstood me. I am not arguing that you can judge the quality of abuse handling by the presence or absence of the appropriate information in the database. I am arguing that its presence can help you judge the willingness of a network operators to take the reports seriously.
Only if you make it not mandatory. But not making it mandatory stops you from having a contact for every IP, and that will keep the chaos we currently have. If there is no IRT object, you will still look through the whois, if there is another contact, and those whois lookups are restricted. And detecting the quality by the absence of an IRT object does not work anyway, because every member could decide to keep the remarks or the abuse-mailbox-field like it is. It just says nothing, if a member can decide not to have an IRT object, so it HAS to be mandytory anyway. And you cannot prove the reachability of this address, if its not mandatory, making the 09 proposal impossible, what is the logical next step. You can check, if the members are taking reports seriously, much better, if there is an email coming back after complaining, but you need a working address for that first !
I see the problem as a social one: many people do not want to receive reports or investigate them if they do.
So they will probably send them to /dev/null and there will be no response. But who cares ? I dont. As long as I can say: "the member got my complaint to the address he published". Or they (if they are really eval :o) will setup a ticket system AND respond to RIPEs test mails. But then you finally can detect the following: spam rates usually drop for ranges, where the member IS taking care. This will not happen for spammer friendly or lazy admins. And that would make things pretty clear.
Your proposal would make it mandatory for people to publish abuse contact information but would do nothing to actually make people take the reports seriously. As such, I do not see it as significant element in making things better. Instead, I see it as a way of making lots of people do some extra administration that is unlikely to achieve anything significant.
Making things better will require the people running the networks to *want* to make things better. Unless you can come up with a proposal to change people's minds about taking abuse reports seriously I don't think this proposal can add any significant value. I suggest starting with solving the social element before moving on to a piece of mandatory mass administration exercise.
I personally do not care, if I have more work in publishing correct abuse data, if there is the chance to delivered reports more accurate and if there is the possibility the detect good from "not-so-good" admins. I will have to invest much less work for the publishing then to program our whois parsers and check a lot of things manually. This proposal will SAVE me at lot of time ! I personally do not like to send reports to non-responsible persons, that another way of spamming. With that proposal I can be sure, that I got the responsible one, and thats a big step forward ... Kind regards, Frank
Regards,
Leo Vegoda
-- 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 ======================================================================
Dear Colleagues, I have followed the whole of this thread. There have been several questions put to the RIPE NCC about what we may or may not be able to do. Also many technical and implementation details have been touched on. I think it may be helpful if I try to address some of these issues, in no particular order. Apologies for the length of the email. There have been many assumption that this issue only concerns members who have an LIR Portal account. This is not the case for end user assignments. Any solution has to cover all resource Holders who may not have access to announcements, tools or features of the LIR Portal. There have also been a few references to making judgements based on the resource Holder using a ticketing system. Again many end users with a single PI prefix may be unlikely to use ticketing systems, but may be very active to resolve any complaints about their address space. The RIPE NCC puts a lot of effort into cooperation with Law Enforcement Agencies (LEA) and other official organisations. Many LEAs in the RIPE region and also worldwide have specialist cyber crime units who are becoming very knowledgeable about Internet resource policies and procedures. I don't think these are the people you need to worry about as far as getting information out about new policies. In many cases it is some of the resource Holders who maintain data that has not changed for years that need advising of new policies. Also the public are increasingly finding the RIPE Database and these people will still grab every email address they see and do a blanket mailing to all addresses. Even if the information was clear they are usually angry and still think sending more emails is good. The RIPE NCC only knows the IP addresses where queries to the RIPE Database come from and what they queried for. We have no information about what type of network it is (fixed, dynamic or whatever) so there is no point trying to guess any numbers. We do know we average 80 queries per second and the IP addresses making the queries are global, not only RIPE region addresses. Other than that we can say nothing about who is making these queries or why. There is an assumption that making a policy will force resource Holders to change data in a short period of time (2 or 3 years). There have been many policy, business rule, security and syntax changes over the last 10 years. Some of the earliest are still not complete. We dropped reference by name in 2001. Some objects still reference the dummy NIC Handles we created to replace the person names. Many objects created in 2004/5 for the Early Registration Transfer were 'locked' with auto-generated MNTNER objects and are still locked. Last year we added MNTNER objects to un-maintained DOMAIN objects. We had to create dummy MNTNER objects for some and they still reference the dummy maintainers. Resource Holder's data does not change quickly. But that does not mean the operational data is wrong or not used. It may be that the networks were set up many years ago, everything still works fine and no one needs to change this data. For the same reasons as above, making a mandatory reference to an IRT object will not affect data that the resource Holder never changes. At some point the RIPE NCC may have to auto generate dummy IRT objects with an abuse-mailbox email address like <unread@ripe.net> to ensure all data in the database complies with current syntax rules. The RIPE NCC can not delete any information currently stored in "remarks:" attributes. This is for the same reason the Abuse Finder tool cannot return any information from "remarks:" and we cannot do any bulk updates to transfer abuse contacts from remarks into IRT objects. We cannot write software to 'understand' remarks. We don't even know what language the remark may be in. Then we can't distinguish between: remarks: use this address for spam reports helpdesk@lir.net remarks: don't send abuse reports to helpdesk@lir.net use admin@lir.net remarks: any complaints sent to helpdesk@lir.net will be ignored At some point the RIPE NCC can auto generate IRT objects and add the email address from existing "abuse-mailbox:" attributes in other objects. Then make the appropriate references to this IRT object and delete the old "abuse-mailbox:" attributes. No data will be lost doing this and the new IRT object will cover the same address space covered by the old "abuse-mailbox:" attribute. Then syntax changes can be applied to only allow "abuse-mailbox:" attribute in IRT object. It has been suggested the RIPE NCC can regularly check/verify abuse contact email addresses. It is very easy to set a filter on incoming emails to allow any mail @ripe.net to pass and block all others. So the fact that a resource Holder receives our email is no guarantee they will receive yours. For those not familiar with the database structure, note that address space is hierarchical. There are just over 3 million INETNUM objects for PA assignments. These all relate to the allocations made to about 7000 members. Each member may have several allocations. From the point of view of administrative work load, adding IRT references to the few thousand members allocation objects achieves the same result as adding a reference to each of the 3 million objects, but is much easier to manage. The default query for any address already searches up the hierarchy for the IRT reference and this object is returned as part of the query result. Queries returning IRT objects are not limited in any way. If this is to be mandatory, any update to one of the INETNUM objects lower down in the hierarchy can be rejected if the allocation object does not have the mandatory reference. If you want it to be advisory, the update can generate warnings if the reference is not there. The overall result is the same as having 3 million references, but the work required to implement and maintain is much less. Calculations of address space coverage by IRT objects is complex because of the hierarchical nature. It is not just a count of the number of INET(6)NUM objects that it is referenced in directly. Those objects have more specifics which may or may not fully utilise that address range. The last time we attempted this calculation was about two years ago. Then there were about 100 IRT objects, not all of which contained the optional "abuse-mailbox:" attribute. The address space covered by those IRT objects with an "abuse-mailbox:" attribute was about 2% of the total assigned address space from members allocations (PA) and direct end user assignments (PI). If abuse emails are located in one place the RIPE NCC Abuse Finder tool can do direct database lookups at SQL level, bypassing the normal query interface. This is much faster and provides real time responses. With a published API you can write your own scripts to use this tool. Downloadable lists are yesterdays data, but we can look at providing such lists if required. Regards Denis Walker Business Analyst RIPE NCC Database Group
Denis Walker wrote:
Dear Colleagues,
Dear Dennis,
There have been many assumption that this issue only concerns members who have an LIR Portal account. This is not the case for end user assignments. Any solution has to cover all resource Holders who may not have access to announcements, tools or features of the LIR Portal. There have also been a few references to making judgements based on the resource Holder using a ticketing system. Again many end users with a single PI prefix may be unlikely to use ticketing systems, but may be very active to resolve any complaints about their address space.
RIPE NCC could simply mail them to include an IRT object.
Even if the information was clear they are usually angry and still think sending more emails is good.
Just asking why other mail addresses are still visible to the public ? Most domain registry give the owner to opportunity to hide their email addresses, like DENIC does by default. Contact email addresses are only needed for routing issues or abuse problems (my opinion, but their might me other reasons Im not aware of). Simple hide the email of the owner to lower email harvesting. Hiding some personal data would be correct according to some local laws anyway.
The RIPE NCC only knows the IP addresses where queries to the RIPE Database come from and what they queried for. We have no information about what type of network it is (fixed, dynamic or whatever) so there is no point trying to guess any numbers. We do know we average 80 queries per second and the IP addresses making the queries are global, not only RIPE region addresses. Other than that we can say nothing about who is making these queries or why.
Simply compare the IPs you see to dynamic IP list like the PBL from spamhaus.org
There is an assumption that making a policy will force resource Holders to change data in a short period of time (2 or 3 years). There have been many policy, business rule, security and syntax changes over the last 10 years. Some of the earliest are still not complete. We dropped reference
This could be enforced, when RIPE NCC does not allow object changes before the LIR fixes wrong or missing syntax of all other objects.
The RIPE NCC can not delete any information currently stored in "remarks:" attributes. This is for the same reason the Abuse Finder tool
But it could present an easy way to fix them via the portal.
cannot return any information from "remarks:" and we cannot do any bulk updates to transfer abuse contacts from remarks into IRT objects. We cannot write software to 'understand' remarks. We don't even know what
Why not ? Anybody who has to parse remarks for abuse contacts has to do it already ...
language the remark may be in. Then we can't distinguish between: remarks: use this address for spam reports helpdesk@lir.net remarks: don't send abuse reports to helpdesk@lir.net use admin@lir.net remarks: any complaints sent to helpdesk@lir.net will be ignored
Think about the following: - the LIR logs in and the portal presents him all object without an IRT link and tells him about the needed changes - when updating the object, the LIR is presented with a list of his current IRT objects and he can select one or more - the portal also presents him an editable field showing the remarks when they include an @ sign or/and present an checkbox to simple delete them all together The LIR can then simply copy-paste the text he likes or can select to delete remakrs all together, select the IRT object he likes and click "Update", what brings him to the next object he needs to fix. Updates could be completed in a couple of hours, even if you have hundreds of INETNUM object, if the interface is comfortable enough. I bet that big LIRs do not use the portal anyway, and update the RIPE DB with their own database interfaces, it should be not to complicated to updated thoses interfaces and program an general and automatic update procedure for them.
At some point the RIPE NCC can auto generate IRT objects and add the email address from existing "abuse-mailbox:" attributes in other objects. Then make the appropriate references to this IRT object and delete the old "abuse-mailbox:" attributes. No data will be lost doing this and the new IRT object will cover the same address space covered by the old "abuse-mailbox:" attribute. Then syntax changes can be applied to only allow "abuse-mailbox:" attribute in IRT object.
Even easier ...
It has been suggested the RIPE NCC can regularly check/verify abuse contact email addresses. It is very easy to set a filter on incoming emails to allow any mail @ripe.net to pass and block all others. So the fact that a resource Holder receives our email is no guarantee they will receive yours.
Its not interesting, if the abuse contact really receives or even reads an email, more interesting is, that he supplies everybody with an abuse address he "wants" to have email too and that it exists. First: abuse reports will not go to contacts, that have nothing to with abuse handling anymore Second: the owner cannot say, that he did not know about the problems he caused, because he received the mail via his own mail servers. Its not the problem of the sender, if he decides to delete or not to read them.
For those not familiar with the database structure, note that address space is hierarchical. There are just over 3 million INETNUM objects for PA assignments. These all relate to the allocations made to about 7000 members. Each member may have several allocations. From the point of view of administrative work load, adding IRT references to the few thousand members allocation objects achieves the same result as adding a reference to each of the 3 million objects, but is much easier to manage. The default query for any address already searches up the
If there is no IRT object for a specific INETNUM, simply present the next higher IRT object. This is what people are doing anyway, if there is no email address at all for the specific INETNUM (f.e. spamcop does this).
If abuse emails are located in one place the RIPE NCC Abuse Finder tool can do direct database lookups at SQL level, bypassing the normal query interface. This is much faster and provides real time responses. With a published API you can write your own scripts to use this tool. Downloadable lists are yesterdays data, but we can look at providing such lists if required.
Im still voting for the list, but SQL is nice too ... Kind regards, Frank
Regards Denis Walker Business Analyst RIPE NCC Database Group
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On Thu, Nov 11, 2010 at 09:00:54AM +0100, Frank Gadegast wrote: Hi
Its not interesting, if the abuse contact really receives or even reads an email, more interesting is, that he supplies everybody with an abuse address he "wants" to have email too and that it exists. First: abuse reports will not go to contacts, that have nothing to with abuse handling anymore Second: the owner cannot say, that he did not know about the problems he caused, because he received the mail via his own mail servers. Its not the problem of the sender, if he decides to
What brings you to that conclusion? Is there any policy which prohibit using somebody else's mail servers? ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Frank, On 10 Nov 2010, at 9:12, Frank Gadegast wrote: [...]
Imho you and Leo Vegoda are mixing up the data quality and the work quality. Data quality judges the quality and the accuracy of the data given in the object and has absolutely nothing to do with the abuse work done behind the email address.
We will never be able to judge the quality of abuse handling work by the existence or non-existence of an object.
I must not have written sufficiently clearly as you appear to have misunderstood me. I am not arguing that you can judge the quality of abuse handling by the presence or absence of the appropriate information in the database. I am arguing that its presence can help you judge the willingness of a network operators to take the reports seriously.
Only if you make it not mandatory.
Yes, I'm describing what we have now.
But not making it mandatory stops you from having a contact for every IP, and that will keep the chaos we currently have. If there is no IRT object, you will still look through the whois, if there is another contact, and those whois lookups are restricted.
And detecting the quality by the absence of an IRT object does not work anyway, because every member could decide to keep the remarks or the abuse-mailbox-field like it is. It just says nothing, if a member can decide not to have an IRT object, so it HAS to be mandytory anyway.
I disagree. Right now, creating an IRT object tells you that people know what they are doing because they need to jump through hoops. [...]
I see the problem as a social one: many people do not want to receive reports or investigate them if they do.
So they will probably send them to /dev/null and there will be no response. But who cares ? I dont. As long as I can say: "the member got my complaint to the address he published".
I do not understand in one automatic system sending a message and another automatic system deleting it without a human intervening at any point. Maybe I am missing something but that just seems like a waste to me. [...]
Your proposal would make it mandatory for people to publish abuse contact information but would do nothing to actually make people take the reports seriously. As such, I do not see it as significant element in making things better. Instead, I see it as a way of making lots of people do some extra administration that is unlikely to achieve anything significant.
Making things better will require the people running the networks to *want* to make things better. Unless you can come up with a proposal to change people's minds about taking abuse reports seriously I don't think this proposal can add any significant value. I suggest starting with solving the social element before moving on to a piece of mandatory mass administration exercise.
I personally do not care, if I have more work in publishing correct abuse data, if there is the chance to delivered reports more accurate and if there is the possibility the detect good from "not-so-good" admins.
I will have to invest much less work for the publishing then to program our whois parsers and check a lot of things manually.
This proposal will SAVE me at lot of time !
I personally do not like to send reports to non-responsible persons, that another way of spamming. With that proposal I can be sure, that I got the responsible one, and thats a big step forward ...
I think you are conflating two things: a single syntax for publishing abuse contact information and making it mandatory. You can alter the database syntax rules to have a just one official way of publishing abuse contact information but that won't stop people putting data in comments, too. And it certainly won't stop them updating the comments and not the (possibly bogus) address any the official publication place. Having automated systems send each other e-mails that are never read or acted upon does not make sense. For that reason, I would suggest work goes in to efforts to explain why it is bad to host abusive systems rather than into lots of make-work that will have little actual impact. Regards, Leo
Leo Vegoda wrote:
Hi Frank,
Hi,
And detecting the quality by the absence of an IRT object does not work anyway, because every member could decide to keep the remarks or the abuse-mailbox-field like it is. It just says nothing, if a member can decide not to have an IRT object, so it HAS to be mandytory anyway.
I disagree. Right now, creating an IRT object tells you that people know what they are doing because they need to jump through hoops.
No, it tells you nothing about the intention. I know, that spammers do everything to stay undetected, their records, objects, domains, SPF-records, reverse-mappings and everything else, what could be used to detect them, is often of much better quality then regular and big IPs ;o)
I do not understand in one automatic system sending a message and another automatic system deleting it without a human intervening at any point. Maybe I am missing something but that just seems like a waste to me.
Not at all, they cannot say, that they did not know about the problem anymore. This is very important for any legal action or even complaining to their upstream provider or LIR ... For me its also a real argument to my customers, why I block some ranges, because I can prove, that they were informed and still did not do anything. I can simply call them "spam-friendly provider" ;o)
This proposal will SAVE me at lot of time !
I personally do not like to send reports to non-responsible persons, that another way of spamming. With that proposal I can be sure, that I got the responsible one, and thats a big step forward ...
I think you are conflating two things: a single syntax for publishing abuse contact information and making it mandatory.
You can alter the database syntax rules to have a just one official way of publishing abuse contact information but that won't stop people putting data in comments, too. And it certainly won't stop them updating the comments and not the (possibly bogus) address any the official publication place.
Having automated systems send each other e-mails that are never read or acted upon does not make sense. For that reason, I would suggest work goes in to efforts to explain why it is bad to host abusive systems rather than into lots of make-work that will have little actual impact.
See above. Kind regards, Frank
Regards,
Leo
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
Leo Vegoda wrote:
Hi Frank,
Hi,
And detecting the quality by the absence of an IRT object does not work anyway, because every member could decide to keep the remarks or the abuse-mailbox-field like it is. It just says nothing, if a member can decide not to have an IRT object, so it HAS to be mandytory anyway.
I disagree. Right now, creating an IRT object tells you that people know what they are doing because they need to jump through hoops.
No, it tells you nothing about the intention. I know, that spammers do everything to stay undetected, their records, objects, domains, SPF-records, reverse-mappings and everything else, what could be used to detect them, is often of much better quality then regular and big IPs ;o)
I do not understand in one automatic system sending a message and another automatic system deleting it without a human intervening at any point. Maybe I am missing something but that just seems like a waste to me.
Not at all, they cannot say, that they did not know about the problem anymore. This is very important for any legal action or even complaining to their upstream provider or LIR ... For me its also a real argument to my customers, why I block some ranges, because I can prove, that they were informed and still did not do anything. I can simply call them "spam-friendly provider" ;o)
This proposal will SAVE me at lot of time !
I personally do not like to send reports to non-responsible persons, that another way of spamming. With that proposal I can be sure, that I got the responsible one, and thats a big step forward ...
I think you are conflating two things: a single syntax for publishing abuse contact information and making it mandatory.
You can alter the database syntax rules to have a just one official way of publishing abuse contact information but that won't stop people putting data in comments, too. And it certainly won't stop them updating the comments and not the (possibly bogus) address any the official publication place.
Having automated systems send each other e-mails that are never read or acted upon does not make sense. For that reason, I would suggest work goes in to efforts to explain why it is bad to host abusive systems rather than into lots of make-work that will have little actual impact.
See above. Kind regards, Frank
Regards,
Leo
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
Sander Steffann wrote:
That being said, I still think a single canonical place to store abuse handling information is A Very Good Thing.
+1
Sander
+1 Same for us, we are happy as every range gets one abuse email contact and we can query the whois server without limits to get this information. Still likes to add, that I love to have a downloadable file with two rows, one row for the range, one for the abuse email address which should be available to download for all RIPE members via ftp or http(s). APIs for RIPEs abuse-tool or similar things make abuse reporting unnecessary complicated and the load to RIPEs whois server could be dramatically reduced. There is no risk to produce such a list, because the abuse email addresses will be mandatory and published without limits anyway. Tobias: could you please add this to the next version of the proposal ? 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 ====================================================================== Public PGP Key available for frank@powerweb.de
On Wed, Nov 10, 2010 at 12:08, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
There is no risk to produce such a list, because the abuse email addresses will be mandatory and published without limits anyway.
It would make harvesting addresses easier. Still, this might be something worth considering. Richard
Am 10.11.2010 12:21, schrieb Richard Hartmann:
On Wed, Nov 10, 2010 at 12:08, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
There is no risk to produce such a list, because the abuse email addresses will be mandatory and published without limits anyway.
It would make harvesting addresses easier. Still, this might be something worth considering.
Right. I think this is something that should be looked at by the RIPE legal department. Offering any easy access non whois way would be nice. Thanks, Tobias
Richard Hartmann wrote:
On Wed, Nov 10, 2010 at 12:08, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
There is no risk to produce such a list, because the abuse email addresses will be mandatory and published without limits anyway.
It would make harvesting addresses easier.
How ? It should only be available for members. And harvesting is done anyway via whois ... And there are lots of unlimited webservices that mirror personal whois data, there are also used by harvesters easily. So: these addresses are known to the spammers anyway. A list will not make it worth, even if a member publishes it. BTW: just did run a quick check how much spam we received on our email addresses published via whois compared to others on the same domain. Seems like spammers fear a official abuse contact and do not spam them a lot. Kind regards, Frank
Still, this might be something worth considering.
Richard
-- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
Hello everybody, first of all thank you for all your feedback on this proposal. It is great to see so many people joining and supporting or opposing the policy proposal. Thanks for that again. I think Denis did a great job yesterday bringing up some clarification about some issues. And I have seen that some people are still having a hard time to understand the idea of the proposal and some of them having a hard time to understand the proposal text, So I want to try to give some clarification and I hope I can do it as well as Denis did yesterday. * Why should we use the IRT-Object? - The IRT object is already existing, it is easy to implement for RIPE. - The IRT object underlies no whois server query restrictions. - The IRT object gives more flexibility. It is possible to monitore abuse, even if the inet(6)num is handled by your customer. - The IRT objects intend was similar to the intend of this proposal. - The IRT object is used by APNIC. * Why is an abuse-c a bad idea? Using an abuse-c would link the abuse-c field to already existing role, person, or org objects. Those objects are underlying query restrictions. If for example a person handle (including an abuse-mailbox attribute) is linked to abuse-c and to admin-c, two possibly different abuse-mailbox attributes are in one inetnum. * Why making the IRT Object mandatory? One of the main intentions of this proposal is to keep and make things simple and clean up. By making the IRT Object mandatory, there is a clear and understandable definition. Communicating that the IRT Object is mandatory is much more easy too understand than communication, that the IRT should be used and still having other options (remarks). * The abuse-mailbox attribute will be mandatory in the IRT Object. Why? Abuse departments are also receiving personal emails. Communication between different abuse departments or even automatic mail notification from for example blacklist providers. Offering 2 email addresses makes much sense in this case. "e-mail" attribute for personal communication and the "abuse-mailbox attribute for complaints. * How will this proposal clean up? By having a clear and understandable definition all in future created inet(6)nums and aut-nums will have an IRT Object with the abuse-contacts included. There is no need for remark fields or anything else. The already existing mess can be solved by, not letting people create abuse-mailbox attributes in non IRT objects anymore. That will solve the abuse-mailbox problem. I would not migrate these things, I would ask the maintainer as often as necessary to create an IRT Object and delete the abuse-mailbox attributes in all other handles. The problem with remark fields is quit bigger, but will not be a problem as long as the IRT object will be mandatory. Why care about remark fields? If the correct information is published in the IRT object. Nevertheless RIPE could contact maintainers with abuse@ or other keywords in remark fields and ask them to clean up. Another idea was to ask for a cleanup why being logged in the LIR portal. I think RIPE NCC will be able to find a good way. * What other impacts does this proposal have? I do just know about the impacts RIPE told me while working on the proposal and the things Denis Walker explained yesterday. So I hope that Denis can and is allowed to make a more general statement about this proposal in ways of other impacts. What I have seen so far the majority is okay with having a "single" place for abuse contact information. The main purpose is the question if this place should be mandatory or not. Leo Vegoda and Jorgen Hovland mentioned their concerns about the data quality. I can't see these problems coming up. I even see the opposite, having better data quality. But I can not prove Leo and Jorgen wrong, and so can't they. So I would outline this as: "If the IRT object will be made mandatory, data quality will change. Could get better, but could also get worse." So believe what you believe, we can not argue about that. But nevertheless: Is there any other concern or positive feedback about making the IRT Object mandatory? Is there any other concern or positive feedback using the IRT Object? Are there any other concerns or positive feedback? Are there any other questions or suggestions? Please ask yourself the above mentioned questions and let us all know, so we have the chance to explain and find a fair way. Thanks again for the great discussion Tobias abusix.org
Hello everybody, On 11/Nov/10 15:26, Tobias Knecht wrote:
- The IRT object underlies no whois server query restrictions.
Good! (Let me just note that preventing abuse to abuse contacts is a non-issue.)
What I have seen so far the majority is okay with having a "single" place for abuse contact information.
One of my ISPs defined an abuse-mailbox for me. I'm not sure that's good, because if I were a spammer I'd have the opportunity to hide complaints and preserve my reputation. However, what should ISPs do? An interesting idea is to establish *hierarchical abuse reporting*, whereby an abuse report addressed to my ISP's IRT would be forwarded to me, so that I'd be able to fix anything wrong on my side while still being traced. But then, why don't RIPE or IANA have regional or global abuse reporting contacts so as to start that hierarchy right at the top? Such hierarchical abuse reporting could be managed much the same way as Americans do feedback loops.
"If the IRT object will be made mandatory, data quality will change. Could get better, but could also get worse."
In case hierarchical forwarding of abuse reports will be adopted, I would like to test it. Periodic tests, e.g. yearly, coordinated among RIPE, ISPs, and interested end users --those who run mail servers on those IPs-- would result in a documented quality improvement. That is, a statistical quality document that can be consulted by end users for guiding their choice of an ISP or other service.
Are there any other questions or suggestions?
Yes, one. This is not directly related to IRTs, but goes in the direction of automating abuse-report handling, so I re-propose it here. European privacy rules apparently mandate opt-in. However, there is no mechanism to certify such practice. This can be accomplished by notifying a given mail domain whenever its users opt-in any mailing list, newsletter, advertising list, or similar. A signed ack from the relevant mail server would constitute the opt-in certification. Such mechanism would ease automation by making it possible to determine whether an abuse report is legitimate. I've kept the description to a minimum, slightly longer versions are here: http://www.ietf.org/mail-archive/web/domainrep/current/msg00270.html http://www.mail-archive.com/courier-users@lists.sourceforge.net/msg35311.htm... If anyone in this group would be interested in experimenting this, or can direct me to people who would, please speak up. Thanx Ale
On Thu, Nov 11, 2010 at 03:26:23PM +0100, Tobias Knecht wrote: Hi Tobias
But nevertheless:
Is there any other concern or positive feedback about making the IRT Object mandatory?
Is there any other concern or positive feedback using the IRT Object?
Are there any other concerns or positive feedback?
Are there any other questions or suggestions?
Yes. Why not introduce mandatory abuse-mailbox field into inet(6)num and aut-num? - This meet the need for single place for abuse contact information. - The inet(6)num and aut-num has no whois server query restrictions. - The inet(6)num and aut-num are already existing. Syntax change would be probably easy to implement for RIPE NCC. - The non-mandatory IRT object could still be used for mature, well established IRT teams. - Reduced resource consumption: there will be no extra objects in DB (we save some disk space) and there will be no extra references (we save some whois servers' processors time). Both means: we save some money. :) - IRT object still can be used as it is used right now (if LIR want's to monitor abuse, even if the inet(6)num or aut-num is handled by its customer) This is of course not connected with leaving or not abuse-mailbox in person/role/organisation object types. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (16)
-
Alessandro Vesely -
Denis Walker -
Emilio Madaio -
Florian Weimer -
Frank Gadegast -
Frank Gadegast -
James Davis -
Jørgen Hovland -
Kostas Zorbadelos -
Leo Vegoda -
Marco Hogewoning -
Michele Neylon :: Blacknight -
Piotr Strzyzewski -
Richard Hartmann -
Rob Evans -
Sander Steffann -
Tobias Knecht