Zusammenfassung

  • Die IESG genehmigte draft-ietf-mailmaint-expires-06 am 8. Mai 2026 als Proposed Standard. Das Feld nennt einen Zeitpunkt, nach dem eine Nachricht ihre Gültigkeit verliert, ohne eine einheitliche operative Folge festzulegen.
  • Mailsoftware darf eine Nachricht nicht allein wegen Expires ablehnen oder verwerfen. Sie sollte eine bereits abgelaufene Nachricht nur löschen, wenn der Postfacheigentümer dieses Verhalten bewusst eingerichtet hat.

Ein Datum mit erkennbarem Urheber

Zeitgebundene Inhalte sind im E-Mail-Verkehr alltäglich. Ein Rabatt endet, eine Veranstaltung ist vorbei, eine soziale Benachrichtigung wird gegenstandslos oder eine regelmäßige Mitteilung bekommt einen Nachfolger. Solche Nachrichten müssen nicht auf Dauer dieselbe Aufmerksamkeit erhalten wie neue Informationen.

Expires liefert dafür einen maschinenlesbaren Zeitpunkt im date-time-Format von RFC 5322. Ein Message Creator darf das Feld nicht mehrfach einfügen. Nach dem angegebenen Datum verliert die Nachricht ihre Gültigkeit.

Mehr behauptet die Spezifikation bewusst nicht. Ungültig bedeutet hier nicht automatisch gelöscht, abgelehnt, zurückgerufen oder für jede Suche verborgen. Für eine genauere normative Bedeutung fehlte der Konsens, und historische Implementierungen verhielten sich unterschiedlich.

Diese Zurückhaltung berücksichtigt die Interessenlage. Der Ersteller setzt den Termin. Ein Händler kann davon profitieren, wenn alte Bedingungen verschwinden. Der Absender einer strittigen Weisung könnte wünschen, dass sie später schwerer auffindbar ist. Das Datum ist daher eine Aussage der Quelle, keine vom Empfänger erteilte Vollmacht.

Beschlossen, aber noch im redaktionellen Verfahren

Die IESG veröffentlichte ihre Genehmigung am 8. Mai 2026 um 22:11 UTC. Das Dokument stammt aus der Mail Maintenance Working Group und ist für den Standards Track als Proposed Standard vorgesehen. Zum Stichtag dieser Recherche befand sich Revision 06 in der RFC-Editor-Warteschlange, wartete auf den ersten Editor und führte für die IANA-Maßnahme den Stand RFC-Ed-Ack.

Das Message-Headers-Verzeichnis der IANA listet Expires für Mail bereits als standard und verweist auf den Entwurf. Daneben steht ein eigener Eintrag für Netnews. Der gleiche Feldname überträgt nicht automatisch die Wirkungen eines Nachrichtensystems auf ein anderes.

Historische Spuren finden sich in der X.400-Zuordnung und in früheren Registrierungen von Mail-Headern. Anwendungen haben das Feld verschieden behandelt. Die neue Arbeit gibt dieser Vielfalt nicht nachträglich den Anschein eines universellen Befehls. Sie definiert einen kleinen gemeinsamen Kern und begrenzt gefährliche Standardfolgen.

Damit bleibt die Koordination dünn. Systeme können das Signal austauschen und verstehen. Wie ein Reader Aufmerksamkeit ordnet, Ansichten bildet oder eine vom Nutzer gesteuerte Bereinigung anbietet, bleibt eine lokale Entscheidung.

Vier Schritte statt eines Zauberworts

Die Mailarchitektur unterscheidet Message Creator und Message Reader. Ein Reader kann Speicheragent oder Benutzerprogramm sein. Er kann abgelaufene Nachrichten schwächer hervorheben, aus einer Standardansicht ausblenden oder Regeln zur nutzergesteuerten Bereinigung anbieten.

