[ SPF ]

Çoklu SPF kayıtları: eski gönderenleri alıkoymadan izinleri birleştirme

Rakip SPF kayıtlarını gözden geçirilmiş tek bir politikayla değiştirin, eski veya aşırı geniş izinleri kaldırırken meşru gönderenleri koruyun.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • Birden fazla seçilen kayıt alıcılar tarafından birleştirilmez.
  • Yalnızca gerekçeli izinleri ve kasıtlı sıralamayı koruyun.
  • Sonuçları icat etmeden DNS ve temsili yolları doğrulayın.
Bu sayfada

İki SPF aynı DNS adındaki politikalar daha büyük bir yetkili gönderen listesi halinde birleştirilmez. Ne zaman SPF kaydı seçim birden fazla geçerli kayıt döndürür, değerlendirme şu şekilde sona erer: permerror altında RFC 7208 §4.5. Onarım, üçüncü bir TXT girişi değil, tutarlı bir politikadır.

Zor kısım hangi izinlerin hala ait olduğuna karar vermektir. Her mekanizmanın tek bir satıra kopyalanması, eski sağlayıcıları, aşırı ağları ve arama sınırı sorununu korurken sözdizimi hatasını ortadan kaldırabilir.

Gerçekte neyin kopyalandığını doğrulayın

Sorgu TXT kayıtları SPF kontrolü için kullanılan tam alanda. Alan doğrulama jetonları gibi diğer TXT kayıtları otomatik olarak SPF kayıtları değildir ve bu onarımın bir parçası olarak silinmemelidir. Birden çok kaynak kaydını, tek bir TXT kaydı içindeki birden çok alıntılanan karakter dizesinden ayırt edin. Altında RFC 7208 §3.3, bir kaydın içindeki dizeler birleştirilir; ayrı SPF kayıtları değildir.

Tam DNS yanıtını, TTL'yi ve yetkili sunucu bilgilerini kaydedin. Herhangi bir şeyi değiştirmeden önce ilgili bölgeyi ve sahip adını onaylayın. Bir sağlayıcı, bölge adını otomatik olarak bir ana bilgisayar alanına ekleyerek, görünüşte doğru olan bir düzenleyici girişinin yanlış isme düşmesine neden olabilir.

Amaçlanan gönderen kümesini yeniden oluşturun

Dört alanlı mekanizma başına bir satır oluşturun: iş hizmeti, sorumlu sahip, destekleyici sağlayıcı yapılandırması ve mevcut gönderimin kanıtı. Açık IP aralıkları için adresleri kimin işlettiğini ve bu aralığa neden ihtiyaç duyulduğunu tanımlayın. Dahil etmek için satıcının mevcut talimatlarını ve yinelenen politika bağımlılıklarını inceleyin. Bilinmeyen bir mekanizmayı sonsuza kadar saklama izni olarak değil, çözülmesi gereken bir soru olarak ele alın.

Bu zarf etki alanını kullanan gönderenleri, kendi zarf etki alanlarını kullanan hizmetlerden ayırın. Bir satıcının görünür Kimden adresi, trafiğinin buraya bir SPF eklenmesi gerektiğini kanıtlamak için yeterli değildir. Benzer şekilde, kısa bir gözlem döneminden uzak kalmak emeklilik anlamına gelmez: faturalar veya sezonluk kampanyalar seyrek olarak yayınlanabilir.

Düzenli bir politika oluşturun

Seçilen yetkileri ve kasıtlı bir nihai politikayı koruyun. Tüm kayıtları birleştirmeyin, bir saniye bırakın v=spf1 belirteç veya bir Tümü mekanizma ortada. Altında RFC 7208 §5.1, erken Tümü kalan tüm kaynaklarla eşleştiğinden daha sonraki mekanizmalara erişilemez.

Açıklayıcı başlangıç ​​durumu: bir kayıt v=spf1 ip4:192.0.2.10 -all; diğeri v=spf1 ip4:198.51.100.20 ~all. Her iki yalnızca belgeye yönelik adres de onaylanmış mevcut gönderenleri temsil ediyorsa, olası bir birleştirilmiş politika şu şekildedir: v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. Nihai niteleyiciyi seçmek kendi yönlendirme incelemesini gerektirir. İkinci gönderenin emekli olması durumunda, onu birleştirmek gereksiz yetkiyi koruyacaktır.

İç içe içermeler ve yönlendirmeler de dahil olmak üzere politikanın tamamını değerlendirin. Altında RFC 7208 §4.6.4RFC 7208 , değerlendirme sırasında aramaya neden olan on terimlik bir sınır uygular; yalnızca görünen include ifadelerini saymak yetersizdir. Açık ip4 Ve ip6 mekanizmaların kendisi bu dönem bütçesini tüketmez, ancak yönetilen içeriklerin kopyalanan IP listeleriyle değiştirilmesi bir bakım yükümlülüğü oluşturur.

Uzun süreli belirsiz bir durum olmadan konuşlandırın

Sağlayıcı desteklediğinde atomik DNS kayıt kümesi güncellemesini tercih edin: tek değişiklikle rakip politikaları onaylanmış tek kayıtla değiştirin. Arayüz ayrı düzenlemeler gerektiriyorsa sırayı planlayın ve politikanın eksik veya kopyalanmasıyla ilgili geçici riski kabul edin. “Geçici” ekstra bir SPF kaydı oluşturmayın ve yayılmasına izin vermeyin.

