Ronald,
Can you please stop attacking ideas (such as web forms) implying that they only have malicious use cases.
> I hold them responsible because they obviously
> fail to have in place contractual clauses that would persuasively
> deter this behavior on the part of their customers.
In many cases it is practically impossible to know if your customers are sending legit emails or spam without having people reporting it.
As TLS is used in many cases now, the provider can't look at the network data to see what the customer is sending even on a technical level, disregarding any trust/potential legal issues.
> The provider in question is a perfectly lousy coder and is thus
> unable and/or unwilling to write code to parse emailed abuse
> reports.
Hi, I am actually primarily a software dev and not a network engineer, it is not even close to as easy as you make it out to be.
Sure you can have a regex to extract IP addresses and other messy things like that, but you can't be sure what that address is, it might be your customer, it might be the address they say you attacked, etc.
My point here is that parsing free form text in this way without having a clearly defined structure is far from trivial.
Also please stop assuming bad faith by saying that providers are "unwilling" to do this.
If they could drastically lower the amount of manual work needed here with a bit of code, they absolutely would in almost all cases.
> And anyway, don't actual human beings need to look at these things,
> in the end, in order to be able to react to each of them properly
> and in a professional fashion?
Web forms can have pros and cons, I am just going to take the case of a VPS/Dedicated server hosting company.
If the hosting company provides a web form, they can have a field where they explicitly ask for the offending IP address.
This report could then automatically also be sent to the customer in question, because we shouldn't assume the customer is malicious, they might just have a bad config that made them a relay for example.
This could make it so the report is acted upon sooner potentially as the hosting company might take a few days to reply but maybe the customer can act sooner.
(I believe Hetzner as an example does this or something similar.)
> A provider that is routinely receiving so many abuse reports that
> it can barely keep up with them all has bigger problems that just
> the manner in which abuse reports are received.
Due to the automated procedure by some providers for abuse reports, if I have one bad host sending spam, I might get an abuse report for every single email they receive, so even if it is just one customer I might wake up to 200 emails.
But if I had a way to group it by sender IP address, that would be a lot more manageable.
(this was just a hypothetical example)
Now I absolutely agree that having an abuse email address that is acted upon in a reasonable amount of time (maybe a week or so) is still essential as the web forms aren't standardised or might rely on technology like captchas.
But if you send me 200 emails about the same host in one day, I am probably still going to be mildly annoyed and I could see how this is actually unmanageable for larger providers.
I think the true solution here is just to have a standard email template or similar so providers could easily and reliably parse it automatically (at least partially).
just a very quick example that I didn't consider for more than a minute: the standard could be as easy as just beginning every report email with "abuse-host=192.0.2.20,192.0.2.21\n\n" and whatever other fields are needed.