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 бетін тексеруден көбірек жұмыс, және қорғауға болатын қорытынды шығаратын жалғыз нұсқа осы. Электрондық пошта мекенжайына жауап беру үй мекенжайыңызды ашпайды және ескі туннельдің ашық тұруын талап етпейді.