Zusammenfassung

  • Am 25. September erklärte der IETF-Exekutivdirektor, die Bounce-Verarbeitung sei abgeschaltet und alle zuvor deaktivierten Adressen seien bis zur Behebung wieder aktiviert worden.
  • Das alte System leitete Bounces nicht an die Listen weiter. Zugleich gibt es Hinweise, dass manche neuen Fehlermeldungen unzutreffend sind.
  • Weder die Zahl der Betroffenen noch ein Termin für die Wiederaufnahme oder die tatsächliche Erreichbarkeit aller freigeschalteten Postfächer sind öffentlich belegt.

Eine Nachricht an Listenverantwortliche, jemand sei wegen zu vieler Bounces deaktiviert worden, beschreibt bereits eine vollzogene Änderung: Die Adresse erhält keine Listenpost mehr, obwohl ihre Anmeldung bestehen kann. Nach der Mail-Umstellung der IETF häuften sich solche Hinweise. Der Exekutivdirektor berichtete am 25. September, dass die Bounce-Verarbeitung ausgesetzt und sämtliche deshalb deaktivierten Adressen wieder aktiviert seien. Diese Umkehr einer automatischen Zustandsentscheidung ist die eigentliche Nachricht. Sie darf nicht mit der Behauptung verwechselt werden, die zugrunde liegenden Zustellprobleme seien verschwunden.

Das frühere System gab Bounces nach Angaben der IETF nicht zur Listenverarbeitung weiter. So blieb ein Rückstand angemeldeter, aber nicht mehr erreichbarer Adressen bestehen. Diesen Bestand zu bereinigen wäre eine nachvollziehbare Betriebsaufgabe. Doch im neuen System scheinen einige Bounce-Benachrichtigungen falsch zu sein. Eine ungeprüfte automatische Sperre könnte daher eine erreichbare Person vom regelmäßigen Listenverkehr abschneiden. Umgekehrt macht die pauschale Wiederfreischaltung einen tatsächlich unerreichbaren Empfänger nicht plötzlich erreichbar. Wie viele Adressen in welche Gruppe fallen, teilt die IETF nicht mit.

Der zeitliche Vergleich ist aufschlussreich, ohne eine Schuldzuweisung zu erlauben. Am 11. September meldete die IETF den Abschluss des Umstiegs auf modulare Mail-Dienste; verbesserte Bounce-Behandlung war ein angekündigter Nutzen. Zwei Wochen später beschreibt der neue Bericht eine Pause genau dieses Vorgangs. Acht andere Probleme gelten dort als behoben, darunter das lautlose Verwerfen bestimmter Nachrichten mit Precedence: Bulk. Überschüssiger Spam bleibt neben den Bounces in Arbeit. Diese Befunde sind verschiedene Fehlerbilder und kein Beleg für eine bestimmte Menge verlorener Korrespondenz. Auch VERP wurde vorübergehend abgeschaltet. Die Aussage des Schreibens zum Einfluss auf Verarbeitungszeiten ist in ihrer Richtung unklar und trägt keine sichere Geschwindigkeitsbehauptung.

Nach der Selbstdarstellung der IETF läuft der größte Teil ihrer Arbeit über mehr als 500 Mailinglisten. Die Frage, wer Post erhält, betrifft damit einen Zugang zur alltäglichen Standardisierungsarbeit. Die Dokumentation des Mailman-Projekts zeigt allgemein, wie ein Bounce-Ereignis zur Liefersperre und zu Benachrichtigungen führen kann. Sie belegt nicht die konkrete IETF-Konfiguration, ihre Schwellenwerte oder die Ursache eines einzelnen Falls. Der Betriebsbericht der IETF bleibt die maßgebliche Quelle für diesen Vorfall.

Bei einer Wiederaufnahme der Automatik sollte erkennbar werden, welche Nachweise eine echte Unerreichbarkeit begründen, wie zweifelhafte Meldungen abgegrenzt und Fehlentscheidungen überprüft werden. Daniel Kade schlägt hierfür eine begrenzte, nachvollziehbare Entscheidungsspur vor, ohne Adressen, Mailinhalte oder sicherheitsrelevante Details offenzulegen. Das ist eine redaktionelle Empfehlung, keine von der IETF angekündigte Maßnahme. Ebenso lässt das knappe öffentliche Schreiben offen, welche internen Prüfungen bereits stattfinden.

Quellen