Е-пошта послата преко VPN-а: куда одговор заиста одлази

Пошаљете поруку кроз тунел, искључите се и одговор стигне следећег јутра. Ништа у вези с тим не тражи стару VPN адресу и ништа се при томе не квари. Е-пошта не усмерава одговоре на адресу са које је порука послата; усмерава их на поштанско сандуче. Три пута се овде стапају у једно питање, а њихово раздвајање одговара на већи део бриге.

Три пута која људи стапају у један

Предаја, достава и читање су три одвојене везе и само две од њих укључују ваш уређај.

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

VPN може утицати на прву и трећу, јер су то везе које ваш уређај успоставља. Не може утицати на другу, јер тај пут пролази између два поштанска сервера која не контролишете. Одговор није пакет који се враћа на адресу са које сте послали. То је нова порука коју поштанска служба друге стране доставља вашој служби поштанског сандучета.

Када та три држите одвојено, питање да ли ће вас одговор наћи престаје да буде тајанствено.

Поље Reply-To је адреса, а не рута

RFC 5322 дефинише Reply-To као поштанско сандуче или сандучиће на које одговоре треба слати. Без њега је уобичајена подразумевана вредност From сандуче, осим ако особа која одговара упише нешто друго. Оба су поштанске адресе у заглављу. Ниједно није упутство да се поново отвори мрежна веза која је предала изворну поруку.

Зато се адреса VPN излаза никада не појављује на путу одговора. Чак и када је сервер за предају ту излазну адресу негде забележио, одговор се адресира на поштанско сандуче, а сервер пошиљаоца тражи поштански размењивач домена, а не ваш стари сокет.

Ако одговор оде негде неочекивано, прочитајте Reply-To и сопствена подешавања клијента пошиљаоца пре него што посумњате на тунел.

Шта записи у заглављима за праћење заиста бележе

Сваки SMTP скок додаје напред заглавље Received које описује обрађену везу, а најгорње је последњи скок пре доставе. Предата порука зато може носити мрежне детаље које вреди прегледати, а те детаље пишу сервери, не бирате их ви. Шта садрже зависи од архитектуре предаје код пружаоца услуге и његовог руковања заглављима.

Читајте их уместо да нагађате, из сачуване поруке:

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

Корисна дисциплина је утврдити која је поуздана услуга додала свако поље. Произвољан текст раније у блоку заглавља није поуздан доказ, а назив производа није трајно обећање да је ваша кућна адреса увек присутна или увек одсутна.

Читање поште касније је нова веза

Када отворите одговор, ваш клијент се повезује са вашом службом поштанског сандучета преко мреже на којој сте сада. То је свежа веза са сопственом изворном адресом, а не наставак јучерашњег сокета за предају. Она следи тренутну политику мреже коју у том тренутку користите.

Удаљени садржај је опет трећа ствар. Клијент е-поште који учитава удаљену слику или прати везу прави посебан захтев према својим тренутним подешавањима, а тај захтев може носити све идентификаторе које је порука уградила. То није SMTP одговор који стиже на стару адресу, а третирање као да јесте скрива стварну изложеност.

Искључите удаљени садржај ако желите да прочитате поруку а да не објавите да сте је отворили.

Шта проверити пре него што то назовете цурењем

Почните са приказом изворне поруке и пољем Reply-To. Затим утврдите која је услуга додала записе Received који вас брину и упоредите то са тренутном документацијом пружаоца услуге, а не са старим одговором са форума.

На крају раздвојите питања: шта је сервер за предају приметио, шта је додао ланац доставе и шта је ваш клијент затражио када сте отворили поруку?

Одговорити на та три одвојено више је посла него проверити IP страницу и то је једина верзија која даје закључак који можете бранити. Одговор на адресу е-поште не открива вашу кућну адресу и не захтева да стари тунел остане укључен.