[arin-ppml] Policy Proposal 2003-1: Required Performance of Abuse Contact

[Matthew Petach]

On Thu, Aug 28, 2025 at 10:42 AM Shawn Bakhtiar <shashaness at gmail.com>
wrote:

> [...]
>
> I am truly curious as to the communities opinion on this (and I'm going to
> do my homework as you suggested) given the conditions we are facing in
> 2025. There are times my instances are spending more CPU cycles dealing
> with this overt abuse, than dealing with actual real business.
>
>
Since you asked...

For sites I administer, when I start seeing wordpress probes in my logs, I
just put an inbound deny ACL for the subnet.
I start with the /32.  If I see a second probe from the same /24, I update
the deny line to be the whole /24.
If I see another probe from within the same /16, I update the deny line to
be the whole /16.
Takes a few minutes each week to update the ACLs, and reduces the impact on
the servers quite nicely.
So far, I've not yet received a "hey, I can't reach your site anymore"
complaint.

I think trying to make explicit rules about how quickly abuse contacts have
to respond to email complaints
is going to backfire horribly; it's far too easy to game the system.

It's rather like the US banking system, where the account holder gets hit
with a service charge for bounced checks,
but there's no input validation on check deposits.  So, I can dump 100
bogus checks into a night deposit drop at a bank
with your account number on the deposit slip, and you'll get dinged with
100 bounced check charges against your account,
even though you never deposited any bad checks yourself.  The "protection"
feature can end up being used to cause real
harm to the legitimate person, without incurring any risk or penalty to the
bad actor.

Similarly, if we start putting rules in that say all messages sent to the
abuse@ email account for a resource holder
must be responded to within 24 hours or the resources can be reclaimed,
then all I need to do is to start overwhelming
your abuse handling system to the point where it can't keep up with the
demand, and incoming complaints don't get
a response within 24 hours, and then go to ARIN and say "look, you have to
take these resources away because they
aren't responding to abuse notifications."  There's no way to shield the
resource holder from abuse like that, and if we
then trigger resource reclamation based on slow response, it's going to
quickly become a barren battlefield where only
the largest entities can survive, simply by being able to absorb bogus
complaints and generate ticket numbers in
response faster than any botnet can generate complaints.

Right now, we have a similar problem with CAN-SPAM and mailing list signup
abuse.  Sure, you can fire off
unsubscribe requests as fast as the spam comes in; but these days they all
say "may take up to 10 days to
remove your name from our lists" -- and in the meantime, now they know they
have a real person monitoring
a real mailbox, and for the next 10 days, they're going to pummel you with
as much spam as they can, all the
while pointing to the "but we're obeying the law and removing your name
from our mailing list as fast as our
system will let us".  And then they file your email address on a "do not
spam for 30 days" list, and on the 31st day,
whammo, you're back on the list getting flooded with spam; you click
unsubscribe again, they tell you again
it's going to take 10 days to remove you, you get 10 more days of getting
hammered with spam, and then
30 days of no spam...from that list.  If you're a spammer, and maintain a
collection of 31 mailing lists, you can keep a
given email address front and center of your spam cannon continuously, by
simply shifting the start of each 30+10 day
cycle by one day for each mailing list.

That is to say, in a long-winded way, it's nigh on impossible to write
policy rules that accomplish what you
want without having even more potential to be abused within the rules to
cause more pain than they
alleviate.  :(

Best of luck!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250828/f4733231/attachment.htm>