Ne zaman iki SPF Damalar farklı arama sayılarını gösterir, daha güven verici sayıyı seçmeyin. Her aracın neyi ölçtüğünü belirleyin. Biri, DNS'ye bağlı terimleri değerlendirilen bir yolda görüntüleyebilir, diğeri bir politika grafiğini genişletebilir ve üçüncüsü ağ sorgularını gösterebilir. Bu çıktılar aynı alanı inceleseler bile farklı sorulara cevap verebilirler.
Sayacın ne anlama geldiğini sorun
RFC 7208 bölüm 4.6.4 özyinelemede değerlendirilen DNS'ye bağımlı terimleri sınırlar. Bu sadece tüm TXT dizelerinin, her DNS paketinin veya en üst düzeyde gözle görülür şekilde yazılan içeriklerin sayısı değildir. Önbelleğe alınan yanıtlar daha büyük bir mantıksal dönem bütçesi sağlamaz.
Diğer kısıtlamaları da ayırın. Spesifikasyon adresleri geçersiz aramalar ve ana değerlendirilen dönem tavanına ek olarak mekanizmaya özgü limitler. Bir araç birleştirilmiş bir uyarı sunarken, bir diğeri her bir kategoriyi ortaya çıkarabilir. Her kırmızı etiketin aynı anlama geldiğini varsaymak yerine, uyarı metnini ve belgeleri tam olarak saklayın.
Her iki alete de aynı fikstürü verin
Değerlendirilen etki alanını, bağlantı IP'sini, gönderenin kimliğini kaydedin, HELO İlgili olduğu yerde, çözümleyici görünümü ve sorgulama süresi. Araç yalnızca bir alanı kabul ediyorsa, sayımının statik bir tahmin mi, en kötü durum analizi mi yoksa belirli bir sentetik yol mu olduğunu öğrenin. Yalnızca etki alanına yönelik tarama, otomatik olarak gerçek bir bağlantıyı değerlendirmeye eşdeğer değildir.
Makro kullanan politikalar için eksik kimlik girişleri doğrudan önemli olabilir. Her ikisi de meydana geldiğinde IPv4 ve IPv6 durumlarını ayrı ayrı karşılaştırın. DNS yanıtlarını veya tekrarlanabilir kontrollü bir fikstürü koruyun, böylece daha sonraki bir sağlayıcı değişikliği, varsayılan bir araç karşılaştırmasını farklı politikaların karşılaştırmasına dönüştürmez.
Küçük açıklayıcı bir örnek yürüyün
Sentetik bir politika düşünün:
v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all
Altında RFC 7208 §4.6.2 Ve RFC 7208 §5.6192.0.2.10 için açık adres, içerme değerlendirilmeden önce eşleşebilir. Başka bir adres için değerlendirme, include ve onun iç içe geçmiş bağımlılıklarına ulaşabilir. Bir grafik genişletme aracı, ilk mesajın yolu ona hiç ulaşmasa bile bu dalı görüntüleyebilir. Farklı sayıların açıklanması gerekir, her iki aletin de kusurlu olduğuna dair otomatik bir karara değil.
Sayısal sayıları karşılaştırmak için dahil etme hedefini açık hale getirin. Bu sentetik fikstürde, _spf.vendor.example tam olarak bir SPF sahip TXT kaydı, v=spf1 ip4:192.0.2.20 -all. DNS alımının başarılı olduğunu, söz diziminin geçerli olduğunu, ek bağımlılıkların olmadığını ve sıradan olduğunu varsayalım. POSTA ana etki alanı için değerlendirme.
- Giriş 192.0.2.10 : ebeveynin ilk ip4 mekanizması eşleşir. Gerçek yol, DNS'ye bağlı 0 terimi değerlendirir ve hiçbir zaman içermeyi ziyaret etmez.
- Giriş 192.0.2.20 : ebeveynin ip4'ü eşleşmiyor. Dahil etme değerlendirilir, hedefi ip4 eşleşir ve ebeveyn, pass değerini döndürür. Gerçek yol, DNS'ye bağlı 1 terimi (include) değerlendirir.
- Giriş 192.0.2.30 : içerme hedefi -all ulaşır ve başarısız olur, dolayısıyla dahil etme eşleşmez. Ebeveyn kendi -all ulaşır ve geri dönüşler başarısız olur. Gerçek yol hala 1 DNS'ye bağlı terimi değerlendiriyor; şu şekilde tutarlı: RFC 7208 §5.2.
Hangi bağlantının seçildiğine bakılmaksızın, bu fikstürün tamamı için DNS'ye bağlı terimlerin statik grafik sayısı 1'dir. Ana politikanın ilk TXT alımı gereklidir ancak kendisi bu sınıra göre sayılan değerlendirilen terimlerden biri değildir. Böylece birinci giriş için 0 ve genişletilmiş grafik için 1 gösteriminin her ikisi de açıklanabilir. Bunlar analitik olarak beklenen sonuçlardır, gerçekleştirilen ölçümler veya ağ paketi sayımları değildir.
Şimdi, dahil edilen politikanın iki tarama arasında değiştiğini hayal edin. Yeni bir tarama, yasal olarak farklı bir bağımlılık ağacını ortaya çıkarabilir. Anlaşmazlığı artırmadan önce zaman damgalarını ve gerçek yanıtları kaydedin. Girdi içermeyen bir ekran görüntüsü zayıf kanıttır.
İlk ıraksamadaki izleri karşılaştırın
Değerlendirilen terimlerin yan yana bir listesini oluşturun. Araçların anlaşamadığı ilk yeri bulun: kayıt seçimi, erken eşleşme, özyineleme, DNS hatası, makro genişletme veya sayma kuralı. Birinin bir hatada durup durmadığını, diğerinin teşhis amacıyla devam edip etmediğini kontrol edin. Tanısal bir genişletme, geçerli bir tamamlanmış değerlendirmeyi temsil etmeden faydalı olabilir.
Bir takımın standartla çeliştiği görülüyorsa, minimum düzeyde sentetik bir fikstür ve kesit referansıyla beklenen davranışı üretin. Bir fikstürün yapacağı yerde gizli üretim verilerinden kaçınarak bunu normal destek süreciniz aracılığıyla takım bakımcısına gönderin. Tutarsız gösterge tablolarının uyumlu olması için üretimi değiştirmeyin.
Çözülmüş kanıtlardan karar verin
Bir gönderici için geçerli bir kısa yol, her göndericinin sağlığını sağlamaz. Temsili yasal girdileri ve eşleşmeyen girdileri test edin ve daha sonra değişebilecek bağımlılıkları inceleyin. Tersine, büyük bir statik grafik tek başına her mesajın değerlendirilen terim sınırını aştığının kanıtı değildir.
Hangi ölçümün kararınızı desteklediğini, çözümlenmemiş araç sınırlamalarını ve önerilen değişikliğin beklenen etkisini kaydedin. Kullanmak mekanizma siparişi ancak bu yolları anladıktan sonra. Sonuç olarak ortaya çıkan bir tutarsızlığı uzlaştıramıyorsanız, açıklanamayan bir sayıyı kesinlik olarak sunmak yerine mevcut kanıtları saklayın ve uygulamaya özel bir inceleme isteyin.
Kararı yazılı hale getirin
Verilen iki kayıt fikstürü için ana ve alt metinleri, giriş adresini, sayım tanımını ve beklenen başarılı/başarısız bilgilerini saklayın. 0/1/1 değerleri, ölçülen DNS paketleri veya bağımsız araç yürütmesi değil, analitik olarak değerlendirilen dönem sayılarıdır. Bir araç farklı bir miktar bildiriyorsa, karşılaştırmadan önce bunu etiketleyin. Hata işleme yolundaki bir tutarsızlık, bu başarılı aramalardan çıkarım yapmak yerine kendi fikstürüne ihtiyaç duyar.