[ Raporlar ve soruşturma ]

Rapor tanımlayıcıları, raportör adları ve raporlama dönemleri

Çakışan pencereleri aynı kanıtlarla karıştırmadan rapor teslimatlarını tekilleştirin.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • Rapor kimliğini, yük kaynağı ve varış zamanını ayrı tutun.
  • Kesin tekrarları ve kısmi örtüşmeleri ayrı kararlar olarak ele alın.
  • Görüntülenen her toplamı açık bir dahil etme politikasına göre izlenebilir hale getirin.
Bu sayfada

Aynısı toplu rapor iki kez gelebilir ve farklı raporlar çakışan dönemleri kapsayabilir. Bunları ayrı sorunlar olarak ele alın. Verileri sayıp saymayacağınıza veya atacağınıza karar vermeden önce raporlayanın kimliğini, rapor kimliğini, politika alanını, raporlama aralığını ve yük kaynağı kaynağını koruyun.

Tanımlayıcıları bağlamlarıyla birlikte okuyun

Referanslar: RFC 9990 §3.5.1, RFC 9990 §3.1.1.3.

RFC 9990 Rapor Kimliğinin aynı alana yönelik raporlar arasında benzersiz olmasını gerektirir ve bu tanımlayıcının yinelenen kopya tespitini nasıl desteklediğini açıklar. Bireysel bir e-postanın mesaj kimliği değildir. Raporlayan kuruluşun adı yararlı bir bağlamdır ancak görünen etiket tek başına güçlü bir kaynak kanıtı değildir.

Orijinal eki, içerik karmasını, varış saatini ve ilgili teslimat kaynağını report_metadata ile birlikte saklayın. Politika etki alanını ve normalleştirilmiş başlangıç ​​ve bitiş değerlerini koruyun. Seçtiğiniz herhangi bir bileşik veritabanı anahtarını, spesifikasyonun benzersizlik gereksiniminin yerine geçecek bir ürün olarak değil, bir besleme tasarımı olarak değerlendirin.

Raporlama dönemini varış zamanından ayırın

Referanslar: RFC 9990 §3.1.1.4.

Başlangıç ​​ve bitiş değerleri, çağdan bu yana saniye cinsinden bir UTC raporlama aralığını tanımlar. Bunlar ilk ve son gözlemlenen mesajların zaman damgaları değildir. Teslim süresi daha geç olabilir ve bir aralık, bir dağıtımı veya DNS politikası değişikliğini kapsayabilir.

Orijinal sayıları ve UTC gösterimini korurken, insan gösterimi aralığını dönüştürün. Bir muhabirin penceresini yerel takvim gününüzle eşleşecek şekilde sessizce yeniden etiketlemeyin. Görünür bir günlük hacim değişikliği, gerçek bir gönderme değişikliğinden ziyade, aralık uzunluğu veya gecikmeli varış sorunu olabilir.

Kopyaları ve çakışmaları ayrı ayrı ele alın

Referanslar: RFC 9990 §3.5.4.

Örnek durum: iki teslimat aynı rapor kimliğine ve aynı sıkıştırılmış XML karmasına sahiptir. İkincisi, sayıları tekrar eklenmeksizin mükerrer fiş olarak kaydedilebilir. İşleme kararının denetlenebilir olması için geldiği gerçeğini koruyun.

Şimdi ikinci bir raporun kısmen örtüşen bir aralığı kapsadığını ancak farklı sayımlara sahip olduğunu varsayalım. Toplu veriler genellikle hangi bireysel mesajların çakıştığını belirlemez; dolayısıyla saatlerin yarısının çakışması nedeniyle sayının yarısını çıkarmak yersizdir. RFC 9990 kısmi örtüşmenin belirsizliğine dikkat çeker. Bir dahil etme politikası seçin ve belgeleyin, ortaya çıkan sınırlamayı işaretleyin ve toplamı tekilleştirilmiş gerçek olarak sunmaktan kaçının.

İçeriği değiştirilen yeniden kullanılan bir rapor kimliği, otomatik reddetme veya değiştirme yerine incelemeyi hak eder. Her iki versiyonu da saklayın, dönemi ve satırları karşılaştırın ve hangi kanıtların görüntülenen toplamlara katkıda bulunduğunu kaydedin. Buradaki senaryolar sentetiktir ve herhangi bir gerçek muhabirin davranışını belirlemez.

Besleme kararlarını geri alınabilir hale getirin

Kabul edilen, tam kopya, çakışan kimlik, kısmen örtüşen ve geçersiz raporlar için ayrı durumları koruyun. Her kontrol paneli toplamından dahil edilen kayıtlara tekrarlanabilir bir bağlantı tutun. Orijinal kanıtları yalnızca derlemenin dışında bırakıldıkları için yok etmeyin.

Yetkili bir kanal mevcut olduğunda tekrarlayan anormallikleri raporlama kaynağıyla birlikte inceleyin. Sorun çözülene kadar kapsamı dürüstçe açıklayın. Güvenilir bir toplam, bu seçenekleri tek bir sayının arkasına saklamak yerine, zaman penceresini açıklar, muhabirlere katkıda bulunur ve politikayı kopyalar.

Beş makbuzun sayısal olarak mutabakatını yapın

Bu açık sentetik besleme politikasını kullanın: tüm faturaları koruyun; tam normalleştirilmiş yük tekrarlarını hariç tutun; Bir muhabir değişen içerikli bir kimliği yeniden kullandığında her iki veri yükü versiyonunu da dışarıda tutun; ve daha sonra kısmen örtüşen bir raporu bu özel karşılaştırma toplamından hariç tutun. Diğer belgelenmiş politikalar da mümkündür.

