Denis
I like that idea.
Especially since there are many groups right now pushing at least within the EU
for clear legislation to mandate Service Providers to be better. The DSA
(Digital Services Act) was a start, although it was weak on Service Providers,
and only content focused, but I know there are discussions going on right now
to fix the holes.
And yes I agree again, lets not talk transport. Transport is fixed with things
like xarf.org ( http://xarf.org/ ) and the worldwide policies about
abuse-contacts.
This is an accountability problem. On all levels, not only the Hyperscaler
level.
Thanks,
Tobias
On Thu, Jul 30, 2026 at 1:39 AM, denis walker < [email protected] > wrote:
>
> 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 < security-wg@
> ripe. net ( [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 < security-wg@ ripe. net (
>> [email protected] ) >
>> *Skickat:* den 29 juli 2026 20:47
>> *Till:* security-wg@ ripe. net ( [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 < heather. skanks@ gmail. com
>> ( [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 < max. grobecker@ ml.
>>> grobecker.
>>> info ( [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/ ( 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/
>> ( 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/ ( 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/
> ( 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/
