E-mail wysłany przez VPN: gdzie naprawdę trafia odpowiedź

Wysyłasz wiadomość przez tunel, rozłączasz się, a odpowiedź przychodzi następnego ranka. Nic w tym nie potrzebuje starego adresu VPN i nic w tym się nie psuje. Poczta nie kieruje odpowiedzi na adres, z którego wysłano wiadomość; kieruje je do skrzynki pocztowej. Trzy ścieżki zlewają się tu w jedno pytanie, a ich rozdzielenie odpowiada na większość obaw.

Trzy ścieżki, które ludzie zlewają w jedną

Wysyłka, dostarczenie i odczyt to trzy osobne połączenia, a tylko dwa z nich dotyczą twojego urządzenia.

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

VPN może wpływać na pierwsze i trzecie, bo to połączenia, które nawiązuje twoje urządzenie. Nie może wpływać na drugie, bo ta ścieżka biegnie między dwoma serwerami poczty, których nie kontrolujesz. Odpowiedź nie jest pakietem wracającym na adres, z którego wysłałeś. To nowa wiadomość, którą usługa pocztowa drugiej strony dostarcza do twojej usługi skrzynki pocztowej.

Gdy trzymasz te trzy osobno, pytanie, czy odpowiedź cię znajdzie, przestaje być zagadkowe.

Pole Reply-To to adres, nie trasa

RFC 5322 definiuje Reply-To jako skrzynkę lub skrzynki, na które należy wysyłać odpowiedzi. Bez niego zwykłą wartością domyślną jest skrzynka From, chyba że odpowiadający wpisze coś innego. Oba są adresami poczty w nagłówku. Żaden z nich nie jest poleceniem ponownego otwarcia połączenia sieciowego, które wysłało pierwotną wiadomość.

Dlatego adres wyjścia VPN nigdy nie pojawia się na ścieżce odpowiedzi. Nawet gdy serwer wysyłki zapisał ten adres wyjścia gdzieś, odpowiedź jest adresowana do skrzynki pocztowej, a serwer wysyłający szuka wymieniacza poczty domeny, a nie twojego starego gniazda.

Jeśli odpowiedź trafi gdzieś nieoczekiwanie, przeczytaj Reply-To i własne ustawienia klienta nadawcy, zanim podejrzysz tunel.

Co naprawdę zapisują nagłówki śledzenia

Każdy skok SMTP dodaje z przodu nagłówek Received opisujący obsłużone połączenie, a najwyższy jest ostatnim skokiem przed dostarczeniem. Wysłana wiadomość może więc nieść szczegóły sieciowe warte przejrzenia, a te szczegóły piszą serwery, nie ty. Co zawierają, zależy od architektury wysyłki dostawcy i jego obchodzenia się z nagłówkami.

Czytaj je zamiast zgadywać, z zapisanej wiadomości:

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

Pożyteczną dyscypliną jest ustalenie, która zaufana usługa dodała każde pole. Dowolny tekst wcześniej w bloku nagłówków nie jest wiarygodnym dowodem, a nazwa produktu nie jest trwałą obietnicą, że twój adres domowy jest zawsze obecny albo zawsze nieobecny.

Późniejsze czytanie poczty to nowe połączenie

Gdy otwierasz odpowiedź, twój klient łączy się z usługą skrzynki pocztowej przez sieć, w której jesteś teraz. To świeże połączenie z własnym adresem źródłowym, a nie kontynuacja wczorajszego gniazda wysyłki. Podlega bieżącej polityce sieci, której w tej chwili używasz.

Treść zdalna to jeszcze trzecia rzecz. Klient poczty, który wczytuje zdalny obraz lub otwiera link, wykonuje osobne żądanie zgodnie z bieżącymi ustawieniami, a to żądanie może nieść dowolne identyfikatory osadzone w wiadomości. To nie jest odpowiedź SMTP docierająca na stary adres, a traktowanie jej tak ukrywa rzeczywiste narażenie.

Wyłącz treść zdalną, jeśli chcesz przeczytać wiadomość bez ogłaszania, że ją otworzyłeś.

Co sprawdzić, zanim nazwiesz to wyciekiem

Zacznij od widoku oryginalnej wiadomości i pola Reply-To. Następnie ustal, która usługa dodała wpisy Received, które cię niepokoją, i porównaj to z bieżącą dokumentacją dostawcy, a nie ze starą odpowiedzią z forum.

Na koniec rozdziel pytania: co zaobserwował serwer wysyłki, co dodał łańcuch dostarczania i o co poprosił twój klient, gdy otworzyłeś wiadomość?

Odpowiedź na te trzy osobno to więcej pracy niż sprawdzenie strony IP i to jedyna wersja, która daje wniosek, którego możesz bronić. Odpowiedź na adres e-mail nie ujawnia twojego adresu domowego i nie wymaga, aby stary tunel pozostał włączony.