Вы адпраўляеце паведамленне праз тунель, адключаецеся, і адказ прыходзіць наступнай раніцай. Нічога ў гэтым не патрабуе старога 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, і гэта адзіны варыянт, які дае выснову, якую вы можаце абараніць. Адказ на паштовы адрас не раскрывае ваш хатні адрас і не патрабуе, каб стары тунель заставаўся ўключаным.

Падобныя артыкулы