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/versions.json
https://www.spamhaus.org/sbl/query/SBL686264
https://labs.ripe.net/author/angela_dallara/abuse-c-validation-update-on-progress-and-some-numbers/

Best regards,
Theo