Değerlendirilen kimlikle başlayın
" -all yayınladık, bu nedenle alıcılar kimliğe bürünmeyi reddetmelidir" ifadesi üç farklı kararı birleştiriyor. Bir alan adı bir yetkilendirme politikası yayınlar, değerlendirici bir yetkilendirme politikası alır. SPF Sonuç olarak bağlantı adresi ve kimlik elde edilir ve alıcı mesajla ne yapılacağına karar verir. Bu kararların ayrı tutulması sorun gidermeyi daha doğru hale getirir ve yapılandırma değişikliğinin desteklenmeyen bir güvenlik taahhüdü haline gelmesini önler.
SPF şunları değerlendirir: HELO kimliği veya POSTA kimlik, yalnızca mesajın Kimden alanında görüntülenen adres değil. Herhangi bir politikayı yorumlamadan önce bağlantı adresini, kimlik türünü, değerlendirilen etki alanını ve saati kaydedin. Bir sağlayıcının zarf alanına ilişkin sonuç, görünür marka alanını otomatik olarak tanımlamaz. Boş bir ters yol için, kimlik işlemenin de bir ekran görüntüsünden tahmin edilmek yerine yakalanması gerekir. RFC 7208 , bölüm 2.3 ve 2.4
Tüm mekanizma aslında ne yapar?
Tüm mekanizma her zaman eşleşir. Eksi niteleyicisi ile ulaşılan -all getiriler başarısız olur. Bu ifade kesindir ancak koşulludur: Daha önceki bir eşleştirme mekanizması, değerlendirmeyi ilk önce bitirebilir ve bir hata, terminal mekanizmasına ulaşılmadan önce değerlendirmeyi kesintiye uğratabilir. Terminal jetonunu "kesin reddetme anahtarı" olarak adlandırmak her iki durumu da gizler. Bunun anlamı, her alıcının posta sisteminde yürütülen bir komut değil, bir yetkilendirme onayıdır.
Mekanizmalar belirlenen sıraya göre işlenir. İzin verilen bir adres, daha önceki bir ip4 veya ip6 mekanizmasıyla eşleşebilir ve -all ulaşmadan geçiş üretebilir. Bir içerme de eşleşebilir. Tersine, geçersiz bir politika veya tükenmiş bir değerlendirme bütçesi, permerror birisinin son jetonu okumasından beklenen başarısızlık yerine. Kaydın son karakterleri gerçek değerlendirme yolunun yerini alamaz. RFC 7208 , bölüm 4.6, 5.1 ve 8
Alt sonuçları ana sonuçlardan ayırın
Dahil etme, sonucu ana mekanizmaya eşlenen özyinelemeli bir kontroldür. Ana politikaya yapıştırılan metin değildir. Bir alt geçiş, içerme eşleşmesini sağlar; Bir çocuğun başarısız olması, softfail veya nötr olması eşleşmemesine neden olur. Ebeveyn daha sonra bir sonraki uygulanabilir mekanizmaya devam eder. Bir çocuk temperror veya permerror bir hata olarak yayılırken, alt öğenin hiçbiri içerme için permerror olarak değerlendirilmez.
Bu, bir tedarikçinin kendi politikasını -all ile sonlandırması durumunda önemlidir. Söz konusu tedarikçi tarafından yetkilendirilmeyen bir gönderici, müşterinin poliçesinin tamamını otomatik olarak başarısızlığa uğratmaz. Ana kayıtta daha sonra başka bir yetkili servis görünebilir. Alt sonucu ve ebeveyn devamını tanılama çalışma sayfasında ayrı ayrı koruyun. Aksi takdirde meşru bir çoklu hizmet tasarımı hatalı bir şekilde çelişkili veya bozuk olarak tanımlanabilir. RFC 7208 , bölüm 5.2
Alıcı politikası başka bir kanıt katmanıdır
RFC 7208 başarısızlığı, istemcinin verilen kimlikteki etki alanını kullanma yetkisine sahip olmadığının açık bir ifadesi olarak tanımlar. Sonuçları ele alma rehberliği, düzenlemeyi alıcının politikasına bırakır. Alıcı, SMTP sırasında reddedebilir, kabul edip işaretleyebilir veya sonucu diğer bilgilerin yanında kullanabilir. Kesin eylem yalnızca genel DNS ile kanıtlanamaz. Kabul raporu, yayınlanan mekanizmanın göz ardı edildiğini göstermez; değerlendirilen kimliği, daha önceki bir eşleşmeyi veya alıcının seçtiği muameleyi yansıtabilir.
Bu ayrımı gelişigüzel SPF zayıflatma tavsiyesine dönüştürmeyin. Doğru bir politika hala önemlidir. Öncelikle, yönlendirme davranışı ve üçüncü taraf gönderimi de dahil olmak üzere meşru rotaların envanterini çıkarın, ardından yetkilendirme uyumsuzluğunu belirli bir alıcı tarafından seçilen işlemden ayırın. Hakkında iddialar DMARC ayrıca kendi kimlik uyumuna ve politika kanıtlarına da ihtiyaç duyar. SPF başarısızlığı tek başına tam bir DMARC tanısı değildir. RFC 7208 , bölüm 8.4 ve 10
Önerilen bir inceleme için kabul çalışma sayfası
Ekran görüntüsü başına bir satır değil, yetkili mesaj örneği başına bir satır oluşturun. Rota sahibini, bağlantı adresini, HELO adını, zarf göndereni, değerlendirilen etki alanını, kesin bilgileri yakalayın TXT kaydı ayarlama, alma zamanı, ayrıştırıcı sürümü ve son SPF sonucu. Sıralı mekanizma yolunu ekleyin ve değerlendirmenin neden durdurulduğunu açıklayın. Alıcınınkini koruyun Authentication-Results güven sınırı ve kaynağı, gönderen tarafından sağlanan güvenilmeyen başlıktan ayrıdır.
Düzenleme için ikinci bir bölüm ekleyin: Varsa SMTP yanıtı, alıcı sistem, zaman damgası, kuyruk veya olay tanımlayıcı ve kanıtın kabul, ret, karantina veya yalnızca başvuru durumunu gösterip göstermediği. Gereksiz alıcıları ve mesaj içeriğini çıkarın. Gönderen bir uygulamanın "teslim edildi" durumu, gelen kutusu yerleşimini otomatik olarak oluşturmaz. Kullanılamayan alanları beklentilere göre doldurmak yerine, kullanılamaz olarak işaretleyin.
İnceleme yalnızca gerçekten kanıtlanan iddiayı geçer. Tam bir politika takibi, alıcı yönetimi çözümsüz kalırken bir SPF sonucunu destekleyebilir. SMTP reddi, tüm alıcıların aynı şekilde davrandığını kanıtlamadan belirli bir işlemin sonucunu belirleyebilir. Bu iki kabul kararını bağımsız olarak kaydedin ve eksik deliller için sahibini koruyun.
Kurgusal teşhis: iki hizmet ve bir terminal arızası
Bir haber bülteni tedarikçisini, ardından işlem tedarikçisini ve ardından -all kontrol eden ana politikası olan kurgusal bir kuruluş düşünün. Bu örnek için DNS sorgulanmadı ve mesaj gönderilmedi. Haber bülteni alt öğesi, bir işlem adresi için başarısız oluyor. Bir sonraki doğru adım, nihai bir başarısızlık bildirmek değil, ebeveyni devam ettirmektir. İşlemsel içerme getirileri geçerse, olağan pozitif dahil etme eşleşmeleri ve üst öğe getirileri geçer.
Şimdi hiçbir tedarikçiyle eşleşmeyen farklı bir adres hayal edin. Daha önce bir hata oluşmazsa, değerlendirme -all ulaşır ve başarısız olur. Belirli bir alıcının bu mesajı reddedip reddetmediği ayrı bir gözlemdir. “Tedarikçinin -all bizi engelledi” şeklinde bir destek notu ilk durumda erken, ikinci durumda ise eksik olacaktır. Yararlı düzeltme, alt sonucu, ana sonucu ve alıcı eylemini ayrı ayrı etiketlemektir.
Üçüncü bir varsayımsal durumda, ilk tedarikçiyi değerlendirirken geçici bir DNS hatası yaşandı. Politika doğrudan final -all öğesine atlanarak teşhis edilemez. Hata yolunu koruyun ve yalnızca tercih edilen bir yorumu zorlamak için kaydı değiştirmekten kaçının. Bu örnekler yalnızca akıl yürütmeyi göstermektedir; bunlar alınan mesaj kanıtı veya test edilmiş sonuçlar değildir.
Yayın ve operasyonel bekletmeler
Bu yazı herhangi bir gerçek göndericinin veya alıcının davranışını belirlemez. Operasyonel bir tanı yayınlamadan önce, kataloğun gerektirdiği sonuca özel örnekleri ve bunların DNS veya mesaj kanıtlarını yetkili bir iş akışı aracılığıyla edinin. Nitelikli bir incelemeci tüm yolu incelemeli ve alıcı kanıtlarının aynı işlem ve zaman penceresine ait olduğunu doğrulamalıdır.
Değişiklikleri tanıdan ayrı tutun. Meşru bir hizmeti kaldırmak, niteleyicileri değiştirmek veya geniş yetkilendirme eklemek gerçek postayı etkileyebilir ve kendi incelemesini gerektirebilir. Taslağın orijinal kanıtları, insan uzmanlığı, kaynağın uygulanabilirliği, üretim rotası, görsel erişilebilirlik ve sahibin serbest bırakılması kapıları açık kalıyor. Kurgusal bir örnek, mantığı standartlara uygun olsa bile bu kapıların yerini tutamaz.