Zusammenfassung

  • Die IETF plant die Umstellung ihrer Maildienste für den 11. September 2026. Bis zu 60 Minuten Verzögerung und ein zeitweiser Ausfall der Mailman-Weboberfläche werden erwartet. Die Umstellung ist noch nicht erfolgt; Plan und Erwartung sind kein Ergebnis.
  • Nach erfolgreicher Prüfung eines neuen Absenders kann postconfirm eine gespeicherte Nachricht wieder einspeisen. Das belegt eine lokale Regelentscheidung, nicht die Annahme durch die Liste, korrekte Umschreibung, Signatur, geschützten Transport oder Ankunft beim Empfänger.

Eine Nachricht kommt während des Wartungsfensters an. Postconfirm legt sie ab und fordert eine Antwort an. Der Absender reagiert, sein Zustand wird akzeptiert, die Nachricht wird freigegeben. Der lokale Bestand sinkt. Für diesen Dienst ist ein Vorgang abgeschlossen; für die Liste hat er vielleicht noch nicht begonnen.

Die IETF-Ankündigung vom 28. August setzt den Wechsel für den 11. September um 22 Uhr UTC an. Betroffen sind die Maildomänen von IETF, IAB, IRTF und RFC Editor. Mailman3 soll vorübergehend keine Weboberfläche anbieten, Archiv und IMAP sollen erreichbar bleiben. Die angekündigte Stunde Verzögerung und die erwarteten Hygienegewinne müssen nach dem Wechsel beobachtet werden.

Jede Warteschlange hat einen eigenen Gewahrsam

Einzelne Funktionen laufen als Kubernetes-Container und sprechen über milter; ausgehende Post wird über mehrere virtuelle Maschinen vermittelt. Postconfirm, Rspamd, Adressumschreibung, DKIM, DANE-Zertifikate und Bounce-Verarbeitung sind damit getrennte Nachweisstellen.

Das postconfirm-Projekt speichert Post unbekannter Absender bis zur Antwort und speist sie danach wieder ein. Es unterscheidet auch reject und discard: Letzteres kann dem SMTP-Client Erfolg melden und dennoch verwerfen. Ein positiver Code braucht deshalb Erzeuger, Aktion und Nachrichtenfingerabdruck.

Zu verknüpfen sind Speicherzeit, Ablauf, Prüfstatus, Freigabeversuch und Annahme der Neueinspeisung. Ein sinkender Zähler kann Fortschritt, Ablauf, Duplikat oder Verlust bedeuten.

Umschreibung ist eine dokumentationspflichtige Transformation

Listen versenden über Infrastruktur, die nicht zwingend in der SPF-Policy des ursprünglichen Absenders steht. Der neue Dienst prüft SPF und DMARC, schreibt gegebenenfalls Envelope oder Header From um und signiert mit DKIM.

SPF bewertet Hostautorisierung für eine Domain. DKIM schützt ausgewählte, kanonisierte Nachrichtenteile unter einer Signierdomain; eine individuelle Person muss damit nicht verifiziert sein. DMARC verbindet Alignment und Empfängerpolicy, beseitigt aber weder ähnlich aussehende Domains noch täuschende Anzeigenamen.

Der Beleg muss ursprüngliche und neue Identität, Umschreibungsgrund, Signierdomain, Selector, abgedeckte Felder und spätere Prüfergebnisse enthalten. Eine gültige Signatur weist Verantwortung für die signierte Form zu. Sie beglaubigt nicht rückwirkend Identität, Mandat oder Wahrheit des ursprünglichen Autors.

Das nächste Zertifikat im Cluster ist noch nicht im Internet

Mit current + next 3 1 1 soll während der Rotation stets DANE-taugliches Material verfügbar sein. Danebot trennt aktuelle und nächste Zertifikatszustände. Das ist Bereitschaft, keine externe Nutzung.

DANE für SMTP entsteht beim Sender: DNSSEC-validierte MX/TLSA-Daten authentisieren den nächsten TLS-Hop. Der RFC schützt nicht den gesamten Mailverkehr und hängt für Downgrade-Schutz von DNSSEC ab. Geplantes Schlüsselmaterial, sichtbarer TLSA-Zustand, tatsächlich ausgeliefertes Zertifikat und erfolgreicher Handshake sind getrennte Nachweise.

Annahme überträgt eine begrenzte Pflicht

Nach SMTP übernimmt ein Empfänger mit 250 OK nach DATA Verantwortung für Zustellung oder Weiterleitung. Das ist keine Lesebestätigung. RFC 3464 zählt selbst die Übergabe an einen Listenverteiler als delivered; relayed und expanded tragen andere Grenzen.

Eingangs-MTA, postconfirm, Mailman, Umschreiber, Signierer, Ausgangsrelay, Ziel-MTA und Testpostfach müssen je einen Beleg liefern. Kein Bounce beweist keine Zustellung. Ein gesunder Pod beweist keinen Abfluss der nächsten Queue.

Heng Lus Realitätsebenen trennen Konfiguration, lokalen Zustand, Protokollannahme und Ergebnis. Primat des laufenden Codes verlangt Beobachtung an der wirksamen Grenze. Praktische Datenkontrolle besitzt, wer Queues lesen, Identitäten ändern, Schlüssel drehen und Nachrichten wiederherstellen kann.

Die Modularisierung ist bewiesen, wenn diese Übergaben abstimmbar werden. Eine bestandene Prüfung ist nur der erste Beleg.

Quellen