E-posta Yönlendirme SPF ve DKIM'i Nasıl Kırar — SRS ve ARC ile Kalıcı Çözüm
Bir alias'ı Gmail'e yönlendirdiğinizde postanın neden spam'e düştüğünü ya da 550 5.7.26 ile reddedildiğini header seviyesinde açıklıyoruz. SPF'in kesin, DKIM'in koşullu kırılmasını, SRS ile zarf yeniden yazımını ve ARC zinciriyle kimlik doğrulamanın kriptografik taşınmasını sahadan gelen konfigürasyon değerleriyle anlatıyoruz.
EvilMail Team5 Ağustos 202613 dk okuma
Bir kullanıcı [email protected] adresini kendi gmail.com kutusuna yönlendiriyor. Beş dakika sonra gelen ilk meşru bülten spam klasöründe, ikincisi ise gönderene şu bounce ile geri dönüyor:
text
550-5.7.26 Unauthenticated email from orijinal.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550 5.7.26 orijinal.com domain.
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of [email protected] does not designate
203.0.113.10 as permitted sender) [email protected];
dkim=pass header.d=orijinal.com;
dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=orijinal.com
E-posta Yönlendirme SPF/DKIM'i Nasıl Kırar: SRS ve ARC Çözümü — EvilMail Blog
Sorun tek cümlede: yönlendirici artık zarfın gönderen tarafında ama From: başlığı hâlâ orijinal alan adını taşıyor. SPF bunu sahtecilik gibi görüyor. Bu yazı, yönlendirmenin SPF'i neden her zaman, DKIM'i neden çoğu zaman kırdığını header seviyesinde gösteriyor; ardından doğru çözümün "SPF'e IP eklemek" değil, zarfı SRS ile yeniden yazmak ve orijinal kimlik doğrulamayı ARC zinciriyle taşımak olduğunu anlatıyor.
SPF neden yönlendirmede kesin olarak kırılır
SPF'in (RFC 7208) doğruladığı şey zarf gönderenidir — yani MAIL FROM komutundaki adres, header'a Return-Path olarak düşen değer. From: başlığını doğrulamaz. Kafa karışıklığının tamamı bu ayrımdan çıkar.
Normal teslimde gönderen sunucu, kendi alan adının SPF kaydında listelenmiş bir IP'den bağlanır, SPF pass olur. Yönlendirmede ise akış değişir: posta önce alıcının MX'ine (evilmail.pro) ulaşır, oradan hedefe yönlendiricinin IP'sinden (203.0.113.10) yeniden çıkar. Orijinal alan adının SPF kaydında bu IP yoktur — olması da beklenemez, çünkü orijinal alan adının yönlendiricinizden haberi yok. Sonuç kaçınılmaz hard fail.
İlk akla gelen "çözüm" bir anti-desendir: yönlendirici IP'sini SPF'e eklemek.
text
v=spf1 include:_spf.evilmail.pro -all
Bu satırı siz kendi alan adınıza ekleyebilirsiniz, ama size posta gönderen binlerce üçüncü tarafın SPF kaydına ekleyemezsiniz. Üstelik SPF'in 10 DNS-lookup üst sınırı vardır; her include bu bütçeyi yer ve aşıldığında sonuç permerror olur — yani düzeltmeye çalışırken tüm postayı fail'e sürüklersiniz. +all gibi bir kestirme ise alan adınızı herkese açık bir spoof platformuna çevirir. SPF yönlendirmenin klasik kırılma noktasıdır ve doğru cevap onu zorlamak değil, zarf gönderenini SRS ile değiştirmektir.
DKIM neden bazen hayatta kalır, bazen ölür
DKIM (RFC 6376) SPF'ten dayanıklıdır çünkü IP'ye değil, iletinin kendisine bakar. İmza; seçili başlıkların (h= etiketi) ve gövde hash'inin (bh=) özel anahtarla imzalanmasından (b=) oluşur:
Saf "store and forward" yönlendirme — mesaja tek bir bayt dokunmadan olduğu gibi iletme — imzayı korur, dkim=pass devam eder. Yukarıdaki bounce senaryosunda dahi dkim=pass görmenizin nedeni budur. DMARC bazen sırf bu hizalanmış DKIM sayesinde ayakta kalır.
Antivirüs/DLP: ekleri yeniden yazan veya "taranmıştır" damgası vuran ara katmanlar.
c=relaxed/relaxed başlık ve gövde whitespace'ine tolerans tanır; simple/simple ise en ufak boşluk farkında bile patlar — yönlendirme geçen sistemlerde daima relaxed/relaxed kullanın.
Bir tuzağa dikkat: l= (body length) etiketi imzayı gövde uzunluğunun ilk N baytıyla sınırlar, böylece footer eklemesi imzayı bozmaz. Cazip görünür ama bir güvenlik açığıdır — saldırgan sizin imzanızın "kapsamadığı" kuyruğa istediği içeriği ekleyebilir. l=kullanmayın. Sonuç olarak DKIM yönlendirmeye SPF'ten dayanıklıdır ama garanti değildir; tek başına DMARC'ı kurtarmaya güvenilmez.
DMARC: iki kimliğin de hizalanması gereken yer
DMARC (RFC 7489) SPF ile DKIM'i tek başına umursamaz; hizalama (alignment) ister. Kural: SPF veya DKIM'den en az biri hem pass olacak hem de doğruladığı alan adı From: başlığındaki alan adıyla eşleşecek. relaxed (adkim=r, aspf=r) hizalamada organizational domain eşleşmesi yeter; strict (s) birebir eşleşme ister.
Yönlendirmede SPF hizalaması peşinen kaybolur, çünkü Return-Path artık yönlendiriciye ait (evilmail.pro), From: ise orijinal.com. Geriye tek şans DKIM hizalamasıdır. İmza bir mailing-list footer'ıyla bozulmuşsa o da gider ve p=reject postayı çöpe atar. rua raporlarınızda bu tip fail'leri gerçek spoof saldırılarından ayırt etmek kritik: yönlendirme kaynaklı satırlar tipik olarak dkim=pass ama spf=fail gösterir ve kaynak IP tanıdık bir yönlendirici/ESP'ye aittir — spoof ise genelde ikisi de fail ve kaynak rastgele bir konut IP bloğudur.
SRS: zarf gönderenini yeniden yazmak
Sender Rewriting Scheme'in yaptığı iş net: Return-Path'i, yönlendiricinin kendi alan adına ait, imzalı ve geri-döndürülebilir bir adrese çevirir. Böylece ikinci hop'ta SPF, yönlendiricinin alan adına karşı doğrulanır ve pass olur.
HHH — gizli anahtarla üretilmiş HMAC hash'inin ilk karakterleri (tipik olarak 4). TT — base32 kodlanmış gün-bazlı zaman damgası; postsrsd'nin varsayılan geçerlilik penceresi 21 gündür. Kalan iki alan orijinal alan adını ve yerel kısmı taşır ki bounce (DSN) geldiğinde adres çözülüp gerçek gönderene geri iletilebilsin. Hash sayesinde kimse elle SRS adresi uydurup yönlendiricinizi açık relay gibi kullanamaz. Zincirleme yönlendirme (bir SRS adresini tekrar yönlendirmek) için SRS1 formatı devreye girer ve önceki hop'un adresini sarmalar.
Secret'ı rotasyona sokarken eski anahtarı en az geçerlilik penceresi kadar (21 gün) yanınızda tutun, yoksa yolda olan bounce'ların hash doğrulaması başarısız olur.
Gizlilik notu: SRS adresi tasarımı gereği orijinal alan adını ve yerel kısmı düz metin gömer. Yani [email protected] adresi, kutusuna ulaşan herkese kullanıcının bir bankayla yazıştığını söyler. Bunu maskelemek için opak alias eşlemesi kullanın: gerçek adresi bir arama tablosunda tutup SRS'te yalnızca kısa ömürlü, anlamsız bir token taşıyın. evilmail.pro'nun geçici e-posta katmanı tam olarak bu opak eşlemeyi standart olarak uygular.
ARC: orijinal kimlik doğrulamayı imzalı taşımak
SRS SPF'i onarır ama DKIM footer eklemesiyle bozulduğunda hâlâ elinizde dmarc=fail kalır. İşte ARC'ın (RFC 8617) çözdüğü sorun tam bu: "posta bana ulaştığında SPF/DKIM/DMARC geçiyordu; sana gelirken kırıldıysa bunun sorumlusu benim müdahalemdir, sözüme kefil oluyorum."
ARC bunu üç başlıkla, kriptografik olarak yapar; her biri i= instance numarasıyla (i=1, 2, ...) etiketlenir:
ARC-Authentication-Results (AAR) — o durakta görülen spf/dkim/dmarc sonuçlarının dondurulmuş kaydı.
ARC-Message-Signature (AMS) — DKIM benzeri, o andaki mesajın imzası.
ARC-Seal (AS) — önceki tüm halkaların (AAR + AMS + eski AS'ler) üzerine mühür; zincirin bütünlüğünü garanti eder.
Zincir doğrulaması cv= alanıyla yürür: ilk halkada cv=none, sağlam devam eden zincirde cv=pass, bozulmuşsa cv=fail. Alıcı taraf en son AMS'nin geçerli olduğunu ve tüm AS zincirinin sağlam olduğunu görürse arc=pass verir. Bu tek başına DMARC'ı geçirmez; ama alıcı yönlendiriciyi güvenilir kabul ediyorsa (Google ve Microsoft'un yaptığı gibi) arc=pass, DMARC reject kararını "local policy override" ile ezmek için meşru gerekçe olur.
rspamd kullanıyorsanız local.d/arc.conf içinde sign_local = true; use_domain = "header"; selector = "arc"; ile aynı işi milter'sız halledebilirsiniz.
SRS + ARC birlikte: doğru mimari
İki mekanizma iki farklı katmandır ve ikisi de gerekir. Kural basit: gelen postada ARC mühürle, çıkan postada SRS ile zarfı yeniden yaz. İşlem sırası şudur:
1.Kabul (reception) — postayı al.
2.Doğrula — SPF/DKIM/DMARC sonuçlarını hesapla.
3.ARC seal ekle — o anki auth sonuçlarını i=1 cv=none ile dondur.
4.Yerel değişiklik — footer/etiket ekliyorsan, ardından mesajı kendi d=evilmail.pro alan adınla yeniden DKIM imzala (re-sign). Böylece alıcı içeriği değiştirmiş olsan bile en azından senin kimliğini doğrular.
Re-signing adımı çoğu kişinin atladığı ama alignment için hayati olan yerdir: içeriğe dokunduysan orijinal DKIM zaten öldü; kendi imzanı eklemezsen alıcının doğrulayacak hiçbir sağlam kimliği kalmaz.
Doğrulama ve gizlilik kontrol listesi
Yönlendirmeyi swaks ile uçtan uca test edin ve teslim edilen mesajın header'ını okuyun:
7.Received ve X-Forwarded-For başlıklarındaki iç IP'ler header_checks ile temizleniyor mu (/^Received:.*internal/ IGNORE)?
8. SRS adresinde PII maskeleniyor mu — orijinal alan adı yerine opak alias token'ı mı taşınıyor?
Yönlendirme e-postanın en eski özelliği ama SPF ve DKIM'in iki temel varsayımını aynı anda çiğniyor. SRS zarfı, ARC ise kimliği kurtarır; ikisi birden çalışmadan p=reject çağındaki hiçbir kutuya güvenilir teslim yapamazsınız.
