Kurz erklärt: Author-Header in E-Mails

Jede E-Mail enthält Kopfzeilen, die dokumentieren, wer eine Nachricht auf welchem Weg versendet hat. Diese Informationen belegen die Vertrauenswürdigkeit, ermöglichen das Versenden von Antworten und können mit kryptografischen Signaturen (etwa DomainKeys Identified Mail, DKIM) vor Veränderungen auf dem Transportweg geschützt werden. Doch auch bei erwünschten Weiterleitungen und Modifikationen – etwa im Fall von Mailinglisten – brechen die Signaturen.

Verteiler übernehmen daher oft die Verantwortung für eine Nachricht, indem sie Header anpassen, eigene Signaturen anlegen und eventuell auch eigene Signaturprüfergebnisse in Gestalt weiterer Headerzeilen (Authenticated Received Chain, ARC) für die nächste Station der Weiterleitungskette dokumentieren. So wird aus einer Nachricht mit Kopfzeilen wie

From: "Alice" <alice@example.com>
To: verteiler@example.net

für die Empfänger des Verteilers

From: "Alice <alice@example.com> via Verteiler" <verteiler@example.net>
To: listenabonnent@example.org
Reply-To: "Alice" <alice@example.com>

Wer Autor ist, bleibt zwar menschenlesbar, versteckt sich aber in mehreren Kopfzeilen. Dieses Vorgehen ist umständlich, verwirrend, nicht standardisiert und daher auch nicht zuverlässig maschinenlesbar.

RFC 9057 schlägt nun mit Author eine neue, experimentelle Headerzeile vor und ruft zum Ausprobieren und zu Feedback auf. Sie soll die Informationen aus dem ursprünglichen From erhalten, falls ein Mediator dieses verändern muss. Mailclients können ihn direkt setzen, er muss dann identisch zum From sein. Auch Mediatoren können sie erstellen, falls sie noch nicht vorhanden ist und sie das From verändern müssen, um die darin ursprünglich enthaltenen Informationen zu sichern. Falls sich die Änderungen des Mediators auf From und Author beschränken, könnte ein empfangender Mailserver diese sogar nachvollziehen und auch noch die ursprüngliche Signatur validieren.

Das vorherige Beispiel würde dann elegantere Mails an den Verteiler erzeugen, ohne Reply-To und komplexe Texte im meist angezeigten Display Name des From:

From: verteiler@example.net
Author: "Alice" <alice@examle.com>
To: listenabonnent@example.org

Es wäre dann den Mailclients überlassen, wie sie ein solches Szenario darstellen. Es ist geplant, den Author- gegenüber dem From-Header zu bevorzugen, falls vorhanden. Eine interessante Frage lautet, wie Mailclients auf einen Klick auf den Antworten-Button reagieren würden. So könnte das Programm nachfragen, ob man gegebenenfalls der Liste, nur dem Autor oder beiden antworten möchte. In so einem Fall könnte das Mailprogramm eigene Buttons oder Shortcuts anbieten.

Für E-Mails gibt es einen ganzen Zoo an Headern, mit denen sich beliebig komplizierte, aber dennoch praxisrelevante Beispiele entwickeln lassen. Komplexer wird es etwa, wenn eine Sender-Zeile hinzukommt:

From: "Alice" <alice@example.com>
Sender: "Sekretariat" <secretariat@example.com>
To: verteiler@example.net

würde dann möglicherweise zu

From: verteiler@example.net
Author: "Alice" <alice@example.com>
Sender: "Sekretariat" <secretariat@example.com>

Das könnte den Mailclient zu Darstellungen verleiten wie „Nachricht von Sekretariat im Auftrag von Alice über verteiler@example.net“, die Verwirrung stiften und möglicherweise Angriffen Vorschub leisten. Zudem steht in einer Übergangsphase zu befürchten, dass veränderte From- und zugefügte Author-Header parallel in derselben Nachricht existieren werden.

Neben Mailclients und Mailinglisten steht auch zur Debatte, ob die Mailserver der Versender gemäß RFC 9057 Anpassungen erfahren müssten. Der Author-Header hat eine vergleichbare Bedeutung wie das altbekannte From, denn er enthält eine Kopie eines ursprünglichen From und würde sowohl die Darstellung im Mailclient als auch das Verhalten beim Verfassen einer Antwort beeinflussen. Daher sollte er den gleichen Schutz genießen und mit einer DKIM-Signatur geschützt werden. Um die Verwirrung stiftende und ohnehin nicht erlaubte Existenz mehrerer Author-Header in einer Nachricht zu verhindern, sollte Author – falls vorhanden – zudem DKIM-übersigniert werden. Dadurch würden weitere Author-Header, die von Zwischenstationen hinzugefügt wurden, die Signatur brechen.

Das wäre eine weitere Regel zum Auswählen der mittels DKIM zu signierenden Header, zu dem es bis heute aufgrund der Komplexität des Themas keine etablierte und schon gar keine vollständige Empfehlung gibt. Ebenso müsste man darüber nachdenken, eingehende Mails mit mehreren Author-Headern abzulehnen, denn diese sind nicht standardkonform und könnten von Mailclients fehlerhaft interpretiert werden. Es bestünde die Gefahr, dass Nutzer zu unerwünschten Aktionen verleitet werden, falls der falsche Header als Basis für die Darstellung der Nachricht oder weitere Aktionen dient.

Ausblick

RFC 9057 ist wenige Wochen alt und noch sind keine Implementierungen bekannt. Die Diskussion beginnt gerade erst. Sie wird sicher spannend für Postmaster. Eine eventuelle Durchsetzung des Vorschlags in der Praxis dürfte jedoch Jahre dauern. (un@ix.de)

Sven Krohlas

ist E-Mail-Spezialist und IT Security Consultant bei der BFK edv-consulting GmbH in Karlsruhe.