Zusammenfassung

  • IETF plant am 11. September 2026 ab 22:00 UTC den Wechsel der Maildienste für ietf.org, iab.org, irtf.org und rfc-editor.org. Zustellung kann bis zu 60 Minuten verzögert sein; Mailman3s Weboberfläche fällt aus, Archiv und IMAP sollen verfügbar bleiben.
  • Die neue Kette verteilt Annahme, Speicherung, Challenge, Freigabe, Adressumschreibung, DKIM-Signatur, DANE-Transport, Ausgangsqueue und Archiv auf verschiedene Komponenten. Keine Komponente kann aus ihrem Erfolg eine Ende-zu-Ende-Zustellung ableiten.

Die Mitteilung vom 28. August nennt getrennte Container, einen dedizierten Kubernetes-Cluster und milter als Verbindung. Rspamd ersetzt SpamAssassin; ein neuer Dienst schreibt Adressen um; Zertifikats- und DANE-Abläufe werden überarbeitet. Ausgehende Mail bildet die Ausnahme und läuft über mehrere virtuelle Maschinen in reputationsstarken Netzen.

Damit zerfällt der scheinbar einheitliche Zustand „Mail verfügbar“. Das Archiv kann lesbar sein, während neue Post im Challenge-Speicher liegt. Die Mailman3-Oberfläche kann fehlen, obwohl IMAP funktioniert. Der Cluster kann gesund sein, während eine Ausgangs-VM eine wachsende Queue hat.

Nicht dieselbe Wartungsmeldung wie 2024

BTW hat bereits einen öffentlichen Beitrag über das IETF-Fenster im August 2024, Amazon SES als primären Versandweg, SPF-Vorbereitung und mögliche Nichtwiederherstellung einzelner Nachrichten. Dieser Beitrag bleibt bestehen.

Eine IETF-Notiz vom Februar 2025 erklärte, dass die grundlegende Verarbeitung damals im Wesentlichen gleich blieb und tiefergehende Cloud-Nutzung später folgen sollte. Die Ankündigung 2026 beschreibt diese spätere Stufe: postconfirm wird neu gebaut, Spamprüfung, Umschreibung, DANE und Scheduling werden getrennt, der Ausgang erhält eine eigene Laufzeitumgebung.

Der neue Gegenstand ist nicht eine weitere Pause. Er ist die offen gelegte Verwahrungskette.

Annahme, Speicherung und Freigabe sind verschiedene Tatsachen

Das öffentliche postconfirm prüft Ziel und Senderstatus. Ist eine Challenge nötig, speichert es die ursprüngliche Nachricht und sendet eine Bestätigung. Eine gültige Antwort setzt den Sender auf accept und injiziert die gespeicherte Nachricht erneut.

Die Zustände unterscheiden unknown, confirming, accepted, rejected, discarded und expired. Reject meldet dem SMTP-Client einen Fehler. Discard kann Erfolg melden und trotzdem nicht zustellen. Der Challenge-Pfad hält zunächst eine Kopie zurück und beendet dann den ursprünglichen Eingangspfad.

Daraus entstehen drei Nachweise: die Antwort am Eingang, das gespeicherte Objekt und die spätere Reinjektion oder Löschung. Ein 2xx ist kein Archiveintrag. Eine accept-Zeile im Datenspeicher beweist nicht, dass die Bytes weiterliefen. Abwesenheit erklärt nicht, ob Expiry, Purge, Discard oder ein früher Fehler vorliegt.

Repository-Defaults sind keine Produktionswerte. Aufbewahrungsdauer, PostgreSQL-Topologie, Commit und Purge-Frequenz sind nicht veröffentlicht. Sie gehören in den Nachweis nach dem Cutover.

Auch die Challenge hat einen begrenzten Sinn. Sie stützt im vorgesehenen Ablauf die Kontrolle über eine Mailbox und die Zustimmung zu Note Well. Sie bestätigt weder bürgerliche Identität noch Unternehmensvollmacht, Autorität über Dritte oder Wahrheit des Beitrags.

DMARC-Umschreibung verschiebt technische Verantwortung

