[arin-ppml] Draft Policy ARIN-2021-7: Make Abuse Contact Useful

[Owen DeLong]

> On Oct 26, 2021, at 15:17 , JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> wrote:
> 
> Hi,
> 
> Unless I misunderstood this proposal, I believe this is the wrong way to go.
> 
> Is this proposal suggesting that the abuse email must not be used anymore and instead a URL for abuse reports enforced?
> 

You are making the same mistake as the previous poster. You are assuming that a URL is a website locator. It is not. It can be an email, a website,
a phone number, a file download, or any of a number of other resource types.

As I read the proposal, the effect would be that administrators receive additional flexibility in how they want to receive abuse reports by being able to
express that desire in terms of a URL.

If you are currently using an abuse POC of abuse at example.com then you would be able to switch to mailto:abuse at example.com and continue as before.

Arguably, staff should automatically convert all ABUSE POC records accordingly as part of the implementation process…
Possible process (just spitballing here as this is operational and not part of the policy):

	T+0	Policy is ratified by BoT
	T+120 days ARIN Staff has the software and training changes ready to go and the final schedule and process are documented and distributed
		arin-announce, nanog, other usual suspects…
	T+120 days ARIN begins accepting ABUSE-URLs as an additional field in WHOIS ORG and RESOURCE records.
	T+150 days ARIN Sends out warning that ABUSE-C will be removed from WHOIS at T+180 days
	T+165 days ARIN sends out second warning
	T+175 days ARIN sends out third warning
	T+178 days ARIN sends out fourth warning
	T+179 days ARIN sends out final warning
	T+180 days, ARIN converts all ABUSE-C items in records that lack an ABUSE-URL entry to ABUSE-URL: mailto:<former abuse-c content>
		ARIN then removes all remaining ABUSE-C fields from WHOIS


> If you look at all the other 4 RIRs, this is totally contrary to the practical experience.
> 

Only if you stick to your above erroneous assumption that an email address expressed in URL form is somehow less valid than an email address in an ABUSE-C field.
> If you enforce abuse to use a form, because each ISP can implement a totally different form format, this disallows automating the abuse reporting process, which is the only way it can be actually useful.
> 
This depends on your definition of useful. From a reporter perspective, perhaps automating the abuse reporting process to minimize the effort required to report abuse is most useful.
From a dealing with the abuse and solving the problem perspective, however, there is some amount of value in having a standardized format for receiving the reports and an ability to insist upon collecting the data needed to actually act on the report.
Allowing resource holders to choose how they wish to receive abuse reports, therefore, may have some utility.
> The problem is not that the abuse mailbox is not useful because it can get spam or something else, the problem is when it is not correctly processed, updated with the right contact, etc., so it must be periodically validated to become useful.
> 
There are multiple problems. Spam and other useless email flooding an abuse mailbox is, in fact, a real problem, so you can’t say that the problem is not that. You may say that’s not the problem that bothers you the most, but that’s a different statement entirely.

There are also situations where incorrect processing is a problem. In many of those cases, it may well be because the needed information is not provided in the emailed report and many such emailed reports do not provide a functional way to request the additional information. There are, of course, other causes for this issue as well.

Certainly stale data in WHOIS is a chronic problem and validation helps, but I don’t see URL validation as being significantly worse than email validation.
> Alternatively, reporting could be done using via email and standard formats such as X-ARF/RFC5965/RFC6650.
> 
That wouldn’t hurt, but even with standardized email formats, there are going to be bad implementations, errors, etc. that result in non-actionable reports.
> APNIC and LACNIC have already implemented my abuse-c policy proposal that enforces the validation of the abuse-mailbox, and the results are awesome.
> 
I’ve heard mixed reviews, but glad you’re happy.
> It reached consensus also in AFRINIC but there is a pending appeal.
> 
It seems anything that happens in AFRINIC these days gets appealed. I wonder if the appeal committee will ever stop churning long enough to actually review any of the appeals that have been stacking up.

Of course, now that the board has chosen to ensure that the appeal committee can’t possibly be independent or fair and is just an extension of the board, I’m not sure what the point is, just let the board ratify or not as the appeal committee has been rejiggered to ensure that they will do whatever the board wants anyway. The level of corruption and disdain for the community and the multistakeholder process displayed by the current AFRINIC board is truly outrageous. Hopefully the next election will see a great deal of new blood seated.
> In the case of RIPE NCC, there is already a validation policy in place. I tried to improve it, but didn’t reached consensus (yet).
> 
Certainly all of the abuse problems in Europe have been completely solved by this, right?

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20211026/6b3f4eb6/attachment.htm>