Bir SPF Paylaşılan bir e-posta hizmeti için dahil edilmesi, birçok müşteri tarafından kullanılan altyapıyı yetkilendirebilir. Hizmet genellikle bu şekilde tasarlanır, ancak izin net bir açıklamayı hak eder. SPF bağlanan ana bilgisayarı bir etki alanı politikasına göre kontrol eder; geniş pozitif eşleşme, kiracıya özgü bir şifreleme kimlik bilgisi değildir.
Pratik soru, sağlayıcınızın başka bir müşterinin SMTP kimliğinizle gönderim yapmasını engelleyip engellemediği ve politikanın yalnızca kullanımınızın gerçekten ihtiyaç duyduğu altyapı izinlerini verip vermediğidir.
Güven ilişkisinin haritasını çıkarın
Dahil edilen veya paylaşılan her IP aralığı için hizmeti, işletme sahibini, desteklenen zarf etki alanını ve belgelenen sağlayıcı kurulumunu kaydedin. Postanızın sağlayıcıya ait bir zarf etki alanı mı yoksa sizin kontrol ettiğiniz özel bir etki alanı mı kullandığını belirleyin. Sağlayıcı, değerlendirilen alanın gerçek sahibiyse, kök alanınıza bir ekleme eklemek, o mesajın SPF sonucunu hiç etkilemeyebilir.
Etki alanı doğrulaması ve gönderen kontrolleri için sağlayıcının mevcut belgelerini okuyun. Dokümantasyonun net olmadığı durumlarda, hizmet sahibi veya sağlayıcı desteği için soruyu tanımlayın. Sadece kendi hesabınızdan yapılan bir test başarılı olduğu için tüm kiracıların izole edildiğini iddia etmeyin.
IP tabanlı kararın sınırını anlayın
RFC 7208 §11.4 Paylaşılan bir sistemin, kullanıcıların diğer kullanıcıların kimliklerini talep etmesine izin verdiği durumlarda, kullanıcılar arası sahtecilik risklerini açıklar. Bir SPF geçişi, iletiyi hangi müşteri hesabının başlattığını kanıtlamadan, bağlanan ana bilgisayarın değerlendirilen alan için yetkili olduğunu belirleyebilir. Bu nedenle sağlayıcı tarafı yaptırımı güvenlik sınırının bir parçasıdır.
Bu, her paylaşılan hizmetin güvensiz olduğu anlamına gelmez. Bu, yetkilendirme modelinin iki katmana sahip olduğu anlamına gelir: DNS altyapıya izin verir ve hizmetin, müşterilerin bu altyapıdaki kimlikleri kullanma şeklini kısıtlaması gerekir. Bir katmana ait delil diğerine delil olarak sunulmamalıdır.
Desteklenen en dar yapılandırmayı seçin
Bu tür ayrımların belgelendiği, gönderen ürününüz ve bölgeniz için sağlayıcının desteklediği tam dahil etme veya alan adı yapılandırmasını tercih edin. Daha dar kapsamlı bir bakım ilkesi mevcut olduğunda satıcının ağ tahsisinin tamamını eklemekten kaçının. Bu tasarımı güvenli bir şekilde sürdüremediğiniz sürece, daha dar kapsamlar icat etmeyin veya satıcı tarafından yönetilen politikayı IP'lerin anlık görüntüsüyle değiştirmeyin.
Özel bir dönüş yolu alt alan adı, bir hizmetin SPF politikasını diğer postalardan ayırabilir. Sahipliği ve yaşam döngüsü yönetimini iyileştirir, ancak tek başına sağlayıcıyı paylaşan müşteriler arasında izolasyon sağlamaz. Diğer kimlik doğrulama ve hesap kontrollerini tasarımın ayrı parçaları olarak inceleyin.
İki konfigürasyonu dikkatlice karşılaştırın
Açıklayıcı örnek: v=spf1 ip4:192.0.2.0/24 -all değerlendirilen kimlik için bu dokümantasyon ağındaki her IPv4 adresine yetki verir. Yalnızca politika adlandırma ip4:192.0.2.10 bir adrese yetki verir. Daha dar politika kaynak kümesini azaltır, ancak yalnızca sağlayıcının hizmetiniz için bu adresi gerçekten garanti etmesi durumunda kullanışlıdır. Desteklenmeyen bir kısıtlama, yük devretme sırasında meşru teslimatı bozabilir.
Altında RFC 7208 §5.2, bir içerme başvurulan bir politikayı değerlendirir; mevcut genişlemesi kalıcı bir sözleşme değil, bir gözlemdir. Sağlayıcı politikasını değiştirdiğinde değişebilir. Bugünün çözümlenen adreslerini nihai gerçekmiş gibi ele almak yerine bağımlılığı ve sahipliği yakalayın.
Diğer kiracıları test etmeden inceleyin
Doğrulama için kendi yetkili hesaplarınızı ve kontrollü alıcılarınızı kullanın. Beklenen kimliklerinizi doğrulayın ve hangi altyapının geçiş ürettiğini kaydedin. Kiracı kısıtlamalarını belgeler, onaylı yapılandırma kanıtları veya açıkça yetkilendirilmiş bir güvenlik testi aracılığıyla değerlendirin. Teorik bir kaygıyı göstermek için başka bir müşterinin alan adını taklit etmeye çalışmayın.
Yeni içermeleri, alışılmadık derecede geniş ağ aralıklarını ve sahibi olmayan hizmetleri izleyin. Bir politika incelemesi aynı zamanda özyinelemeli değerlendirme sınırlarını da kontrol etmelidir; çünkü birden fazla paylaşılan sağlayıcı, her bir ekleme ayrı ayrı yasal olsa bile kaynak sorunu yaratabilir.
Kabul kararını açıkça belirtin
Verilen altyapı izninin, sağlayıcı tarafı kimlik kontrollerinin, bilinen kanıt boşluklarının ve sorumlu sahibin kısa bir kaydını tutun. Sağlayıcı veya hizmet yapılandırması değiştiğinde incelemeyi planlayın. Paylaşılan altyapıyı kabul etmek makul olabilir ancak karar, yalnızca yeşil SPF rozeti yerine tam güven modeline dayanmalıdır.
Bir sonraki kararı kaydedin
İki kanıt satırı kullanın: altyapı izni (gerçek politika, zarf etki alanı ve gözlemlenen kaynak) ve kiracı kontrolü (belgelenmiş doğrulama/yürütme, yapılandırma kanıtı ve çözülmemiş boşluklar). Kendi başarılı SPF sonucunuz yalnızca ilk satırı doldurur. Sağlayıcı tarafından daha dar bir adres garanti edilmiyorsa, desteklenmeyen bir kısıtlamayı doğrulanmış bir güvenlik iyileştirmesi olarak değerlendirmeyin. Kiracılar arası test veya sağlayıcı değişikliği yapılmadı.