Summary

  • RIPE NCC reported about 8,000 undeliverable email addresses at RIPE 93, a level that had stayed roughly the same since RIPE 92.
  • The same update said those addresses affected about 1% of daily update notifications. RIPE Database documentation describes notifications as email-only.

A database change has two audiences: the record and the people told to watch it. The first can be correct while the second never hears the news.

At RIPE 93, the RIPE NCC Database team put a number on that gap. It had about 8,000 undeliverable email addresses, roughly the same count reported since RIPE 92. The team said the addresses affected about 1% of daily update notifications. It periodically revalidates them and marks addresses that become deliverable again. The presentation called notifications important because they tell users that something changed in the database.

Eight thousand is the stock of unreachable addresses. One percent is the share of daily update notifications affected. Those are different measures. The transcript does not say that 1% of database objects are wrong, that 1% of updates fail, or that every message sent to one of the 8,000 addresses is lost. It says the notification system encounters a measurable delivery problem every day.

The RIPE Database documentation on notifications makes the channel unusually plain. An update acknowledgement can come by email or another HTTP connection. A notification is a separate message for people who want to know about operations on database objects, and the documentation says those messages are always sent by email. The acknowledgement tells the submitter about an update transaction; a notification tells designated recipients that an object changed. One receipt cannot stand in for the other.

That distinction matters in routine operations. A maintainer may authenticate an update successfully, receive an acknowledgement, and leave the transaction with a clean record. A separate person watching the object may still depend on an email address that no longer accepts mail. The database can preserve the edit and lose the human side of the change log.

RIPE NCC says it revalidates addresses and restores the deliverable status when mail starts working again. That is useful repair, but the public transcript gives no revalidation interval, message-level failure count, recovery rate, or breakdown by address owner and object. Any of those facts could change which repair should come first. The public evidence supports the narrower point: about 8,000 addresses remain undeliverable, and about 1% of daily update notifications are affected.

The design question is what happens between “email rejected” and “someone fixes the contact.” A bounce is useful only if it reaches a visible queue, maps back to the records that depend on the address, and gives the right maintainer a practical route to correct it. Periodic revalidation can detect that an address has recovered; it cannot by itself make a stale address current.

RIPE NCC could publish a small delivery scorecard: failed notifications by day, addresses revalidated, addresses restored, and the age of the unresolved pool. A record-level prompt could show a maintainer that the address attached to a notification path has stopped receiving mail. For high-consequence changes, the registry could also test a second, opt-in route. Those are proposals, not announced RIPE NCC plans. The immediate evidence is already strong enough to justify measuring the handoff more clearly.

The lesson is not that email has failed as a technology. Email still does the unglamorous work of telling distributed operators that a record moved. The weakness is treating a field in a database as if it were proof of a live route to a reader. The record is the registry’s memory; delivery is how that memory reaches the people expected to act on it.

Sources: RIPE 93 Database Working Group transcript · RIPE Database Notifications documentation · RIPE 92 Database Working Group transcript