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 баракчасын текшерүүдөн көбүрөөк иш, жана коргой ала турган тыянак чыгарган жалгыз варианты ушул. Электрондук почта дарегине жооп берүү үй дарегиңизди ачпайт жана эски туннелдин ачык турушун талап кылбайт.