Zusammenfassung

  • Normale Prüf-, Speicher- und Sendeaktionen verwenden nach RFC 5293 den aktuellen Header; Dispositionsmeldungen und ein durch Fehler ausgelöstes implizites Keep verwenden das unveränderte Original.
  • Für die Deduplizierung bleiben beide Darstellungen dieselbe Nachricht. Ein Erfolgssignal beweist daher weder gespeicherte Bytes noch Signaturgültigkeit oder endgültige Zustellung.

Der fehlende Eintrag im Änderungsprotokoll

Ein Gateway entfernte ein fremdes Freigabezeichen, setzte eine interne Klassifizierung und legte die Nachricht ab. Im Streitfall passte der DSN nicht zur Ablage. Das Protokoll kannte nur „ausgeführt“, aber nicht die vom jeweiligen Schritt gelesene Sicht.

addheader fügt standardmäßig am Anfang ein, mit :last am Ende. deleteheader entfernt alle Vorkommen oder ein durch :index gewähltes. Gezählt wird vor dem Wertvergleich. Nach einer Löschung bezeichnet derselbe Index ein anderes Feld. Der Header ist während des Laufs ein geordneter Zustand.

Ein identischer Endzustand kann daher Zwischenschritte verdecken, die eine Entscheidung beeinflusst haben.

Das Original bleibt ein aktiver Eingang

exists, header, vacation sowie gewöhnliche Speicher-, Sende- und Änderungsaktionen sehen den aktuellen Zustand. Änderungen wandern auch durch eingebundene Skripte. MDN, DSN und ähnliche Meldungen müssen dagegen den ursprünglichen, unveränderten Header benutzen. Beendet ein Fehler das Skript, greift auch das vorgeschriebene implizite Keep auf das Original zurück. Das normale implizite Keep wird nach den Änderungen gedacht, sofern es nicht aufgehoben wurde.

Ohne den Auslöser sagt die Angabe „Keep“ nicht, welche Darstellung abgelegt wurde.

Eine Identität, verschiedene Bytes

Für das Aussortieren von Duplikaten gilt die bearbeitete Form als dieselbe Nachricht. Redundante Keeps dürfen nicht zwei Kopien im selben Postfach erzeugen; die Implementierung darf auswählen, welche redundante Aktion sie ausführt.

Deduplizierungsidentität, Darstellungs-Hash und beobachtetes Ergebnis sind deshalb getrennte Belege.

Still ignoriert heißt nicht wirkungslos für die Prüfung

Lokale Regeln dürfen Änderungen beschränken; ein unzulässiger Versuch wird still ignoriert. Received und Auto-Submitted dürfen nie gelöscht werden, Subject muss bearbeitbar sein. Der Schutz von Received erhält die SMTP-Schleifenspur.

Ein fehlerfreier Lauf belegt nicht jede Mutation. Erforderlich sind Auftrag, lokale Entscheidung und tatsächlicher Vorher-Nachher-Unterschied.

Signaturen binden eine bestimmte Schicht

Eine Änderung kann DKIM ungültig machen, auch wenn die Signatur gerade die Abwesenheit eines Feldes belegt. Bei S/MIME und OpenPGP/MIME kann eine signierte innere Headerkopie unverändert bleiben, während außen editiert wird. Der Befund hängt von der geprüften Schicht ab.

Korrekte Syntax beweist zudem keine vertrauenswürdige Herkunft. Eingehende Daten müssen zuerst eingefroren und geprüft, fremde Stempel isoliert und erst danach lokale Aussagen erzeugt werden.

Ein belastbarer Ausführungsbeleg

Zu sichern sind Original-Hash, geordnete Vorkommen, Skriptversion und pro Aktion Selektor, Vergleich, Richtlinienentscheidung, aktueller Hash vor und nach dem Schritt sowie die gelesene Sicht. Hinzu kommen Signaturbefunde, Deduplizierungsschlüssel, Auswahl redundanter Aktionen, Speicher- oder Sendequittung und eine unabhängige Zielbeobachtung.

Ein gewähltes redirect ist noch kein Nachweis der Annahme durch das Zielsystem.

Quellen