Zusammenfassung

  • RIPE NCC meldete bei RIPE 93 rund 8.000 unzustellbare E-Mail-Adressen; die Größenordnung sei seit RIPE 92 ähnlich.
  • Betroffen seien etwa 1 % der täglichen Update-Benachrichtigungen. Die RIPE-Database-Dokumentation legt E-Mail als Benachrichtigungskanal fest.

Eine Datenbankänderung hat zwei Ziele: den Datensatz und die Menschen, die davon erfahren müssen. Der erste kann stimmen, während die Nachricht beim zweiten nie ankommt.

Das RIPE-Database-Team hat diese Lücke bei RIPE 93 beziffert. Rund 8.000 E-Mail-Adressen waren unzustellbar, ungefähr so viele wie seit RIPE 92. Nach Angaben des Teams betrafen sie etwa ein Prozent der täglichen Update-Benachrichtigungen. RIPE NCC überprüft Adressen regelmäßig erneut und kennzeichnet sie wieder als zustellbar, wenn E-Mails später ankommen. Benachrichtigungen seien wichtig, weil sie Nutzer über Änderungen in der Datenbank informieren.

Die beiden Zahlen haben unterschiedliche Nenner. 8.000 ist der Bestand unzustellbarer Adressen; ein Prozent bezeichnet den Anteil betroffener täglicher Benachrichtigungen. Daraus folgt weder, dass ein Prozent der Datenbankobjekte falsch ist, noch dass ein Prozent der Updates scheitert oder jede Nachricht an eine dieser Adressen verloren geht. Belegt ist ein wiederkehrendes Zustellproblem, kein Eindringen in die Datenbank.

Die Dokumentation der RIPE Database zu Benachrichtigungen trennt die Empfangsbestätigung eines Updates von den Hinweisen an Personen, die Änderungen an Objekten verfolgen. Eine Bestätigung kann per E-Mail oder über eine andere HTTP-Verbindung zurückkommen. Benachrichtigungen werden dagegen immer per E-Mail versandt. Die Bestätigung antwortet dem Absender der Änderung; der Hinweis richtet sich an die festgelegten Beobachter. Der Eingang des einen belegt nicht den Eingang des anderen.

Im Alltag ist diese Grenze entscheidend. Ein Maintainer kann sich erfolgreich anmelden, eine Änderung senden und die erwartete Bestätigung erhalten. Eine andere Person, die dasselbe Objekt beobachtet, kann auf eine Adresse angewiesen sein, die längst keine Nachrichten mehr annimmt. Die Datenbank bewahrt die Änderung; der Weg, der sie sichtbar machen sollte, endet vor dem Leser.

RIPE NCC berichtet von regelmäßigen Prüfungen und der Rückstufung wieder erreichbarer Adressen in den zustellbaren Status. Das öffentliche Protokoll nennt aber weder Prüfintervall noch Zahl der fehlgeschlagenen Nachrichten, Wiederherstellungsquote oder Aufschlüsselung nach Inhaber und Objekt. Diese Angaben könnten die Prioritäten verändern. Der öffentliche Befund bleibt klar begrenzt: etwa 8.000 Adressen sind unzustellbar und ungefähr ein Prozent der täglichen Update-Hinweise ist betroffen.

Die eigentliche Designfrage liegt zwischen „E-Mail abgelehnt“ und „Kontakt korrigiert“. Ein Bounce hilft nur, wenn er in einer sichtbaren Warteschlange landet, den betroffenen Datensätzen zugeordnet wird und der zuständige Maintainer die Adresse praktisch berichtigen kann. Eine erneute Prüfung kann erkennen, dass eine Adresse wieder funktioniert. Sie aktualisiert keine veraltete Adresse von selbst.

RIPE NCC könnte ein knappes Zustellungs-Dashboard veröffentlichen: tägliche Fehler, erneut geprüfte Adressen, wieder erreichbare Adressen und das Alter offener Fälle. Ein Hinweis an den Maintainer könnte zeigen, dass die für Benachrichtigungen hinterlegte Adresse keine E-Mails mehr annimmt. Für folgenreiche Änderungen ließe sich ein zweiter, freiwillig gewählter Kanal prüfen. Das sind redaktionelle Vorschläge, keine angekündigten Pläne von RIPE NCC.

Die Schwäche ist nicht, dass E-Mail als Technik überholt wäre. Sie informiert Betreiber an verschiedenen Orten weiterhin darüber, dass sich ein Datensatz geändert hat. Riskant ist die Annahme, ein ausgefülltes Adressfeld beweise einen lebenden Zustellweg zum Leser. Das Register hält die Erinnerung fest; erst die Zustellung macht sie für die Verantwortlichen nutzbar.

Quellen: Transcript der RIPE 93 Database Working Group · RIPE-Database-Dokumentation zu Benachrichtigungen · Transcript der RIPE 92 Database Working Group