Lähetät viestin tunnelin läpi, katkaiset yhteyden ja vastaus saapuu seuraavana aamuna. Mikään siinä ei tarvitse vanhaa VPN-osoitetta, eikä mikään siinä mene rikki. Sähköposti ei ohjaa vastauksia osoitteeseen, josta viesti lähetettiin; se ohjaa ne postilaatikkoon. Tässä kolme polkua litistyy yhdeksi kysymykseksi, ja niiden erottaminen vastaa suurimpaan osaan huolesta.

Kolme polkua, jotka ihmiset litistävät yhdeksi

Lähetys, toimitus ja lukeminen ovat kolme erillistä yhteyttä, ja vain kaksi niistä koskee laitettasi.

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

VPN voi vaikuttaa ensimmäiseen ja kolmanteen, koska ne ovat yhteyksiä, jotka laitteesi muodostaa. Se ei voi vaikuttaa toiseen, koska se polku kulkee kahden sähköpostipalvelimen välillä, joita et hallitse. Vastaus ei ole paketti, joka palaa osoitteeseen, josta lähetit. Se on uusi viesti, jonka toisen osapuolen sähköpostipalvelu toimittaa postilaatikkopalveluusi.

Kun pidät ne kolme erillään, kysymys siitä, löytääkö vastaus sinut, lakkaa olemasta mystinen.

Reply-To-kenttä on osoite, ei reitti

RFC 5322 määrittelee Reply-To-kentän postilaatikoksi tai postilaatikoiksi, joihin vastaukset tulee lähettää. Ilman sitä tavallinen oletus on From-postilaatikko, ellei vastaaja kirjoita jotain muuta. Molemmat ovat otsakkeessa olevia postiosoitteita. Kumpikaan ei ole kehotus avata uudelleen sitä verkkoyhteyttä, joka lähetti alkuperäisen viestin.

Siksi VPN:n ulostulo-osoite ei koskaan esiinny vastauksen polulla. Vaikka lähetyspalvelin olisi tallentanut tuon ulostulo-osoitteen jonnekin, vastaus on osoitettu postilaatikkoon, ja lähettävä palvelin etsii verkkotunnuksen postinvälittäjän vanhan pistokkeesi sijaan.

Jos vastaus menee jonnekin odottamattomaan, lue Reply-To ja lähettäjän omat asiakasasetukset ennen kuin epäilet tunnelia.

Mitä jäljitysotsakkeet todella tallentavat

Jokainen SMTP-hyppy lisää eteen Received-otsakkeen, joka kuvaa käsiteltyä yhteyttä, ja ylin niistä on viimeinen hyppy ennen toimitusta. Lähetetty viesti voi siksi kantaa verkkotietoja, jotka kannattaa käydä läpi, ja ne tiedot kirjoittavat palvelimet, eivät sinä. Se, mitä ne sisältävät, riippuu palveluntarjoajan lähetysarkkitehtuurista ja sen tavasta käsitellä otsakkeita.

Lue ne arvaamisen sijaan tallennetusta viestistä:

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

Hyödyllinen käytäntö on selvittää, mikä luotettu palvelu lisäsi kunkin kentän. Satunnainen teksti aiemmin otsakelohkossa ei ole luotettava todiste, eikä tuotteen nimi ole pysyvä lupaus siitä, että kotiosoitteesi on aina läsnä tai aina poissa.

Sähköpostin lukeminen myöhemmin on uusi yhteys

Kun avaat vastauksen, asiakkaasi yhdistää postilaatikkopalveluusi sen verkon kautta, jossa olet nyt. Se on tuore yhteys, jolla on oma lähdeosoitteensa, ei eilisen lähetyspistokkeen jatko. Se noudattaa sen verkon senhetkistä käytäntöä, jota käytät sillä hetkellä.

Etäsisältö on vielä kolmas asia. Sähköpostiasiakas, joka lataa etäkuvan tai seuraa linkkiä, tekee erillisen pyynnön nykyisillä asetuksillaan, ja se pyyntö voi kantaa mitä tahansa tunnisteita, jotka viesti upotti. Se ei ole vanhaan osoitteeseen saapuva SMTP-vastaus, ja sen pitäminen sellaisena kätkee todellisen altistuksen.

Kytke etäsisältö pois, jos haluat lukea viestin ilmoittamatta, että avasit sen.

Mitä tarkistaa ennen kuin kutsut sitä vuodoksi

Aloita alkuperäisen viestin näkymästä ja Reply-To-kentästä. Selvitä sitten, mikä palvelu lisäsi ne Received-merkinnät, jotka huolestuttavat sinua, ja vertaa sitä palveluntarjoajan nykyiseen dokumentaatioon etkä vanhaan foorumivastaukseen.

Lopuksi erota kysymykset: mitä lähetyspalvelin havaitsi, mitä toimituketju lisäsi ja mitä asiakkaasi pyysi, kun avasit viestin?

Näihin kolmeen erikseen vastaaminen on enemmän työtä kuin IP-sivun tarkistaminen, ja se on ainoa versio, joka tuottaa johtopäätöksen, jonka voit puolustaa. Sähköpostiosoitteeseen vastaaminen ei paljasta kotiosoitettasi eikä vaadi, että vanha tunneli pysyy pystyssä.

Aiheeseen liittyvät artikkelit