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]<mailto:[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]<mailto:[email protected]>> Skickat: den 29 juli 2026 20:47 Till: [email protected]<mailto:[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]<mailto:[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]<mailto:[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/
