SPF 10 sorgu sınırı: teşhis ve flattening

Kural ne diyor

SPF (RFC 7208), bir alan adının kendisini zarf göndericisi olarak kullanarak posta göndermeye yetkili sunucuları listelemesini sağlar. Bir kaydın değerlendirilmesi DNS sorguları gerektirebilir ve bir kayıt include'ları sonsuza kadar zincirleyebilir; bu yüzden §4.6.4 yapılacak işi sınırlar. DNS sorgusuna yol açan terimler her değerlendirme için 10 ile sınırlıdır ve sınırın aşılması permerror sonucunu üretir. Sınır alıcı tarafında uygulanır, yani kaydı yayımlarken hiçbir uyarı almazsınız.

Aynı bölüm void lookup'ları da sınırlar: hiçbir kayıt döndürmeyen ya da var olmayan bir ada yapılan DNS sorguları. Tek bir değerlendirmede bunlardan ikiden fazlası da permerror demektir ve bu kural, artık kullanmadığınız sağlayıcılara işaret eden include'ları yakalar. Yani iptal edilmiş bir hizmetin include'unu kayıtta unutmak, toplam sorgu sayınız sınırın altında kalsa bile SPF'i bozabilir.

Sınırı aşınca ne olur

Sınıra ulaşan bir alıcı değerlendirmeyi durdurur ve permerror döndürür. RFC 7208 bunu kaydınızdaki kalıcı bir sorun olarak görür ve alıcılar genellikle bunu bir hata gibi ele alır. SPF böylece her mesaj için başarısız olur; doğru biçimde listelenmiş sunuculardan gelen postalar da buna dahildir. Kısmi bir başarı yoktur: sorgu bütçesi dolduğu anda kaydın geri kalanı hiç okunmaz.

Yürürlükte bir DMARC politikası varsa hasarın boyutu DKIM'e bağlıdır. Hizalı bir DKIM imzası taşıyan mesajlar DMARC'tan geçmeyi sürdürür; SPF hizalamasına dayanan mesajlar ise başarısız olur ve zorlayıcı bir politika altında karantinaya alınır veya reddedilir. Yıllardır sorunsuz çalışan bir kaydın, birisi bir pazarlama aracı daha eklediği gün bozulmasının nedeni budur. Değişikliği yapan ekiple sonucunu yaşayan ekip de çoğu zaman aynı ekip olmaz.

Kaydınızı teşhis etmek

E-posta Güvenliği aracı, kaydı ve her include ile redirect'i XGM sunucusundan çözümler. Ağacı gösterir, sorguları alıcıların saydığı biçimde sayar, void lookup'ları ve döngüleri işaretler ve sınıra yaklaşan kayıtları sekiz ve üzerinde uyarı olarak bildirir. Kayıttaki her değişiklikten önce ve sonra kullanın. Böylece bir değişikliğin sorgu sayısını ne kadar arttırdığını tahmin etmek zorunda kalmazsınız.

Ağacı dig ile elle de dolaşabilirsiniz. Önce kök kaydı sorgulayın, ardından her include hedefini sorgulayıp yeniden sayın. Büyük kayıtlarda yorucu bir iştir, ama sorguların tam olarak nereden geldiğini gösterir. Çıktıyı bir metin dosyasına yazarsanız, bir sonraki denetimde iki ağacı karşılaştırmanız da kolaylaşır.

dig +short TXT example.com
"v=spf1 include:_spf.mail.example.net include:esp.example.net mx -all"

dig +short TXT _spf.mail.example.net
"v=spf1 include:_spf1.mail.example.net include:_spf2.mail.example.net ~all"

Bir kaydı adım adım denetlemek

example.com için yıllar içinde büyümüş bir kaydı ele alalım. SPF Checker 12 sorgu ve permerror bildiriyor, yani SPF'e dayanan her mesaj şu anda başarısız oluyor. Aşağıdaki tablo her terimi, iç içe olanlar dahil kaç sorguya mal olduğunu ve denetimin ne bulduğunu listeliyor. Amaç sorgu sayısını olabildiğince düşürmek değil, gerçekten posta gönderen kaynakları tutup geri kalanını çıkarmaktır.

