I agree with all of you, we need to penalise orgs that don't act, small
ones, but also the hyper scalars, which admittedly have a scale problem.
But externalising these costs is not ok.
I'd fully support Denis' proposal, but aas Suresh says, we're really
good here at not doing anything.
Best
Serge
On 30/07/2026 02:59, Suresh Ramasubramanian wrote:
I fear that any attempt to put in place a sensible policy will be
scuttled as earlier attempts have been over the past decade or more.
But yes this approach makes sense to me.
*From: *denis walker <[email protected]>
*Date: *Thursday, 30 July 2026 at 5:09 AM
*To: *Michael Duffy <[email protected]>
*Cc: *[email protected] <[email protected]>
*Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no
longer monitored and are being replaced by (bad) forms
Serge, Michael, and Working Group,
The reason LIRs do not process abuse reports is because RIPE policy
currently makes it entirely free to ignore them. We can only fix this
by creating a clear, contractual incentive where permitting systemic
abuse carries the risk of registry closure.
To avoid the historical jurisdiction arguments regarding the
definition of "abuse" (used every time we try to address this issue),
we can simply utilize the harmonized definitions established under the
EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering
DDoS, phishing, and malware distribution). Just as Address Policy
limits sub-assignments under contract, we have the absolute authority
to limit malicious routing behaviors.
I propose a simplified, two-article baseline framework for an
Anti-Abuse Policy under the Policy Development Process (PDP):
* Article 1: For the purposes of RIPE Address Policy, "Network
Abuse" is defined by the technical threat classifications
maintained under the European Union Cybercrime framework
(specifically DDoS, malware hosting, phishing networks and
systemic spam botnet distribution).
* Article 2: RIPE address space must not be systematically utilized
to facilitate Network Abuse as defined in Article 1.
By anchoring to an external regulatory baseline, we save the working
group from endless definitional debates. If a member receives
authenticated, systemic notifications of these technical harms and
explicitly refuses to remediate them, they are in violation of RIPE
Policy—with the ultimate sanction of triggering standard contractual
registry closure procedures.
Let's stop trying to fix the transport mechanism of the report and
finally address the accountability of the resource holder.
cheers
denis
------------------------------------------------------------------------
On Wed, 29 Jul 2026 at 21:02, Michael Duffy via Security-wg
<[email protected]> wrote:
From a SOC/abuse perspective, I think we're solving the wrong
problem. Attackers move in minutes. Most abuse handling still
happens in hours or days. By the time a report is reviewed, the
infrastructure has often already been rotated or abandoned. The
issue isn't how reports are submitted-email, web forms, or a new
API. The issue is whether there's an operational capability and
willingness to act on them. A new protocol won't change that. If
an organization doesn't process abuse reports today, I don't see
why another transport mechanism would suddenly make them do so. It
just gives them another inbox, queue, or API endpoint to ignore.
The real challenge isn't improving report delivery-it's reducing
response time and creating incentives to process abuse. Until
then, we're optimizing the wrong part of the workflow.
-Michael
*Från:* Serge Droz via Security-wg <[email protected]>
*Skickat:* den 29 juli 2026 20:47
*Till:* [email protected]
*Ämne:* [Security-wg] Re: Abuse mailboxes are increasingly no
longer monitored and are being replaced by (bad) forms
I think Max's point was that others don't process mail reports,
, which is true, because why would they.
The problem, in my view is not, that they are overwhelmed by spam,
because you can filter spam. And still let legitimate abuse
complaints get through. But it's work. That's all why I think
building another mechanism is not going to solve the issue. It's
work to set it up, and even more work to process the complaints.
And doing so helps others, respectively offloads the cost of abuse
to others.
Folks that already now don't bother won't bother in the future,
unles not bothering is more expensive than bothering.
But in the past we couldn't agree on making it more expensive to
permit abuse than to tolerate it.
So, I'm afraid we won't change a thing, but please prove me wrong.
Serge
On 29 July 2026 17:57:19 CEST, Heather Schiller
<[email protected]> wrote:
Have you looked at Abusix? They have tools to manage abuse
mailbox, parse various log types, and include a mechanism for
building playbooks to automate handling.
--h
On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker
<[email protected]> wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to
abuse reports mailed to their "abuse-mailbox" address,
stating that this mailbox will not be monitored and urging
you to use some form on their website.
And often enough, those forms are either only usable for
very specific types of abuse or they are just tedious to
use and sometimes I suddenly don't want to report spam or
phishing anymore to that specific provider when I see a
form with 20+ input fields.
Besides that, it renders automatic reports useless, even
those that are meant to be automatically processable
(i.e., containing information as XARF).
(Surely, automated reports are a very special topic, but
as a provider we are grateful to receive prompt reports of
abuse on our network.)
This raises the questions: Is there – at least for the
RIPE region – any sort of requirement to accept/process
abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting
forms can be, I understand why providers might not want to
maintain abuse mailboxes anymore
(the amount of spam sent towards these addresses is
hilariously large) and instead rely on forms with captchas
to tackle this problem.
So I'm wondering: Would there be a benefit for building
some standardized HTTP API with an authentication system,
that would allow providers to automatically send
authenticated abuse reports to other providers?
That could work in a similar way like DKIM does: The
sending provider needs to publish a private key somewhere
in the RIPE database, signs the report, and the receiving
provider would be able to immediately verify that signature.
And if you get a ton of false reports or even spam from a
specific provider you can still filter these out based on
the sender information in the signature.
I would like to hear your opinion on this, or maybe there
already *are* solutions I just don't know about yet
(besides from manually reporting 20-30 phishing mails a
day over 30 different forms).
Thanks and greetings
Max
-----
To unsubscribe from this mailing list or change your
subscription options, please visit:
https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_security-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=wnOKjSw2Hka3J9pq0JKlrWAbTMAL6yhLSSGi9pLfhYs&e=>
As we have migrated to Mailman 3, you will need to create
an account with the email matching your subscription
before you can change your settings.
More details at:
https://www.ripe.net/membership/mail/mailman-3-migration/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=IanMQ8pIvD7qqPqeSpVuYxshUrDx2YrdQtSQ-PWpS-Q&e=>
-----
To unsubscribe from this mailing list or change your subscription
options, please visit:
https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an
account with the email matching your subscription before you can
change your settings.
More details at:
https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
