July 2026 - Security-wg - mailman.ripe.net

Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
by Max Grobecker 01 Sep '26

01 Sep '26

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

22 117

Apologies
by Niall O'Reilly 31 Jul '26

31 Jul '26

Dear WG, I sent a reply to Denis yesterday using "Reply All", but inadvertently from an address which isn't subscribed to this list. As a result, my message wasn't archived, and Denis's reply to it started a separate thread. Since Denis's reply included mine entirely, I'll not risk further confusion or inconvenience by resending to have it archived. Please accept my apologies. /Niall

1 0

Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
by denis walker 30 Jul '26

30 Jul '26

Hi Niall On Thu, 30 Jul 2026, 13:41 Niall O'Reilly, <niall+ripe(a)no8.be> wrote: > On 30 Jul 2026, at 0:38, denis walker wrote: > > 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. > > As a (metaphorical) piece of string, this is admirably short. > > I think just one more article might be needed, referring to > the responsiveness required of the abuse contact. > Article 3: In the absence of an acknowledgment, abuse reports will be considered delivered once sent. The resource holder must take action within nnn. Those with more knowledge than i on how much work is involved to address a complaint within large and small organisations can fill in the 'nnn'. It could be left as 'a reasonable time frame'. But then it becomes judgemental. Cheers Denis I hope that no more will be needed. > > /Niall >

1 0