Die genehmigte Arbeit zieht zwei Grenzen. Software darf eine Nachricht nicht allein wegen des Feldes ablehnen oder verwerfen. Eine Nachricht mit vergangenem Datum sollte nicht gelöscht werden, sofern der Eigentümer des Postfachs dieses Ergebnis nicht absichtlich konfiguriert hat.

Operativ sind mindestens vier Ereignisse zu unterscheiden: Das Feld wird geparst, die Darstellung ändert sich, die Nachricht erhält einen Löschstatus, und die Daten werden dauerhaft entfernt. Jeder Übergang hat eine andere Entscheidungsquelle und ein anderes Maß an Umkehrbarkeit.

IMAP4rev2 zeigt die letzten Schritte ausdrücklich. Das Kennzeichen \Deleted markiert einen Zustand. EXPUNGE entfernt so markierte Nachrichten endgültig; UID EXPUNGE grenzt die Operation auf bestimmte UIDs ein. Andere Speicherverfahren dürfen anders funktionieren, sollten aber gleichwertige Nachweise über Entscheidung und Ergebnis liefern.

Wer die ganze Kette nur „Ablauf“ nennt, verliert die Zurechnung. Dann lässt sich nicht mehr erkennen, ob die Absenderangabe, eine Oberflächenregel, eine Eigentümerrichtlinie oder ein endgültiger Löschvorgang wirksam wurde.

DKIM bestätigt keine Verfügungsgewalt

Eine DKIM-Signatur kann belegen, dass eine signierende Domain für ausgewählte Bestandteile einer Nachricht eine bestimmte Verantwortung übernommen hat. Ist Expires einbezogen, kann eine spätere Veränderung unter den Bedingungen von DKIM auffallen.

Die Signatur beweist weder die Angemessenheit des Datums noch seine Übereinstimmung mit den Interessen des Empfängers. Vor allem verleiht sie der Domain kein Recht, über die Aufbewahrung in einem fremden Postfach zu entscheiden. Die Herkunft einer Behauptung und die Befugnis zu ihrer Durchsetzung bleiben getrennt.

Maschinenlesbare und kryptografisch zuordenbare Werte wirken leicht wie fertige Befehle. In der Internetinfrastruktur ist das ein wiederkehrender Kategorienfehler. Ein Beleg kann in seinem Bereich stark sein und außerhalb dieses Bereichs keinerlei Erlaubnis schaffen.

Automatisierung bleibt möglich. Ein Reader kann Datum, Authentifizierung, Absenderhistorie, Nachrichtenart und Eigentümerwunsch zusammenführen. Er muss nur erkennbar machen, welche lokale Regel aus diesen Hinweisen eine Anzeige- oder Löschentscheidung machte.

Auch ein Angreifer kann einen gültigen Zeitpunkt wählen

Die Bedrohungsanalyse berücksichtigt Termine weit in der Vergangenheit, in naher Zukunft und weit voraus. Ohne Zusatzwissen kann der Reader weder Genauigkeit noch gute Absicht unterstellen.

Ein vergangenes Datum könnte Spam vor einer Meldung unauffällig machen. Eine nahe Frist könnte eine Beschwerde oder Weisung nach erfolgter Handlung schwerer auffindbar machen. Ein fernes Datum könnte auf dauerhafte Sichtbarkeit zielen. Deshalb eignet sich das Feld allein kaum zur Entscheidung, ob eine Nachricht erwünscht oder betrügerisch ist.

Es bleibt als Darstellungshinweis nützlich. „Die von der Nachricht angegebene Gültigkeit ist abgelaufen“ beschreibt einen Befund. „Diese Nachricht kann sicher gelöscht werden“ ist ein Urteil, das eine weitere Regel und einen verantwortlichen Entscheider erfordert.

Die Benutzeroberfläche darf aus dem ersten Satz nicht stillschweigend den zweiten machen. Sonst verschiebt sie nicht nur Semantik, sondern Kontrolle.

Quellen