Değişikliklerden sonra kök kayıt dört sorgu kullanıyor, hepsi de posta kutusu sağlayıcısından geliyor; bülten alt alanının ise iki sorgu kullanan kendi kaydı var. İletişim formu sabit bir ip4 terimi üzerinden çalışmayı sürdürüyor. Hiçbir şey düzleştirilmediği için sağlayıcı değişiklikleri kayda hâlâ kendiliğinden yansıyor. Kökte altı sorguluk bir pay kaldığından, bir sonraki araç eklendiğinde kaydı yeniden baştan elden geçirmek de gerekmeyecek.

example.com.       IN TXT "v=spf1 include:_spf.mail.example.net ip4:192.0.2.80 -all"
news.example.com.  IN TXT "v=spf1 include:esp.example.net -all"

Bir include'u kaldırmadan önce, ilgili hizmetin artık göndermediğini ya da hizalı DKIM ile geçtiğini DMARC toplu raporlarınızda doğrulayın. Toplu rapor rehberi bu satırların nasıl okunacağını gösteriyor. Kaldırma işlemini de tek seferde değil tek tek yapın ki bir şey bozulursa sorumlusunu hemen bulabilesiniz.

HELO adları ve posta göndermeyen sunucular için SPF

RFC 7208 ayrıca, bir sunucunun bağlanırken kullandığı HELO ya da EHLO adı için de SPF kontrolü tanımlar. Alıcılar zarf göndericisi boş olduğunda, örneğin geri dönen iletilerde bu kimliği kullanır. Her posta sunucusunun ana makine adı için küçük bir kayıt yayımlamanın size hiçbir maliyeti yoktur ve bu kontrollerin geçmeyi sürdürmesini sağlar. HELO kontrolünden kalan bir sunucu, bazı alıcılarda daha sıkı bir spam değerlendirmesiyle karşılaşır.

mail.example.com. IN TXT "v=spf1 a -all"

Hiç posta göndermeyen ana makine adları v=spf1 -all yayımlayabilir. Buna web sunucuları ve DNS'te görünen, ama gönderici olarak kullanılmaları için hiçbir neden bulunmayan diğer alt alanlar dahildir. Bu kayıtlar kendi adları üzerinde durduğu için kök alan adının sorgu bütçesinden hiçbir şey harcamaz. Kimlik avı denemelerinde sahte gönderici olarak seçilen adlar da çoğu zaman tam olarak bu unutulmuş alt alanlardır.

Flattening gerektirmeyen çözümler

1. Artık kullanmadıklarınızı kaldırın

Eski kayıtlar, yıllar önce iptal edilmiş araçların include'larını biriktirir. Her include'u gönderici envanterinizle ve DMARC toplu raporlarınızdaki kaynaklarla karşılaştırın. Aylardır geçen bir kaynak olarak hiç görünmeyen bir include, kaldırılmaya adaydır. Emin değilseniz kararı bir çeyrek boyunca erteleyin; raporlar sessiz kalırsa include'u güvenle çıkarabilirsiniz.

2. Gerekmediği yerde mx ve a terimlerini çıkarın

mx, gelen posta sunucularınıza gönderme yetkisi verir; bu ancak o sunucular gerçekten dışarıya posta gönderiyorsa doğru bir tercihtir. Barındırılan posta kutusu sağlayıcılarının çoğu, giden postayı kendi include'larının zaten kapsadığı başka sunuculardan teslim eder. Gereksiz bir mx ya da a terimini kaldırmak her biri için bir sorgu kazandırır. Kaldırmadan önce, gelen sunucularınızın son aylarda hiç dışarıya posta göndermediğini günlüklerinizden doğrulayın.

3. Sağlayıcılar kendi bounce alan adlarını kullansın