Yetkili yanıtları ve ardından ilgili özyinelemeli yanıtları doğrulayın. Önbelleğe alınan eski yanıtlar önceki tazelik aralıklarını korur; RFC 8767 §4 ayrıca geçerlilik süresi dolduktan sonra nitelikli eski yanıt kullanımına da izin verir. TTL garantili bir küresel iptal tarihi değildir. Saklanan her hizmetten temsili mesajlar gönderin ve değerlendirilen kimliği ve sonucu güvenilir bir alıcıda onaylayın. Eşsiz bir kaynağı da kontrolünüz altında test edin, böylece kazara yapılan evrensel geçişin başarı ile karıştırılmaması sağlanır.

Temizleme kanıtlarını saklayın

Değişiklik kaydı, tutulan ve kaldırılan her mekanizmayı, arama değerlendirmesini, DNS öncesi ve sonrası durumunu ve test sonuçlarını açıklamalıdır. Yinelenen kayıt uyarısı yalnızca seçili bir SPF kaydı olduğunda ve politika incelenen gönderen kümesini ifade ettiğinde kapatılır. Bu, tek seferlik DNS onarımını sürdürülebilir bir yetkilendirme envanterine dönüştürür.

Kararı ve sınırlarını kaydedin

İki adresli örnek için, bir izin çalışma sayfası, her sahibin kararını ve beklenen eşleşmeyi son niteleyiciden ayrı olarak tutmalıdır. Birleştirilmiş ~all örneği, eşleşmeyen bir adres için hala softfail değerini döndürmektedir; Daha önceki -all politikasını zayıflatmaya yönelik bir öneri değil. Bu niteleyiciyi değiştirmek açık bir karar gerektirir. Bu çizim için herhangi bir DNS güncellemesi veya teslimat testi yapılmamıştır.

[ Götürmek ]

Birden fazla seçilen kayıt alıcılar tarafından birleştirilmez. Yalnızca gerekçeli izinleri ve kasıtlı sıralamayı koruyun. Sonuçları icat etmeden DNS ve temsili yolları doğrulayın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Dizeleri değil anlambilimi birleştirin.

Kayıt sırası, niteleyiciler ve özyinelemeli bağımlılıklar birleştirme işleminden doğru şekilde geçmelidir.

Sonraki adımlar

  1. Orijinal kayıt setini kaydedin.
  2. Tutulan her hizmeti ve eşsiz bir kaynağı test edin.

CISO / SecOps

Korunan güveni gözden geçirin.

Korunan her içerme veya ağ, bir yetkilendirme kararıdır.

Sonraki adımlar

  1. Her mekanizma için sahiplik gerektirir.
  2. Kaldırılan gönderenlerin neden artık erişime ihtiyaç duymadığını kaydedin.

Kurucu / Teknik Olmayan

Olayı mülkiyeti temizlemek için kullanın.

Onarım, yalnızca denetleyiciyi susturmak değil, hangi ticari hizmetlerin hala izne sahip olduğunu belirlemelidir.

Sonraki adımlar

  1. Hizmetin kullanımdan kaldırılmasını sahiplerle birlikte onaylayın.
  2. Sık olmayan gönderme işlerini doğrulamaya dahil edin.

[ SSS ]

Sık sorulan sorular

Her satıcı için ayrı bir SPF kaydı yayınlayabilir miyim?

Aynı sahibin adına değil. Birden çok seçilmiş SPF kaydı, birleştirilmiş izinler yerine permerror üretiyor.

RFC 7208 §4.5

Diğer tüm TXT kayıtlarını silmeli miyim?

Hayır. İlgisiz doğrulama kayıtları kalabilir. Protokolün seçim kurallarını kullanarak SPF kayıtlarını tanımlayın.

RFC 7208 §4.5

Alıntılanan iki dize iki SPF kaydı mıdır?

Bir TXT kaynak kaydının içindeki karakter dizeleri olduklarında değil. İçerikleri boşluk eklenmeden birleştirilir.

RFC 7208 §3.3

Her iki politikanın tamamını birbirine yapıştırabilir miyim?

Hayır. Bir sürüm işaretçisini saklayın, mekanizma sırasını gözden geçirin ve etkili bir nihai politika seçin.

RFC 7208 §4.6 RFC 7208 §5.1

Neden her eski içeriği saklamıyorsunuz?

Satıcı yetkilerini korur ve hizmete artık ihtiyaç duyulmadığında bile değerlendirme kaynaklarını tüketir.

On görünür içerik uyumluluğu garanti ediyor mu?

Hayır. İç içe değerlendirme ve aramaya neden olan diğer terimler de sınıra dahil edilir.

RFC 7208 §4.6.4

Onarım ne zaman onaylanır?

DNS geçerli bir politikayı sunduktan ve tutulan gönderenlerden gelen temsili mesajlar beklendiği gibi değerlendirilir.

Peki ya DNS düzenleyicisi atomik olarak güncellenemiyorsa?

Geçici durumu planlayın ve belgeleyin, düzenlemeler arasındaki süreyi en aza indirin ve elde edilen kayıt kümesini anında doğrulayın.

[ Kaynaklar ]

Kaynaklar

  1. RFC 7208

    Bölümler §2.4 · §3.3 · §4.5 · §4.6 · §4.6.4 · §5.1 · §4.1

  2. RFC 8767

    Bölümler §4

[ Sözlük ]

Sözlük

SPF
İlgili SMTP kimliğine ilişkin politikaya göre bağlanan IP'nin değerlendirilmesi.

RFC 7208 §2.4

DNS TTL'si
Genel bir silme veya iptal etme son tarihi garanti edilmeyen, olağan güncellik aralığı; nitelikli servis-eski kullanım, sürenin sona ermesinden sonra devam edebilir.

RFC 8767 §4

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası