E-mail odoslaný cez VPN: kam odpoveď naozaj dorazí

Odošlete správu tunelom, odpojíte sa a odpoveď dorazí na druhý deň ráno. Nič z toho nepotrebuje starú VPN adresu a nič z toho sa nepokazí. E-mail nesmeruje odpovede na adresu, z ktorej bola správa odoslaná; smeruje ich do poštovej schránky. Tri cesty sa tu zlievajú do jednej otázky a ich oddelenie odpovedá na väčšinu obáv.

Tri cesty, ktoré ľudia zlievajú do jednej

Podanie, doručenie a čítanie sú tri oddelené pripojenia a len dve z nich zahŕňajú vaše zariadenie.

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

VPN môže ovplyvniť prvé a tretie, pretože to sú pripojenia, ktoré vaše zariadenie vytvára. Nemôže ovplyvniť druhé, pretože tá cesta vedie medzi dvoma poštovými servermi, ktoré nekontrolujete. Odpoveď nie je paket, ktorý sa vracia na adresu, z ktorej ste odoslali. Je to nová správa, ktorú poštová služba druhej strany doručí do vašej služby poštovej schránky.

Keď tie tri držíte oddelene, otázka, či vás odpoveď nájde, prestáva byť záhadná.

Pole Reply-To je adresa, nie trasa

RFC 5322 definuje Reply-To ako poštovú schránku alebo schránky, na ktoré sa majú odpovede posielať. Bez neho je obvyklou predvolenou hodnotou schránka From, ak človek, ktorý odpovedá, nenapíše niečo iné. Obe sú poštové adresy v hlavičke. Ani jedna nie je pokyn znovu otvoriť sieťové pripojenie, ktoré odoslalo pôvodnú správu.

Preto sa adresa výstupu VPN nikdy neobjaví v ceste odpovede. Aj keď server pre podanie tú výstupnú adresu niekde zaznamenal, odpoveď je adresovaná poštovej schránke a odosielajúci server hľadá poštový výmenník domény, nie váš starý socket.

Ak odpoveď ide niekam nečakane, prečítajte si Reply-To a vlastné nastavenia klienta odosielateľa, skôr než začnete podozrievať tunel.

Čo sledovacie hlavičky skutočne zaznamenávajú

Každý SMTP skok pridáva dopredu hlavičku Received, ktorá opisuje spracované pripojenie, a tá najvyššia je posledný skok pred doručením. Odoslaná správa tak môže niesť sieťové podrobnosti, ktoré stoja za preskúmanie, a tieto podrobnosti píšu servery, nie vy. Čo obsahujú, závisí od architektúry podania u poskytovateľa a od jeho zaobchádzania s hlavičkami.

Čítajte ich namiesto hádania, z uloženej správy:

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

Užitočná disciplína je určiť, ktorá dôveryhodná služba pridala každé pole. Ľubovoľný text skôr v bloku hlavičiek nie je spoľahlivý dôkaz a názov produktu nie je trvalý sľub, že vaša domáca adresa je vždy prítomná alebo vždy chýba.

Čítanie pošty neskôr je nové pripojenie

Keď odpoveď otvoríte, váš klient sa pripojí k službe poštovej schránky cez sieť, v ktorej práve ste. Je to nové pripojenie s vlastnou zdrojovou adresou, nie pokračovanie včerajšieho socketu na podanie. Riadi sa aktuálnou politikou siete, ktorú v tej chvíli používate.

Vzdialený obsah je zase tretia vec. Poštový klient, ktorý načítava vzdialený obrázok alebo sleduje odkaz, robí samostatnú požiadavku podľa svojho aktuálneho nastavenia a táto požiadavka môže niesť akékoľvek identifikátory, ktoré správa vložila. Nie je to SMTP odpoveď prichádzajúca na starú adresu a zaobchádzať s ňou ako s ňou skrýva skutočnú expozíciu.

Vypnite vzdialený obsah, ak si chcete správu prečítať bez toho, aby ste oznámili, že ste ju otvorili.

Čo skontrolovať, kým to nazvete únikom

Začnite zobrazením pôvodnej správy a poľom Reply-To. Potom určte, ktorá služba pridala záznamy Received, ktoré vás znepokojujú, a porovnajte to s aktuálnou dokumentáciou poskytovateľa, nie so starou odpoveďou z fóra.

Nakoniec oddelte otázky: čo pozoroval server pre podanie, čo pridala doručovacia reťaz a čo si váš klient vyžiadal, keď ste správu otvorili?

Odpovedať na tie tri oddelene je viac práce než skontrolovať stránku s IP a je to jediná verzia, ktorá dáva záver, ktorý môžete obhájiť. Odpoveď na e-mailovú adresu neprezradí vašu domácu adresu a nevyžaduje, aby starý tunel zostal zapnutý.