Retpoŝto sendita tra VPN: kien la respondo vere iras

Vi sendas mesaĝon tra la tunelo, malkonektiĝas, kaj la respondo alvenas la sekvan matenon. Nenio pri tio bezonas la malnovan VPN-adreson, kaj nenio pri tio rompiĝas. Retpoŝto ne direktas respondojn al la adreso, de kiu mesaĝo estis sendita; ĝi direktas ilin al poŝtkesto. Tri vojoj kunfandiĝas ĉi tie en unu demandon, kaj ilia apartigo respondas al la plej granda parto de la zorgo.

Tri vojoj, kiujn homoj kunfandas en unu

Sendo, liverado kaj legado estas tri apartaj konektoj, kaj nur du el ili koncernas vian aparaton.

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

La VPN povas influi la unuan kaj la trian, ĉar tiuj estas konektoj, kiujn faras via aparato. Ĝi ne povas influi la duan, ĉar tiu vojo iras inter du retpoŝtaj serviloj, kiujn vi ne regas. Respondo ne estas paketo revenanta al la adreso, de kiu vi sendis. Ĝi estas nova mesaĝo, kiun la retpoŝta servo de la alia flanko liveras al via poŝtkesta servo.

Kiam vi tenas tiujn tri aparte, la demando, ĉu la respondo trovos vin, ĉesas esti mistera.

Kampo Reply-To estas adreso, ne vojo

RFC 5322 difinas Reply-To kiel la poŝtkeston aŭ poŝtkestojn, al kiuj respondoj estu senditaj. Sen ĝi, la kutima defaŭlto estas la poŝtkesto From, krom se la respondanta persono tajpas ion alian. Ambaŭ estas retpoŝtaj adresoj en kaplinio. Neniu el ili estas instrukcio remalfermi la retan konekton, kiu sendis la originan mesaĝon.

Tial VPN-elira adreso neniam aperas en la responda vojo. Eĉ kiam la sendoservilo ie registris tiun eliran adreson, la respondo estas adresita al poŝtkesto, kaj la sendanta servilo serĉas la retpoŝtan interŝanĝilon de la domajno anstataŭ vian malnovan soketon.

Se respondo iras ie neatendite, legu Reply-To kaj la proprajn klientajn agordojn de la sendinto antaŭ ol suspekti la tunelon.

Kion la spuraj kaplinioj efektive registras

Ĉiu SMTP-salto antaŭmetas kaplinian Received, kiu priskribas la pritraktitan konekton, kaj la plej supra estas la lasta salto antaŭ liverado. Sendita mesaĝo do povas porti retajn detalojn indajn je revizio, kaj tiujn detalojn skribas serviloj, ne vi elektas ilin. Kion ili enhavas dependas de la senda arkitekturo de la provizanto kaj de ĝia traktado de kaplinioj.

Legu ilin anstataŭ diveni, el konservita mesaĝo:

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

La utila disciplino estas identigi, kiu fidinda servo aldonis ĉiun kampon. Arbitra teksto pli frue en la kaplinia bloko ne estas fidinda pruvo, kaj produkta nomo ne estas permanenta promeso, ke via hejma adreso ĉiam ĉeestas aŭ ĉiam forestas.

Legi retpoŝton poste estas nova konekto

Kiam vi malfermas la respondon, via kliento konektiĝas al via poŝtkesta servo tra kiu ajn reto vi nun estas. Tio estas freŝa konekto kun propra fontadreso, ne daŭrigo de la hieraŭa sendosoketo. Ĝi sekvas la nunan politikon de la reto, kiun vi uzas en tiu momento.

Fora enhavo estas ankoraŭ tria afero. Retpoŝta kliento, kiu ŝarĝas foran bildon aŭ sekvas ligilon, faras apartan peton laŭ siaj nunaj agordoj, kaj tiu peto povas porti ĉiajn identigilojn, kiujn la mesaĝo enkorpigis. Ĝi ne estas la SMTP-respondo alvenanta al malnova adreso, kaj trakti ĝin kiel tian kaŝas la realan elmeton.

Malŝaltu foran enhavon, se vi volas legi mesaĝon sen anonci, ke vi malfermis ĝin.

Kion kontroli antaŭ ol nomi ĝin liko

Komencu per la vido de la originala mesaĝo kaj la kampo Reply-To. Poste identigu, kiu servo aldonis la enskribojn Received, kiuj zorgigas vin, kaj komparu tion kun la nuna dokumentaro de la provizanto anstataŭ kun malnova forumrespondo.

Fine, apartigu la demandojn: kion observis la sendoservilo, kion aldonis la livera ĉeno, kaj kion petis via kliento, kiam vi malfermis la mesaĝon?

Respondi al tiuj tri aparte estas pli da laboro ol kontroli IP-paĝon, kaj ĝi estas la sola versio, kiu produktas konkludon, kiun vi povas defendi. Respondi al retpoŝta adreso ne malkaŝas vian hejman adreson, kaj ĝi ne postulas, ke la malnova tunelo restu malfermita.