Alıcı A, politika alanı brand.example , pencere 0-86400 ve sayım 10 için kimlik 42'yi gönderir: toplam 10. Aynı ikinci alındı bilgisi sıfır ekler: toplam 10. Yeniden kullanımın benzersizlik kuralına uygun olduğunu iddia etmek yerine çapraz raporlayıcılar tanımlayıcı çarpışmasını modellemek için, alıcı B aynı pencere üzerinden sayım 7 ile kimlik 42'yi gönderir: bunu farklı bir raporlayıcı olarak dahil edin ve 17'yi verin. A daha sonra sayımla birlikte kimlik 42'yi gönderir 12: her iki A versiyonunu da tutun, toplamı 7'ye revize edin. B, 43200-129600 penceresi üzerinden ID 43'ü gönderir ve sayar 9: kısmi örtüşmeyi hariç tutun ve işaretleyin, geriye 7 kalır. Pencereler sentetik geçen dönem saniyeleridir.

Sağlanan yerel aritmetik alıştırması toplam 10, 10, 17, 7 ve 7'yi yeniden üretir. Son sayı, dünya çapındaki benzersiz mesajları değil, dahil edilen alıcı gözlemlerini temsil eder. Kısmi örtüşme olmadığı sonucuna varılır ve hariç tutulan veriler inceleme için kullanılabilir durumda kalır.

Egzersizi kapsam dahilinde tutun

Örnekler kısmi alan projeksiyonlarıdır; şema açısından geçerli raporlar veya ölçülen trafik değildir. Yerel kontroller, açıkça sağlanan kimlik doğrulama sonuçlarını ve organizasyonel ilişkileri kullanır; DNS keşfi yapmazlar, SPF değerlendirme, kriptografik doğrulama, rapor alımı veya alıcı teslim testleri. Üretim değişikliği yapmadan önce orijinal raporu ve güvenilir mesaj kanıtlarını koruyun.

[ Götürmek ]

Rapor kimliğini, yük kaynağı ve varış zamanını ayrı tutun. Kesin tekrarları ve kısmi örtüşmeleri ayrı kararlar olarak ele alın. Görüntülenen her toplamı açık bir dahil etme politikasına göre izlenebilir hale getirin.

[ 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

Besleme kararlarını izlenebilir tutun

Kimlikler, karmalar ve dönemler birbiriyle ilişkili ancak farklı sorunları çözer.

Sonraki adımlar

  1. Orijinal yük kaynağını saklayın.
  2. Değiştirilen içeriği tek bir kimlik altında işaretleyin.
  3. Dahil etme ve hariç tutma kararlarını kaydedin.

CISO / SecOps

Aşırı iddiada bulunmadan kanıtları koruyun

Muhabir etiketleri ve toplu pencereler, mesajın eksiksiz veya benzersiz bir şekilde kapsandığını kanıtlamaz.

Sonraki adımlar

  1. Kaynak güvenini inceleyin.
  2. Kanıt saklamayı kontrol edin.
  3. Çakışmalardan kaynaklanan sonuç kesintilerini denetleyin.

Kurucu / Teknik Olmayan

Toplamın neleri kapsadığını sorun

Hacim trendleri tutarlı zaman ve besleme kurallarına ihtiyaç duyar.

Sonraki adımlar

  1. Aralık uzunluklarını gözden geçirin.
  2. Teslimat gecikmesini trafik değişikliğinden ayırın.
  3. Etkilenen toplamların yanında sınırlamalar gerektirir.

[ SSS ]

Sık sorulan sorular

report_id bir mesaj tanımlayıcısı mı?

Hayır. Birçok mesajı özetleyebilecek bir raporu tanımlar.

RFC 9990 §3.5.1

Yalnızca report_id kullanarak tekilleştirme yapabilir miyim?

Çarpışmaların veya değişen yüklerin araştırılabilmesi için raporlayıcıyı, politika alanını, dönemi ve içerik kaynağını koruyun.

RFC 9990 §3.5.1 RFC 9990 §3.5.4

Başlangıç ​​ve bitiş mesajı zaman damgaları mı?

Hayır. Raporlama aralığını UTC dönemi saniyesi cinsinden tanımlarlar.

RFC 9990 §3.1.1.4

Geç varış raporlama dönemini değiştirir mi?

Hayır. Varış saatini raporda açıklanan süreden ayrı tutun.

RFC 9990 §3.1.1.4

Örtüşen saatler orantılı olarak çıkarılabilir mi?

Hayır. Toplu sayımlar, mükerrer bireysel mesajların dağılımını ortaya çıkarmaz.

RFC 9990 §3.5.4

Ya aynı kimlik XML'i değiştirmişse?

Her iki yükü de saklayın ve değiştirmeden veya otomatik olarak saymadan önce araştırın.

Mükerrer makbuzların silinmesi gerekir mi?

Saklama politikası kapsamında hariç tutma kararını denetlemek için yeterli kaynağı koruyun.

Bir bütünün tekrarlanabilir olmasını sağlayan şey nedir?

Rapor seti, yinelenen politika ve izlenebilir kaynak sayımlarını içeren açık bir zaman penceresi.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9990

    Bölümler §3.1.1.3 · §3.1.1.4 · §3.5.1 · §3.5.4

[ Sözlük ]

Sözlük

Rapor Kimliği
Aynı etki alanına gönderilen raporlar arasında benzersiz olması gereken bir rapor tanımlayıcı; bireysel bir e-posta tanımlayıcısı değildir.

RFC 9990 §3.5.1

Raporlama dönemi
İlk ve son gözlemlenen mesaj zaman damgalarıyla değil, başlangıç ​​ve bitiş dönemi saniyeleriyle açıklanan UTC aralığı.

RFC 9990 §3.1.1.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ı