E-Mail über ein VPN gesendet: wohin die Antwort wirklich geht

Sie senden eine Nachricht durch den Tunnel, trennen die Verbindung und die Antwort kommt am nächsten Morgen an. Nichts daran braucht die alte VPN-Adresse, und nichts daran bricht. E-Mail leitet Antworten nicht an die Adresse, von der eine Nachricht gesendet wurde; sie leitet sie an ein Postfach. Drei Wege werden hier zu einer Frage zusammengezogen, und sie zu trennen beantwortet den größten Teil der Sorge.

Drei Wege, die Menschen zu einem zusammenziehen

Übermittlung, Zustellung und Lesen sind drei getrennte Verbindungen, und nur zwei davon betreffen Ihr Gerät.

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

Das VPN kann die erste und die dritte beeinflussen, denn das sind Verbindungen, die Ihr Gerät aufbaut. Die zweite kann es nicht beeinflussen, denn dieser Weg verläuft zwischen zwei Mailservern, die Sie nicht kontrollieren. Eine Antwort ist kein Paket, das an die Adresse zurückkehrt, von der Sie gesendet haben. Sie ist eine neue Nachricht, die der Maildienst der anderen Seite an Ihren Postfachdienst zustellt.

Sobald Sie diese drei auseinanderhalten, ist die Frage, ob die Antwort Sie findet, nicht mehr rätselhaft.

Ein Reply-To-Feld ist eine Adresse, keine Route

RFC 5322 definiert Reply-To als das Postfach oder die Postfächer, an die Antworten gesendet werden sollen. Ohne dieses Feld ist der übliche Standard das From-Postfach, es sei denn, die antwortende Person tippt etwas anderes ein. Beides sind Mailadressen in einem Header. Keines von beiden ist eine Anweisung, die Netzwerkverbindung wieder zu öffnen, die die ursprüngliche Nachricht übermittelt hat.

Deshalb erscheint eine VPN-Ausstiegsadresse nie im Antwortweg. Selbst wenn der Übermittlungsserver diese Ausstiegsadresse irgendwo festgehalten hat, ist die Antwort an ein Postfach adressiert, und der sendende Server sucht den Mail-Exchanger der Domain statt Ihres alten Sockets.

Wenn eine Antwort unerwartet landet, lesen Sie Reply-To und die eigenen Clienteinstellungen des Absenders, bevor Sie den Tunnel verdächtigen.

Was die Trace-Header tatsächlich festhalten

Jeder SMTP-Hop stellt einen Received-Header voran, der die abgewickelte Verbindung beschreibt, und der oberste ist der letzte Hop vor der Zustellung. Eine übermittelte Nachricht kann daher Netzwerkdetails tragen, die eine Prüfung wert sind, und diese Details schreiben Server, nicht Sie. Was darin steht, hängt von der Übermittlungsarchitektur des Anbieters und seinem Umgang mit Headern ab.

Lesen Sie sie, statt zu raten, aus einer gespeicherten Nachricht:

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

Die nützliche Disziplin besteht darin, festzustellen, welcher vertrauenswürdige Dienst jedes Feld hinzugefügt hat. Beliebiger Text weiter oben im Headerblock ist kein verlässlicher Beleg, und ein Produktname ist kein dauerhaftes Versprechen, dass Ihre Heimatadresse immer vorhanden oder immer abwesend ist.

Mail später zu lesen ist eine neue Verbindung

Wenn Sie die Antwort öffnen, verbindet sich Ihr Client über das Netzwerk, in dem Sie sich jetzt befinden, mit Ihrem Postfachdienst. Das ist eine frische Verbindung mit eigener Quelladresse, keine Fortsetzung des gestrigen Übermittlungs-Sockets. Sie folgt der aktuellen Richtlinie des Netzwerks, das Sie in diesem Moment nutzen.

Remote-Inhalte sind noch eine dritte Sache. Ein Mailclient, der ein entferntes Bild lädt oder einem Link folgt, stellt eine separate Anfrage unter seinen aktuellen Einstellungen und diese Anfrage kann alle Kennungen tragen, die die Nachricht eingebettet hat. Es ist nicht die SMTP-Antwort, die an einer alten Adresse ankommt, und sie als solche zu behandeln verbirgt die tatsächliche Exposition.

Schalten Sie Remote-Inhalte ab, wenn Sie eine Nachricht lesen wollen, ohne bekannt zu geben, dass Sie sie geöffnet haben.

Was Sie prüfen sollten, bevor Sie es ein Leck nennen

Beginnen Sie mit der Ansicht der Originalnachricht und dem Reply-To-Feld. Stellen Sie dann fest, welcher Dienst die Received-Einträge hinzugefügt hat, die Sie beunruhigen, und vergleichen Sie das mit der aktuellen Dokumentation des Anbieters statt mit einer alten Forumsantwort.

Trennen Sie schließlich die Fragen: was hat der Übermittlungsserver beobachtet, was hat die Zustellkette hinzugefügt, und was hat Ihr Client angefordert, als Sie die Nachricht geöffnet haben?

Diese drei getrennt zu beantworten ist mehr Arbeit als eine IP-Seite zu prüfen, und es ist die einzige Version, die eine Schlussfolgerung ergibt, die Sie verteidigen können. Auf eine E-Mail-Adresse zu antworten verrät Ihre Heimatadresse nicht, und es erfordert nicht, dass der alte Tunnel bestehen bleibt.