SPF, görünen From adresine göre değil, zarf göndericisine (return-path) göre kontrol edilir. Bir sağlayıcı kendi alan adındaki ya da bounces.example.com gibi bir alt alandaki bir bounce adresiyle gönderiyorsa SPF o alan adı için değerlendirilir ve kök kaydınızın o sağlayıcının include'una hiç ihtiyacı kalmaz. DMARC ise alan adınızla imzalanmış DKIM üzerinden geçer. Bu yüzden yeni bir sağlayıcı seçerken kendi bounce alan adını kullanıp kullanamayacağını baştan sorun.

4. Göndermeyi alt alanlara bölün

Her alan adının kendi SPF kaydı ve kendi 10 sorguluk bütçesi vardır. Bültenleri news.example.com, makbuzları billing.example.com adresine taşımak bu include'ları kök kaydın dışına çıkarır. Her alt alanın ardından kendi DKIM kurulumuna ihtiyacı olur ve kurumsal DMARC politikasını devralır. Bu bölünme raporları da netleştirir, çünkü her akışın teslim edilebilirliğini ayrı ayrı izleyebilirsiniz.

; before: 11 lookups at the root
example.com.       IN TXT "v=spf1 include:_spf.mail.example.net include:esp.example.net include:crm.example.net include:helpdesk.example.net mx -all"

; after: the mailbox provider stays at the root, other streams move
example.com.       IN TXT "v=spf1 include:_spf.mail.example.net -all"
news.example.com.  IN TXT "v=spf1 include:esp.example.net -all"
help.example.com.  IN TXT "v=spf1 include:helpdesk.example.net -all"

Flattening: nasıl çalışır ve neden risklidir

Flattening, include mekanizmalarını o an çözümlendikleri ip4 ve ip6 aralıklarıyla değiştirir. Adres mekanizmaları sınıra sayılmadığı için düzleştirilmiş bir kayıt, sıfır ya da tek bir sorguyla birçok sağlayıcıyı listeleyebilir. Sayı sorununu çözer, ama başkasının yapılandırmasını anlık bir görüntü olarak kendi DNS'inize kopyalar. Kayıt bir kez düzleştirildiğinde, o aralıkların güncel kalması artık sağlayıcının değil sizin sorumluluğunuzdadır.

Sağlayıcılar gönderim aralıklarını, bazen önceden haber vermeden değiştirir. Düzleştirilmiş bir kayıt eski aralıkları saklamayı sürdürür ve yeni sunuculardan gelen postalar, kaydı biri elle güncelleyene kadar SPF'ten kalır. Arıza sessizdir: DNS'te hiçbir şey size sağlayıcının include'unun değiştiğini söylemez. İlk belirti çoğu zaman bir kullanıcıdan gelen "postalarım artık spam klasörüne düşüyor" şikâyeti olur.

Düzleştirecekseniz bu işi otomatikleştirin. Zamanlanmış bir görev özgün include'ları çözümlemeli, aralıkları yayımlanmış kayıtla karşılaştırmalı ve bir fark bulduğunda uyarı vermeli ya da kaydı güncellemelidir. Sık değişen sağlayıcılar için include'ları koruyun ve yalnızca kendi sunucularınız gibi denetiminizdeki kararlı aralıkları düzleştirin. Betiği bir değişiklik geçmişi tutacak biçimde yazın; böylece hangi aralığın kayda ne zaman girdiğini sonradan izleyebilirsiniz.

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 " "ip6:2001:db8:10::/48 ip6:2001:db8:20::/48 include:_spf.mail.example.net -all"

Makrolar ve SPF barındırma hizmetleri

Bazı hizmetler sınırı exists mekanizması ve SPF makrolarıyla aşar. Kayıt exists:%{i}._spf.service.example.net gibi bir terim içerir ve hizmet, gönderen IP başına o adrese izin verilip verilmediğini yanıtlar. Arkasında kaç sağlayıcı olursa olsun değerlendirme tek bir sorguya mal olur. Kayıt böylece sabit kalır; gönderici listesi değişse bile kendi DNS'inizde hiçbir şeyi güncellemeniz gerekmez.

