[anti-abuse-wg] @EXT: RE: working in new version of 2019-04 (Validation of "abuse-mailbox")

 Colleagues

I have just read this whole thread, it took a while (I should get sick more often and spend a day in bed reading emails). I have a few points to make. Some are similar to points already raised but I will reinforce them. I cut out the bits I want to respond to, but sorry I have not included the authors (you will know if it's you).

"If I need to use a web form, which is not standard, for every abuse report that I need to submit, there is no sufficient time in the world to fill all them."
So instead each resource holder must interpret randomly written emails and find any relevant information from within lots of junk.

"ever since the day that RIPE NCC firstpublished an abuse reporting address in the data base, it has, ineffect, injected itself, even if only to a minimal degree, intothe relationship between a network abuse victim and the relevantresource holders that have clear connections to the abuse source"
To be clear, the RIPE NCC is the data controller, not the data content provider. The RIPE NCC does not publish the abuse contacts, they facilitate resource holders to publish them.

"make abuse-c: an optional attribute(basically, unrolling the "mandatory" part of the policy proposal thatintroduced it in the first place)"
As co-author/designer of "abuse-c:" one of the original aims of the "abuse-c:" attribute was to provide one single point of contact for a resource holder's abuse reports. If it is made optional, abuse reports would simply be sent to the "admin-c:", "tech-c:", "notify:", etc email addresses, as they were before. People will simply search the database for any email address associated with the resource holder and spam them all. It won't stop abuse reports being sent 'somewhere'. And once someone has had to go to the trouble of finding a list of email addresses to use for the resource holder who has no "abuse-c:", then they will probably do the same for all reports they send. So those of you who do respond to abuse complaints will find complaints being sent to a whole host of your email addresses from the RIPE Database. We lose the 'keep it in one well defined location' benefit.

"at the very least, RIPE NCC could setup and maintain just a basic review "platform" where the public at largecan at least make it known to all observers which networks are the assholesand which ones aren't."
This would be an excellent way for a network operator to 'take out' their competitors.

"While I would accept Gert's proposal for making abuse-c an optionalattribute, the reason I offered a counter proposal for publishing "astatement to the effect that the network operator does not act onabuse reports" is to add clarity at a high level."
How many operators are going to make such a statement? It would become an invitation to block their traffic. If that was the alternative to any verification then they know if they don't make such a statement there will be no penalty. So just don't make a statement and still ignore the reports.

"i'm more worried about someone using real e-mailaddresses of real unrelated people than the /dev/null or unattendedmailboxes."
Separately to this discussion we need to have a mechanism to say "Remove my email address from this resource", as Google has when someone uses your gmail address as a recovery address. (A service I use on a weekly basis)

"Nice analogy, but when you add the eCommerce Directive into the mix, where a network provider (or hosting provider) is not liable for what their users do, the outcome changes. Only if you have knowledge there might be a possibility for liability, but if you do not accept abuse notices, and therefore do not have knowledge you are not liable. Also note there is no monitoring obligation, but if you do monitor you can gain knowledge and become liable for -everything-."
If you hide behind this type of logic, the EU in particular could easily change the law so that refusal to accept notifications renders you liable as if you had received it. 'Ignorance of the law is no excuse' comes to mind.

">It's amazing that nobody cant propose anything without receiving a shower of all sorts of arguments againstIt's called 'democracy'."
Many of the countries in the RIPE region are not democracies (including the UK now).

Having been on this mailing list for many years, as others have said, this discussion has gone round in circles so many times. It really makes it hard to follow what the general view is. To me there seems to be 2 camps. One camp wants to 'do something' to try to improve the situation. The other camp wants to do nothing for a variety of reasons (not the RIPE NCC's job, gets tangled up with other policies, too much work/time, a burden on those who do the right thing, won't help with those who avoid it, we are engineers not social workers or police). These are the same reasons used against almost every policy proposal on this list. We are in a new decade now. We have to take a more holistic view of the RIPE Database and services around it. I started at the RIPE NCC as a software engineer working on the database. But over time I became involved in almost every aspect of it, including legal, policy, feature design, contracts, etc. I thought the days of demarcation lines went out in the 70s when an engineer thought only about engineering issues. Abuse (in all its forms) is a problem on the internet. Some organisations work hard to tackle it, others ignore it. As a community (of holistic engineers) we need to try things out to reduce abuse. There have been so many negative comments in this thread and so few positive ones. It isn't just LEAs that watch what we do, it's governments as well. If we don't 'try' to reduce abuse, we may find a form of GDPR coming down the line for abuse on the internet. Then every organisation, large and small, will be rushing to their lawyers to ensure they are GDPR(abuse) compliant. Avoiding a little effort now may involve a huge effort later. We are no longer a little group of chatty engineers. We are prominent figures in a global, life critical service. Lets try to be a little more positive and constructive....
cheersdenis
co-chair DB-WG

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20200116/4eb2b3a0/attachment.html>