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/