Bu yaklaşım, yetkili sunucularınızın listesini üçüncü bir tarafın DNS'ine taşır. Büyük kurumlar için makul bir tercih olabilir, ama bağımlılığı bilerek kabul edin: hizmet çöktüğünde ya da yanlış yapılandırıldığında tüm postalarınız için SPF başarısız olur. Makrolar ayrıca kaydı okumayı ve denetlemeyi zorlaştırır; sorguyu sayan ama arkasındaki listeyi göremeyen SPF Checker gibi araçlar için de geçerlidir bu. Çıkış planınızı baştan düşünün, çünkü bir gün bu hizmetten ayrılırsanız listeyi yeniden kendi kaydınıza taşımanız gerekir.

Sizin yapmadığınız değişiklikleri izlemek

Include'lar canlı referanslardır. Bir sağlayıcı kendi SPF kaydını yeniden düzenlediğinde, örneğin bölgesel bir include ya da yeni bir iş ortağı aralığı eklediğinde, bir alıcı kaydınızı bir sonraki değerlendirişinde sayınız değişir. Hiçbir bildirim almazsınız ve ilk işaret, SPF hatalarıyla dolu bir DMARC raporu olabilir. Yani kendi kaydınıza hiç dokunmamış olmanız, sorgu sayınızın değişmediği anlamına gelmez.

Basit bir önlem, sorgu sayısını düzenli olarak kontrol etmektir. SPF değerlendirmesini bir betikten ya da izleme sisteminden günde bir çalıştırın; sayı sekize ulaştığında veya bilinen bir gönderen IP için sonuç pass olmadığında uyarı verin. XGM API'si sayıyı JSON olarak döndürdüğü için bunu mevcut izleme sisteminize bağlamak kolaydır. Kontrolü kendi posta altyapınızdan bağımsız bir yerden çalıştırmak, arıza anında da uyarı almanızı güvence altına alır.

count=$(curl -s -H 'Accept: application/json' https://xgm.ro/api/v1/spf/example.com | python3 -c 'import sys, json; print(json.load(sys.stdin)["lookups"])')
if [ "$count" -ge 8 ]; then echo "SPF for example.com uses $count of 10 lookups"; fi

Her kontrolden tam include ağacının bir kopyasını saklayın. Sayı sıçradığında iki ağacı karşılaştırmak, hangi sağlayıcının değiştiğini ve bunun kalıcı bir değişiklik mi yoksa karşı tarafta bildirmeye değer bir hata mı olduğunu anında gösterir. Saklanan bu ağaçlar, sağlayıcıyla yapacağınız yazışmada elinizde somut bir kanıt bulunmasını da sağlar.

Sınırın altında kalmak

• Sağlayıcı devreye alma sürecine bir SPF incelemesi ekleyin: hangi include, kaç sorgu ve alan adınızla atılan bir DKIM imzası bu include'u gereksiz kılıyor mu.
• Her DNS değişikliğinden sonra E-posta Güvenliği aracını çalıştırın ve en az iki sorguluk pay bırakın.
• DMARC toplu raporlarını üç ayda bir gözden geçirin ve artık göndermeyen include'ları kaldırın.
• DMARC için DKIM hizalamasını tercih edin; SPF ikinci katmandır, temel değil.
• Her include'un neden var olduğunu DNS deponuzdaki bir yorumda ya da değişiklik günlüğünde belgeleyin.

SPF'in unutulması kolay ikinci bir koruması daha vardır: her ad için yalnızca tek bir SPF kaydına izin verilir. v=spf1 ile başlayan iki TXT kaydı, tıpkı fazla sorgu gibi permerror üretir ve bu durum çoğu zaman iki ekip birbirinden habersiz sağlayıcı eklediğinde ortaya çıkar. SPF rehberi diğer yaygın sözdizimi hatalarını ele alıyor. Aynı kural alt alanlar için de geçerlidir; her ad kendi başına tek kayıt kuralına tabidir.

SSS

Kaynaklar

• RFC 7208: Sender Policy Framework, §4.6.4 DNS sorgu sınırları
• RFC 7208 §3.4: Kayıt boyutu
• RFC 7208 §5.5: ptr mekanizması (kullanmayın)
• RFC 7489: DMARC
• RFC 5737: Belgeleme için ayrılmış IPv4 adres blokları