E-post fersjoerd oer in VPN: wêr't it antwurd echt hinne giet

Jo stjoere in berjocht troch de tunnel, ferbrekke de ferbining, en it antwurd komt de oare moarns oan. Neat dêroan hat it âlde VPN-adres nedich, en neat dêroan giet stikken. E-post stjoert antwurden net nei it adres dêr't in berjocht fanôf stjoerd is; it stjoert se nei in postbus. Trije paden wurde hjir gearfoege ta ien fraach, en se skiede beantwurdet it grutste part fan de soarch.

Trije paden dy't minsken ta ien gearfoegje

Yntsjinjen, levering en lêzen binne trije aparte ferbiningen, en mar twa dêrfan belûke jo apparaat.

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

De VPN kin ynfloed hawwe op de earste en de tredde, om't dat ferbiningen binne dy't jo apparaat makket. Hy kin gjin ynfloed hawwe op de twadde, om't dat paad tusken twa mailtsjinners rint dy't jo net beheare. In antwurd is gjin pakket dat weromkomt by it adres dêr't jo fanôf stjoerden. It is in nij berjocht dat de mailtsjinst fan de oare kant by jo postbustsjinst leveret.

As jo dy trije apart hâlde, is de fraach oft it antwurd jo fine sil net langer mysterieus.

In Reply-To-fjild is in adres, gjin rûte

RFC 5322 definiearret Reply-To as de postbus of postbussen dêr't antwurden hinne stjoerd wurde moatte. Sûnder dat is de gewoane standert de From-postbus, útsein as de persoan dy't antwurdet eat oars typt. Beide binne mailadressen yn in koptekst. Gjint fan beide is in opdracht om de netwurkferbining wer iepen te meitsjen dy't it orizjinele berjocht yntsjinne.

Dêrom ferskynt in VPN-útgongsadres nea yn it antwurdpaad. Sels as de yntsjinjende tsjinner dat útgangsadres earne fêstlein hat, wurdt it antwurd oan in postbus adressearre, en de stjoerende tsjinner siket de mailskiffler fan it domein ynstee fan jo âlde socket.

As in antwurd earne ûnferwachts hinne giet, lês dan Reply-To en de eigen klantynstellingen fan de stjoerder foardat jo de tunnel fertinke.

Wat de spoarkopteksten echt fêstlizze

Elke SMTP-hop set in Received-koptekst foaroan dy't de ferwurke ferbining beskreau, en de boppeste is de lêste hop foar levering. In yntsjinne berjocht kin dêrom netwurkdetails drage dy't it besjen wurdich binne, en dy details wurde troch tsjinners skreaun, net troch jo keazen. Wat se befetsje hinget ôf fan de yntsjinjende arsjitektuer fan de provider en syn omgong mei kopteksten.

Lês se ynstee fan te rieden, út in bewarre berjocht:

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

De nuttige dissipline is om fêst te stellen hokker fertroude tsjinst elk fjild tafoege hat. Willekeurige tekst earder yn it koptekstblok is gjin betrouber bewiis, en in produktnamme is gjin ivich belofte dat jo thúsadres altyd oanwêzich of altyd ôfwêzich is.

E-post letter lêze is in nije ferbining

As jo it antwurd iepenje, ferbynt jo klant mei jo postbustsjinst oer hokker netwurk jo no ek brûke. Dat is in farske ferbining mei har eigen boarneadres, net in fuortsetting fan de yntsjinjende socket fan juster. It folget it hjoeddeiske belied fan it netwurk dat jo op dat stuit brûke.

Ofstân-ynhâld is wer in tredde ding. In mailklant dy't in ôfstân-ôfbylding laadt of in keppeling folget, docht in apart fersyk ûnder syn hjoeddeiske ynstellingen, en dat fersyk kin alle identifikaasjes drage dy't it berjocht ynbêde hat. It is net it SMTP-antwurd dat by in âld adres oankomt, en it as sadanich behannelje ferberget de echte bleatstelling.

Skeakelje ôfstân-ynhâld út as jo in berjocht lêze wolle sûnder oan te kundigjen dat jo it iepene hawwe.

Wat te kontrolearjen foardat jo it in lek neame

Begjin mei de werjefte fan it orizjinele berjocht en it Reply-To-fjild. Stel dan fêst hokker tsjinst de Received-ynskriuwings tafoege hat dy't jo dwers sitte, en fergelykje dat mei de hjoeddeiske dokumintaasje fan de provider ynstee fan in âld forumantwurd.

Ta beslút, skied de fragen: wat hat de yntsjinjende tsjinner waarnommen, wat hat de leveringskeatling tafoege, en wat hat jo klant frege doe't jo it berjocht iepenen?

Dy trije apart beantwurdzje is mear wurk as in IP-side kontrolearje, en it is de iennige ferzje dy't in konklúzje jout dy't jo ferdigenje kinne. Antwurdzje op in e-postadres ferriedt jo thúsadres net, en it freget net dat de âlde tunnel oanhâldt.