Kullanıcının gördüğü satır From: [email protected]. MTA'nın gördüğü ise bambaşka bir katman: MAIL FROM komutuyla verilen envelope-from, yani Return-Path. "Takma ad mı yönlendirme mi daha gizli?" diye soranların çoğu bu iki katmanı birbirine karıştırdığı için yanlış cevaba varır. Çünkü alias ile forwarding tam da bu ayrımda ayrışır: alias yalnızca teslim adresini yeniden yazar ve mesaj senin sunucunda kalır; forwarding mesajı üçüncü bir hop'a iter ve o hop'ta gerçek kutun ifşa olur.
Gerçek soru "hangisi daha gizli" değil. Gerçek soru şu: kimden saklanıyorsun? Gönderenden mi, kendi mail sağlayıcından mı, yoksa bir gün sızacak bir veritabanında adreslerini birbirine bağlayacak saldırgandan mı? Her senaryoda kazanan farklı, ve yanlış aracı seçmek yalnızca gizliliğini değil teslimatını da öldürüyor.
Zarf ile başlığı ayırmak: neden bu ayrım her şeyi belirliyor
Bir e-postanın iki kimliği vardır. Görünen kimlik, MUA'nın (Thunderbird, Gmail arayüzü) gösterdiği From: başlığıdır. Zarf kimliği ise SMTP oturumunda MAIL FROM:<...> ile açıklanan adrestir ve alıcı tarafta Return-Path: olarak yazılır. SPF bu zarf adresine bakar, DMARC ise From: alanı ile SPF/DKIM sonuçlarının hizalanmasına (alignment) bakar. Bu ayrımı içselleştirmeden gizlilik konuşmak mümkün değil.
"Gizlilik" tek boyutlu bir kelime değil; en az üç ayrı tehdide bölmen gerekir:
- Gönderene karşı gizlilik: Karşı taraf senin kalıcı, gerçek adresini öğrenebiliyor mu?
- Sağlayıcıya/aracıya karşı gizlilik: Postanı taşıyan veya depolayan taraf içeriği düz metin görüyor mu?
- Korelasyona karşı gizlilik: Farklı servislere verdiğin adresler sızdığında birbirine bağlanabiliyor mu?
Alias ve forwarding bu üç eksende hiç de aynı puanı almaz.
Teknik olarak alias nedir, forwarding nedir
Alias, aynı mailbox'a çözülen ikinci bir sol-taraf ya da adrestir. Teslim yereldir, ekstra SMTP hop'u yoktur, mesaj hiç dışarı çıkmaz. Return-Path değişmez çünkü yeni bir gönderim kararı verilmez. Postfix tarafında bu bir eşleme satırıdır:
# /etc/postfix/virtual
[email protected] [email protected]
[email protected] [email protected]
# main.cf
# virtual_alias_maps = hash:/etc/postfix/virtual
postmap /etc/postfix/virtual
postfix reload[email protected]'ya gelen mesaj, hiçbir yere iletilmeden doğrudan ahmet kutusuna düşer. Tek kullanımlık/temp adres, aslında alias'ın en uç halidir: TTL'li, hesapsız, otomatik yok olan bir alias.
Forwarding ise gelen mesajın başka bir alana veya sağlayıcıya yeniden gönderilmesidir. Yeni bir SMTP oturumu açılır, yeni bir MAIL FROM kararı verilir (SRS varsa yeniden yazılır) ve DKIM imzası potansiyel olarak kırılır. Dovecot Pigeonhole ile Sieve redirect en yaygın biçimidir:
# ~/sieve/forward.sieve
require ["copy"];
redirect :copy "[email protected]";:copy bir kopyayı yerelde bırakır; onsuz mesaj tamamen dışarı gider. Fark kritik: alias'ta posta yerel kalır, forwarding'te posta ikinci bir kutuya — çoğunlukla Gmail veya Outlook'a — teslim edilir ve o teslim izini bırakır.
Header ve zarf izleri: mesaj gerçekte ne sızdırıyor
Bir forwarding mesajının başlıklarını açtığında, gizliliğin nerede çatladığını satır satır görürsün. İşte evilmail.pro'dan Gmail'e iletilen bir mesajın tepe başlıkları:
Delivered-To: [email protected]
X-Original-To: [email protected]
Return-Path: <[email protected]>
Received: from mx.evilmail.pro (mx.evilmail.pro [203.0.113.10])
by mx.google.com with ESMTPS id ...
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of SRS0=a1b2=... designates 203.0.113.10) ;
dkim=pass header.d=amazon.com ;
dmarc=pass (p=REJECT) header.from=amazon.comKritik satır Delivered-To: [email protected]. Forwarding, nihai kutunu mesajın başlığına yazar. Kim bu mesaja erişirse — Gmail'in kendisi, bir eklenti, sızan bir yedek — takma adının arkasındaki gerçek adresi düz metin olarak okur. Alias'ta böyle bir satır yoktur çünkü ikinci bir teslim yoktur.
Return-Path satırındaki SRS0=... da aynı hikâyeyi anlatır. SRS devredeyse zarf adresi yeniden yazıldığı için SPF pass verir. SRS olmasaydı Return-Path orijinal amazon.com adresi kalırdı, ama iletim IP'si 203.0.113.10 Amazon'un SPF kaydında olmadığı için spf=fail dönerdi. İşin sinsi tarafı şu: SPF fail olsa bile, DKIM imzası ilettiğin gövdede sağlam kaldığı sürece DMARC yine geçer — çünkü DMARC tek bir hizalı passe razıdır. Yani DKIM forwarding'in can simididir. Asıl çöküş, aracı gövdeye dokunup (footer, Subject etiketi) DKIM'i de kırdığında olur:
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of [email protected]
does not designate 203.0.113.10 as permitted sender) ;
dkim=fail (body hash did not verify) header.d=amazon.com ;
dmarc=fail (p=REJECT) header.from=amazon.comİki bacak birden düştü: SPF SRS yokluğundan, DKIM gövde değişiminden. Geriye DMARC'ı geçirecek hiçbir hizalı pass kalmaz ve p=reject politikası mesajı doğrudan reddeder.
Received: zinciri hop sayısını ve iletim yolunu açık eder — analiz eden biri kaç sunucudan geçtiğini ve nereden yönlendirildiğini okur. Bir ayrıntı daha: mesaja bir takip pikseli veya okundu bilgisi (return receipt) gömülmüşse, forwarding'in ikinci kutuda açılması senin gerçek MUA'nı ve çıkış IP'ni gönderene sızdırabilir. Alias'ta mesaj ana kutunda açıldığı için ekstra bir ayak izi eklenmez.
Gizlilik matrisi: üç tehdit modeline karşı üç seçenek
Şimdi üç seçeneği üç tehdide karşı puanlayalım. Asimetriler net: alias gönderene karşı iyidir ama sağlayıcına karşı sıfır koruma sağlar — çünkü tüm postan senin sunucunda düz metin durur, sağlayıcı sensin. Forwarding sağlayıcı değiştirmek için iyidir ama korelasyon ve başlık sızıntısında kötüdür. Temp-email korelasyona karşı en güçlüsüdür ama kalıcılık ve yanıt verme yeteneği yoktur.
Matrisin en belirleyici sütunu "yanıt verebilme". Forwarding tek yönlüdür: gelen postayı taşır ama Reply bastığında gerçek adresinden yanıt gidersin, maske çöker. Gerçek anonim yanıt için giden postayı da yeniden yazan bir masking relay şart. Bu ihtiyaç çoğu kararı tek başına belirler.
Deliverability tuzağı: SPF, SRS, DKIM ve ARC
Forwarding'i "kur ve unut" sananların vurduğu duvar teslimattır. Dört mekanizmayı doğru kurmadan kalıcı forwarding, gizliliğini bırak, mesajlarının spam klasörüne düşmesini garantiler.
SPF (RFC 7208) zarf adresine bakar. İlettiğin mesajın orijinal Return-Path'i korunursa, ileten sunucunun IP'si o alanın SPF kaydında olmadığı için fail döner. SRS (Sender Rewriting Scheme) çözümü budur: MAIL FROM'u [email protected] biçiminde yeniden yazar. İlk hop SRS0, zincirlenmiş hop SRS1 üretir. Böylece SPF ileten alanına hizalanır ve bounce'lar doğru adrese geri döner. Postfix'te postsrsd ile:
# /etc/postfix/main.cf
sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient,header_recipient
# doğrulama
postconf -n | grep -E 'srs|canonical'DKIM (RFC 6376) başlık ve gövde değişmediği sürece forwarding'te hayatta kalır — imza kriptografiktir, IP'ye bağlı değildir. Ama bir mailing-list footer'ı, Subject'e [liste] etiketi veya herhangi bir gövde dokunuşu imzayı kırar. Bu yüzden aracı ekleyen forwarding senaryolarında DKIM pass'a güvenemezsin — ve DKIM düştüğü an, SRS'siz forwarding'te DMARC'ı geçirecek hiçbir bacak kalmaz.
ARC (RFC 8617) tam da bu noktada devreye girer. Orijinal Authentication-Results'ı ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS) ve ARC-Seal (AS) başlıklarıyla kriptografik olarak taşır. Böylece alıcı, "bu mesaj bana ulaşmadan önce güvenilir bir aracıda SPF/DKIM pass idi" bilgisini doğrulayabilir. p=reject politikalı bir alandan forward ediyorsan ARC imzalaması pratikte zorunludur; OpenARC veya rspamd'nin arc modülü ile milter zincirini opendkim → openarc sırasıyla kur.
2026 itibarıyla bu isteğe bağlı değil. Google ve Yahoo'nun günde 5.000'den fazla mesaj gönderenler için kuralları SPF+DKIM+DMARC'ı zorunlu kılıyor ve spam oranını %0,3'ün (hedef %0,1) altında tutmanı istiyor. ARC'siz forwarding bu eşiklerde teslimatı sürekli aşağı çeker.
Pratik reçeteler: hangi senaryoda ne kurulur
- Hesap kayıtları ve bültenler için: Her servise ayrı, etiketli alias üret (
kayit-amazon@,bulten-hepsi@) ve bir filtre yaz. Adres sızarsa hangi servisin sattığını anında görürsün — alias bir erken uyarı sistemidir. Yandığındapostmap'ten sil, bitti. - Sağlayıcı göçü / eski adres için: SRS'li forwarding kur, 30-90 gün tut, sonra hard-cut yap ve "adresim değişti" otomatik yanıtı bırak. Kalıcı forwarding'i altyapı olarak değil geçiş köprüsü olarak düşün.
- Tek seferlik doğrulama için: Temp-email kullan, hesap açma.
evilmail.pro'da TTL dakika-saat mertebesinde; kod geldi, işin bitti, adres yok oldu. Korelasyona karşı en güçlü seçenek budur. - Gerçek çift yönlü anonimlik için: Alias + outbound rewrite yapan masking relay. Gelen postayı alias taşır, giden postayı relay maskeler; iki yön de gerçek adresini görmez.
Kontrol listesi
- Her servise ayrı, etiketli alias üret; ana kutunu asla doğrudan verme.
- Forwarding kuruyorsan SRS'i zorunlu yap, yoksa SPF
failalırsın. p=rejectpolitikalı bir alandan forward ediyorsan ARC imzala.Delivered-ToveX-Original-Tobaşlıklarının hedefte gerçek kutunu sızdırdığını kabul et; hassas kimlikler için forwarding değil alias seç.- Yanıt verme ihtiyacın varsa forwarding değil masking relay kur.
- Alias yandığında iptal et ve adresi rotate et.
- Kalıcı olmayan doğrulamalar için temp-email kullan, hesap açma.
- Kurulumu
swaks --to [email protected] --server mx.evilmail.proile test et, mail-tester.com skorunu vedig TXT default._domainkey.evilmail.proile DKIM kaydını doğrula.
Alias kimliğini gizler ama üstünde durduğun bacağı gizlemez; forwarding kimliğini Return-Path ve Delivered-To üzerinden sızdırır ve SRS/ARC olmadan teslimatını da bozar. Doğru soru "hangisi daha gizli" değil, "kimden saklanıyorsun" — cevabı verince araç kendiliğinden belli olur.