Eine Liste verteilt Nachrichten von ihrer eigenen Infrastruktur. Deren IP-Adressen können im SPF des Autors fehlen; Listenänderungen können ursprüngliche DKIM-Signaturen brechen. Striktes DMARC kann dadurch legitime Beiträge abweisen.

Der angekündigte Rewriter prüft SPF und DMARC. Sind IETF-Ausgangsadressen nicht autorisiert, kann er envelope From in eine reversible Adresse unter einer IETF-kontrollierten dmarc.*-Domain ändern. Bei quarantine oder reject kann er auch header From umschreiben. Danach signiert die passende IETF-Domain per DKIM.

RFC 9989 beschreibt solche Verfahren als etablierte Praxis indirekter Mailflüsse. Die Liste übernimmt Verantwortung für eine ausgerichtete Sendeidentität, aber nicht die Urheberschaft. RFC 6376 bindet eine Domain an signierte Teile; DKIM beweist weder Person, Challenge noch Zustellung.

Der Auditpfad muss ursprüngliche Adresse, gesendete envelope/header-Adressen, auslösende Policy, Mapping-Version und -Frische sowie DKIM-Domain und Selector zusammenhalten. Sonst wird „vom IETF weitergesendet“ später zu „vom IETF verfasst“.

DANE-Rollover ist ein zeitlich verteiltes Ereignis

Die Mitteilung nennt ein Schema aus aktuellem und folgenden Zertifikaten. RFC 7672 verlangt vor dem Wechsel überlappende TLSA-Assoziationen und genügend Zeit für alte DNS-Caches. Bei verpflichtendem DANE und fehlender Übereinstimmung soll Zustellung warten, statt unbemerkt unauthentifiziert zu erfolgen.

Der Erfolg eines Zertifikatsjobs ist daher nur ein Teil. TLSA-Publikation, DNSSEC, TTL, tatsächlich präsentierte Zertifikate, externer Handshake und Queue-Alter müssen korreliert werden. Der Cutover liegt in der Zukunft; universelle DANE-Nutzung externer Sender ist nicht behauptet.

Komponenten brauchen eine gemeinsame Nachrichtenidentität

Unabhängiges Skalieren verringert Kopplung, doch Replikate können während eines Rollouts unterschiedliche Konfigurationen tragen. Kubernetes stellt einen Prozess wieder her, nicht automatisch dessen Entscheidungszustand. Freigabedatenbank, reversible Mappings und Schlüssel folgen eigenen Lebenszyklen.

Die Ausgangs-VMs ergänzen Queue und IP-Reputation als getrennte Fehlerflächen. Der Cluster kann alle Filter abschließen, während der Empfänger defer antwortet. RFC 5321 definiert SMTP als hopweises Store-and-forward, nicht als atomaren Commit bis zum Leser.

Das angekündigte Ziel, eine Open-Relay-Möglichkeit zu beseitigen, entspricht RFC 2505. Es muss mit frischen, abgelaufenen, fehlenden und gefälschten Mappings negativ getestet werden. Ein Sicherheitsziel ist noch kein Messergebnis.

Archiv und IMAP sind Beobachter, keine universelle Quittung. Eine zurückgehaltene Nachricht ist noch nicht veröffentlicht; eine archivierte Nachricht kann einzelne Empfänger verfehlen. Eingang, gespeicherter Hash, Challenge, Freigabe/Purge, Umschreibung, Signatur, Listenexpansion, Archiv, Ausgangsqueue, Remote-Antwort und Bounce brauchen einen durchgehenden Zusammenhang. Jeder Hash muss seine Transformationsstufe nennen.

Running-Code Primacy verlangt den ausgeführten Pfad statt der Ankündigung. Praktische Datensouveränität folgt Kopien, Datenbanken, Logs, Schlüsseln, DNS, Pods, VMs und Archiven. Das Modell von minimaler Spezifikation und lokaler Entscheidung hält die Grenze: Gemeinsame Protokolle schaffen Semantik, jeder Betreiber entscheidet lokal und beweist seine Schnittstelle.

Modularität begrenzt Macht nur dann, wenn die Übergänge wieder zusammengesetzt werden können.