VPN üzerinden gönderilen e-posta: yanıt aslında nereye gider

Tünelden bir ileti gönderir, bağlantıyı kesersiniz ve yanıt ertesi sabah gelir. Bunun hiçbir yanı eski VPN adresine ihtiyaç duymaz ve hiçbir yanı bozulmaz. E-posta yanıtları iletinin gönderildiği adrese yönlendirmez; bir posta kutusuna yönlendirir. Burada üç yol tek bir soruda birleştirilir ve onları ayırmak endişenin büyük bölümünü yanıtlar.

İnsanların tek bir şeyde birleştirdiği üç yol

Gönderim, teslimat ve okuma üç ayrı bağlantıdır ve bunlardan yalnızca ikisi cihazınızı içerir.

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

VPN birinciyi ve üçüncüyü etkileyebilir, çünkü bunlar cihazınızın kurduğu bağlantılardır. İkinciyi etkileyemez, çünkü o yol sizin denetlemediğiniz iki posta sunucusu arasında geçer. Yanıt, gönderdiğiniz adrese geri dönen bir paket değildir. Karşı tarafın posta hizmetinin sizin posta kutusu hizmetinize teslim ettiği yeni bir iletidir.

Bu üçünü ayrı tuttuğunuzda, yanıtın sizi bulup bulmayacağı sorusu gizemli olmaktan çıkar.

Reply-To alanı bir adrestir, bir yol değil

RFC 5322, Reply-To'yu yanıtların gönderilmesi gereken posta kutusu veya kutuları olarak tanımlar. O olmadan olağan varsayılan From kutusudur, yanıt veren kişi başka bir şey yazmadıkça. İkisi de bir başlıkta duran posta adresleridir. Hiçbiri özgün iletiyi gönderen ağ bağlantısını yeniden açma talimatı değildir.

Bu yüzden VPN çıkış adresi yanıt yolunda asla görünmez. Gönderim sunucusu o çıkış adresini bir yere kaydetmiş olsa bile yanıt bir posta kutusuna adreslenir ve gönderen sunucu sizin eski soketiniz yerine alan adının posta değiştiricisini sorgular.

Bir yanıt beklenmedik bir yere giderse, tünelden şüphelenmeden önce Reply-To alanını ve gönderenin kendi istemci ayarlarını okuyun.

İzleme başlıkları gerçekte ne kaydeder

Her SMTP atlaması, işlediği bağlantıyı tanımlayan bir Received başlığını önüne ekler ve en üstteki teslimattan önceki son atlamadır. Bu nedenle gönderilen bir ileti, incelenmeye değer ağ ayrıntıları taşıyabilir ve bu ayrıntıları siz değil sunucular yazar. İçerdikleri, sağlayıcının gönderim mimarisine ve başlıklarla başa çıkma biçimine bağlıdır.

Tahmin etmek yerine onları kaydedilmiş bir iletiden okuyun:

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

Yararlı disiplin, her alanı hangi güvenilir hizmetin eklediğini belirlemektir. Başlık bloğunda daha önce yer alan rasgele metin güvenilir kanıt değildir ve bir ürün adı, ev adresinizin her zaman var olduğuna ya da her zaman yok olduğuna dair kalıcı bir söz değildir.

Postayı sonra okumak yeni bir bağlantıdır

Yanıtı açtığınızda istemciniz, şu anda bulunduğunuz ağ üzerinden posta kutusu hizmetinize bağlanır. Bu, kendi kaynak adresine sahip yeni bir bağlantıdır, dünkü gönderim soketinin devamı değildir. O anda kullandığınız ağın güncel politikasını izler.

Uzak içerik yine üçüncü bir şeydir. Uzak bir görseli yükleyen ya da bir bağlantıyı izleyen posta istemcisi, güncel ayarlarına göre ayrı bir istek yapar ve bu istek iletinin gömleştirdiği her türlü tanımlayıcıyı taşıyabilir. Bu, eski bir adrese ulaşan SMTP yanıtı değildir ve onu öyle görmek gerçek maruziyeti gizler.

Bir iletiyi açtığınızı duyurmadan okumak istiyorsanız uzak içeriği kapatın.

Buna sızıntı demeden önce neyi denetlemeli

Özgün ileti görünümüyle ve Reply-To alanıyla başlayın. Sonra sizi endişelendiren Received girdilerini hangi hizmetin eklediğini belirleyin ve bunu eski bir forum yanıtıyla değil sağlayıcının güncel belgeleriyle karşılaştırın.

Son olarak soruları ayırın: gönderim sunucusu neyi gözledi, teslimat zinciri neyi ekledi ve iletiyi açtığınızda istemciniz neyi istedi?

Bu üçünü ayrı ayrı yanıtlamak bir IP sayfasını denetlemekten daha çok iştir ve savunabileceğiniz bir sonuç üreten tek sürüm budur. Bir e-posta adresine yanıt vermek ev adresinizi açığa çıkarmaz ve eski tünelin açık kalmasını gerektirmez.