Validated abuse-c that does not handle reports - 91.92.243.0/24 (ORG-OL329-RIPE)
Hello all, I would like to raise a case that shows a gap between abuse-c validation and abuse handling in practice. The assignment 91.92.243.0/24 (ASSIGNED PA, org ORG-OL329-RIPE, Omegatech LTD, Seychelles) is maintained by LIR MGN Teknoloji A.S. (lir-tr-mgn-1-MNT) and announced by AS202412. Since August 2026 it has hosted an active phishing operation aimed at Dutch consumers on 91.92.243.136. Spamhaus lists the /22 as SBL686264. Timeline: - 18 August, 22 August, 5 September and 7 September 2026: reports to the abuse contact abuse@omegatech.sc. No reply, no acknowledgement of receipt. The phishing pages remain online. - 24 September 2026: report to the LIR. The LIR confirmed that it holds the resource, stated that the /24 is leased via a third-party broker, and referred me back to abuse@omegatech.sc. According to the LIR, the RIPE NCC confirmed on 17 September 2026 that this address is valid. - 24 September 2026: report to the RIPE NCC (ticket 1112396). On 25 September the RIPE NCC replied that its role is limited to ensuring that the abuse contact is valid, and that handling reports is up to the network operator. Each party acts within its own mandate, and the result is that nobody acts. The abuse-c validation checks only whether the address can receive email. This address can, but reports sent to it are not handled. The LIR and the RIPE NCC both treat the successful validation as sufficient. Questions to the working group: 1. Should documented, repeated non-response from an abuse-c be a reason for the LIR to act on the assignment, in particular when the LIR leases the space via a broker? 2. Is there support for extending ripe-705 or the validation procedure, so that repeated non-handling reported with evidence triggers follow-up by the LIR? Sources: https://rest.db.ripe.net/ripe/organisation/ORG-OL329-RIPE https://rest.db.ripe.net/ripe/inetnum/91.92.240.0%20-%2091.92.243.255/versio... https://www.spamhaus.org/sbl/query/SBL686264 https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-pro... Best regards, Theo
This has been resolved in LACNIC, APNIC and AFRINIC by means of a policy proposal that ensures not just the validation but the response (in AFRINIC not yet implemented). We had a previous attempt to do that in RIPE, but it according to the chairs didn’t reach consensus. https://www.ripe.net/community/policies/proposals/2019-04/ Regards, Jordi @jordipalet
El 25 sept 2026, a las 22:58, Theo Plooij <theoplooij@gmail.com> escribió:
Hello all,
I would like to raise a case that shows a gap between abuse-c validation and abuse handling in practice.
The assignment 91.92.243.0/24 <http://91.92.243.0/24> (ASSIGNED PA, org ORG-OL329-RIPE, Omegatech LTD, Seychelles) is maintained by LIR MGN Teknoloji A.S. (lir-tr-mgn-1-MNT) and announced by AS202412. Since August 2026 it has hosted an active phishing operation aimed at Dutch consumers on 91.92.243.136. Spamhaus lists the /22 as SBL686264.
Timeline:
18 August, 22 August, 5 September and 7 September 2026: reports to the abuse contact abuse@omegatech.sc <mailto:abuse@omegatech.sc>. No reply, no acknowledgement of receipt. The phishing pages remain online. 24 September 2026: report to the LIR. The LIR confirmed that it holds the resource, stated that the /24 is leased via a third-party broker, and referred me back to abuse@omegatech.sc <mailto:abuse@omegatech.sc>. According to the LIR, the RIPE NCC confirmed on 17 September 2026 that this address is valid. 24 September 2026: report to the RIPE NCC (ticket 1112396). On 25 September the RIPE NCC replied that its role is limited to ensuring that the abuse contact is valid, and that handling reports is up to the network operator. Each party acts within its own mandate, and the result is that nobody acts. The abuse-c validation checks only whether the address can receive email. This address can, but reports sent to it are not handled. The LIR and the RIPE NCC both treat the successful validation as sufficient.
Questions to the working group:
Should documented, repeated non-response from an abuse-c be a reason for the LIR to act on the assignment, in particular when the LIR leases the space via a broker? Is there support for extending ripe-705 or the validation procedure, so that repeated non-handling reported with evidence triggers follow-up by the LIR? Sources: https://rest.db.ripe.net/ripe/organisation/ORG-OL329-RIPE https://rest.db.ripe.net/ripe/inetnum/91.92.240.0%20-%2091.92.243.255/versio... https://www.spamhaus.org/sbl/query/SBL686264 https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-pro...
Best regards, Theo
----- 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/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hello all, First a correction to my original post: the Spamhaus listing for 91.92.240.0/22 is SBL686267, not SBL686264. https://www.spamhaus.org/sbl/query/SBL686267 Thank you, Jordi. In the APNIC and LACNIC regions, abuse reports must be reviewed and responded to, and in LACNIC an abuse mailbox that ignores abuse cases can be reported for re-validation. The RIPE region has no equivalent: even 2019-04, which left the handling of reports out of scope, did not reach consensus. This case shows the result in practice. If the working group wants to revisit the topic, I am happy to share the full documentation of this case. Best regards, Theo Plooij
Forgot to mention before: The case you mention and similar ones are very common in RIPE (also in ARIN). Many abuse-c contacts are broken, they don’t accept emails, or they enforce using forms for the reporting, or they bounce, the mailbox is full or they just get ignored. Many have outdated abuse-c contacts, so it becomes nearly impossible to contact them and if you report to other addresses that the abuse-c is broken, you’re simply ignored. A very frequent situation is when they only accept emails from their own customers, so how come can you report from an attacked network? All this means many folks are not responsible for the resources they manage, which in my opinion is clearly against ethics and rules. Wild-West! Regards, Jordi @jordipalet
El 26 sept 2026, a las 10:24, Theo Plooij <theoplooij@gmail.com> escribió:
Hello all,
First a correction to my original post: the Spamhaus listing for 91.92.240.0/22 <http://91.92.240.0/22> is SBL686267, not SBL686264. https://www.spamhaus.org/sbl/query/SBL686267
Thank you, Jordi. In the APNIC and LACNIC regions, abuse reports must be reviewed and responded to, and in LACNIC an abuse mailbox that ignores abuse cases can be reported for re-validation. The RIPE region has no equivalent: even 2019-04, which left the handling of reports out of scope, did not reach consensus. This case shows the result in practice. If the working group wants to revisit the topic, I am happy to share the full documentation of this case.
Best regards, Theo Plooij ----- 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/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On Sat, 26 Sep 2026 10:12:14 +0200, "jordi.palet--- via Security-wg" <security-wg@ripe.net> wrote:
This has been resolved in LACNIC, APNIC and AFRINIC by means of a policy proposal that ensures not just the validation but the response (in AFRINIC not yet implemented).
We had a previous attempt to do that in RIPE, but it according to the chairs didn’t reach consensus.
It seemed that Denis' proposal was going to be formalized an presented to the RIPE Policy Development Process. See https://mailman.ripe.net/archives/list/security-wg@ripe.net/message/SKR2HP3N... Any news on it? Best Ale --
Yup, there will be news on this very soon. Brian Co-Chair, RIPE Security WG Brian Nisbet (he/him) Head of Service Operations Asiera (formerly HEAnet), Ireland's National Research and Education Network North Dock One, 93-94 North Wall Quay, Dublin 1, D01 V8Y6 +35316609040 brian.nisbet@asiera.ie www.heanet.ie<http://www.heanet.ie> www.asiera.ie<https://www.asiera.ie/> Registered in Ireland, No. 275301. CRA No. 20036270 ________________________________ From: Alessandro Vesely <vesely@tana.it> Sent: Monday 28 September 2026 11:27 To: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Validated abuse-c that does not handle reports - 91.92.243.0/24 (ORG-OL329-RIPE) CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe. On Sat, 26 Sep 2026 10:12:14 +0200, "jordi.palet--- via Security-wg" <security-wg@ripe.net> wrote:
This has been resolved in LACNIC, APNIC and AFRINIC by means of a policy proposal that ensures not just the validation but the response (in AFRINIC not yet implemented).
We had a previous attempt to do that in RIPE, but it according to the chairs didn’t reach consensus.
It seemed that Denis' proposal was going to be formalized an presented to the RIPE Policy Development Process. See https://mailman.ripe.net/archives/list/security-wg@ripe.net/message/SKR2HP3N... Any news on it? Best Ale -- ----- 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/
participants (4)
-
Alessandro Vesely -
Brian Nisbet -
jordi.palet＠consulintel.es -
Theo Plooij