Summary

  • RIPE-563 made the abuse-c attribute mandatory for inetnum, inet6num and aut-num objects: the referenced role object must carry a single abuse-mailbox attribute, publicly available through WHOIS and the APIs, able to receive messages, and not forcing senders into a web form. Legacy internet resources were outside the requirement when it took effect.
  • Under policy proposal 2017-02, Regular abuse-c Validation, RIPE NCC validates abuse-mailbox attributes proactively at least once a year, starting with automated technical checks that send no email.
  • A failed check marks the attribute invalid and opens an escalation chain: a ticket to the responsible LIR, a validation link to close false positives, two further contact attempts at one-week intervals, staff follow-up by phone or another channel, and, as a last resort, a procedure that can end in member closure and deregistration.
  • Validation assesses presence and reachability only, not how abuse cases are handled. Registry-reported numbers put an early trial estimate of incorrect or inactive abuse mailboxes at roughly 10–25 per cent, and a later round's automated-check pass rate at about 92.5 per cent.

For any network in the RIPE NCC service region, the public record that answers “who do I tell?” is an attribute, not a relationship. Every inetnum, inet6num and aut-num object is expected to point to a role object carrying one abuse-mailbox address, and RIPE-563 — the policy that introduced the abuse-c requirement — fixed the terms of that promise: the address must be publicly available through WHOIS and the registry's APIs, it must be able to receive messages, and it must not force senders through a web form (RIPE-563; RIPE NCC abuse-contact documentation). One limitation was built in from the start: when the requirement took effect, legacy internet resources sat outside it. The boundary still matters whenever a registry record is read as proof that a network has an accountable contact.

Under policy proposal 2017-02, Regular abuse-c Validation, RIPE NCC does not wait for complaints to reveal a dead address. It validates abuse-mailbox attributes proactively, at least once a year. The first stage is automated and deliberately silent: no email is sent. The tooling looks for formatting errors in the address, runs DNS checks, screens for bogus or honeypot addresses, and tests whether the mailbox can accept mail (validation process documentation). The failures this catches are the ones that would otherwise stay invisible in day-to-day operations — a typo, a domain that no longer resolves, an address that never existed.

A failed validation is more than a warning: it changes the record. The attribute is marked invalid and a ticket is generated for the responsible LIR — the sponsoring LIR in the case of independent resources. A validation link is sent to the mailbox itself so that a functional address caught in a false positive can close the case. If there is no response, contact is attempted two more times at one-week intervals; a staff member then tries a phone number or another channel; and as a last resort RIPE NCC may initiate its procedure for the closure of members and the deregistration of internet resources (process documentation).

The scope is narrow by design, and RIPE NCC describes it that way: validation establishes that the attribute is present and the mailbox reachable, and does not assess how abuse cases are handled once received. The registry's own reporting offers two numbers with different meanings — an early trial of the validation tool suggested that roughly 10–25 per cent of abuse-mailbox attributes might be incorrect or inactive, while a later round reported about 92.5 per cent passing the automated technical check (reported validation results). One is a trial estimate of defect prevalence, the other a later pass rate; neither has been independently audited here, and they are not a trend line. RIPE NCC has also said that anonymised statistics on how abuse cases are processed should be collected and periodically published — an acknowledgement that visibility currently ends at the mailbox.

What the programme can claim, on the evidence it publishes, is a modest and real improvement in contact-data quality, backed by a ladder that ends in the loss of resources. What it cannot claim is anything about response. For operators, the practical question is whether a passing mailbox has become a substitute for operating it; for the registry, the open question is the one its own reporting flags — whether what happens after the message arrives will ever be measured, or whether reachability remains the only standard the record has to meet.

Related directory entry: RIPE NCC abuse-contact handling.