VPN ilə göndərilən e-poçt: cavab əslində hara gedir

Mesajı tuneldən göndərir, bağlantını kəsirsiniz və cavab səhəri gəlir. Bunun üçün köhnə VPN ünvanı lazım deyil və heç nə pozulmur. E-poçt cavabları mesajın göndərildiyi ünvana yönəltmir; onları poçt qutusuna yönəldir. Burada üç yol bir suala yığılır və onları ayırmaq narahatlığın çoxunu cavablandırır.

İnsanların bir yerə yığdığı üç yol

Göndərmə, çatdırılma və oxuma üç ayrı bağlantıdır və onlardan yalnız ikisi cihazınızı əhatə edir.

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

VPN birinciyə və üçüncüyə təsir edə bilər, çünki bunlar cihazınızın qurduğu bağlantılardır. İkinciyə təsir edə bilməz, çünki o yol sizin nəzarət etmədiyiniz iki poçt serveri arasında keçir. Cavab göndərdiyiniz ünvana qayıdan paket deyil. O, qarşı tərəfin poçt xidmətinin sizin poçt qutusu xidmətinizə çatdırdığı yeni mesajdır.

Bu üçünü ayırdıqdan sonra cavabın sizi tapıb-tapmaması sualı müəmmalı olmaqdan çıxır.

Reply-To sahəsi ünvan, marşrut deyil

RFC 5322 Reply-To sahəsini cavabların göndərilməli olduğu poçt qutusu və ya qutular kimi təyin edir. O olmadıqda adi standart From qutusudur, cavab yazan başqa bir şey yazmadıqda. Hər ikisi başlıqda duran poçt ünvanıdır. Heç biri orijinal mesajı göndərən şəbəkə bağlantısını yenidən açmaq əmri deyil.

Buna görə VPN çıxış ünvanı heç vaxt cavab yolunda görünmür. Göndərmə serveri həmin çıxış ünvanını haradasa qeyd etsə belə, cavab poçt qutusuna ünvanlanır və göndərən server köhnə soketinizə deyil, domenin poçt mübadilə serverinə baxır.

Cavab gözlənilməz bir yerə gedirsə, tuneldən şübhələnməzdən əvvəl Reply-To və göndərənin öz müştəri ayarlarını oxuyun.

İzləmə başlıqları əslində nə qeyd edir

Hər SMTP mərhələsi idarə etdiyi bağlantını təsvir edən Received başlığı əlavə edir və ən üstdəki çatdırılmadan əvvəlki son mərhələdir. Buna görə göndərilmiş mesaj nəzərdən keçirməyə dəyər şəbəkə təfərrüatları daşıya bilər və bu təfərrüatları siz deyil, serverlər yazır. Onların nə ehtiva etdiyi provayderin göndərmə arxitekturasından və başlıq emalından asılıdır.

Təxmin etmək əvəzinə onları saxlanmış mesajdan oxuyun:

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

Faydalı nizam-intizam hər sahəni hansı etibarlı xidmətin əlavə etdiyini müəyyən etməkdir. Başlıq blokunda daha əvvəl gələn ixtiyari mətn etibarlı sübut deyil və məhsul adı ev ünvanınızın həmişə mövcud və ya həmişə yox olmasına dair daimi vəd deyil.

Poçtu sonra oxumaq yeni bağlantıdır

Cavabı açdıqda müştəriniz hazırda olduğunuz şəbəkə üzərindən poçt qutusu xidmətinizə qoşulur. Bu, öz mənbə ünvanı olan təzə bağlantıdır, dünənki göndərmə soketinin davamı deyil. O, həmin anda istifadə etdiyiniz şəbəkənin cari siyasətinə tabedir.

Uzaq məzmun yenə üçüncü bir şeydir. Uzaq şəkil yükləyən və ya linki izləyən poçt müştərisi cari ayarları ilə ayrıca sorğu edir və bu sorğu mesajın daxil etdiyi bütün identifikatorları daşıya bilər. Bu, köhnə ünvana gələn SMTP cavabı deyil və ona belə baxmaq real məruz qalmanı gizlədir.

Mesajı açdığınızı elan etmədən oxumaq istəyirsinizsə, uzaq məzmunu söndürün.

Bunu sızma adlandırmazdan əvvəl nəyi yoxlamaq lazımdır

Orijinal mesaj görünüşü və Reply-To sahəsi ilə başlayın. Sonra sizi narahat edən Received qeydlərini hansı xidmətin əlavə etdiyini müəyyən edin və bunu köhnə forum cavabı ilə deyil, provayderin cari sənədləri ilə müqayisə edin.

Nəhayət, sualları ayırın: göndərmə serveri nə müşahidə etdi, çatdırılma zənciri nə əlavə etdi və mesajı açdığınızda müştəriniz nə tələb etdi?

Bu üçünə ayrıca cavab vermək IP səhifəsini yoxlamaqdan daha çox işdir və müdafiə edə biləcəyiniz nəticə çıxaran yeganə versiyadır. E-poçt ünvanına cavab vermək ev ünvanınızı açmır və köhnə tunelin açıq qalmasını tələb etmir.