[ Taşıma güvenliği ]
TLS-RPT raporlama hedefleri ve rapor teslimi
Onaylanmış mailto veya HTTPS toplama yollarını, rapor bütünlüğünü, zamanlamayı ve işleme sorumluluklarını, garantili kopya teslimatı üstlenmeden tanımlayın.
EmailAuth araştırma ekibi tarafından · 8 dakikalık okuma
[ Anahtar noktalar ]
- TLS-RPT toplama ve aktarım uygulaması ayrı bağımlılıklardır.
- Birden fazla rua hedefi, her uç noktada bir kopyayı garanti etmez.
- Makbuz, bütünlük, ayrıştırma ve ilişkilendirmeyi ayrı aşamalar olarak doğrulayın.
[ Götürmek ]
Raporlama hedefini, onaylanmış veri paylaşımı ve gözlemlenebilir teslimattan işleme aşamalarına sahip, sahip olunan bir hizmet sözleşmesi olarak değerlendirin.
[ 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
Raporu koleksiyon aracılığıyla takip edin
Uç nokta kabulü, başarılı ayrıştırmayla aynı şey değildir.
Sonraki adımlar
- Tam raporlama kaydını ve desteklenen URI'leri doğrulayın.
- Rapor tanımlayıcılarını alma yoluyla koruyun.
- Sıkıştırmayı, bütünlüğü ve ilişkilendirmeyi ayrı ayrı kontrol edin.
CISO / SecOps
Raporlama kanalını onaylayın ve koruyun
Raporlar operasyonel meta veriler ve güvenilmeyen içerik taşır.
Sonraki adımlar
- Üçüncü taraf alıcıları ve saklamayı onaylayın.
- Gerekli SMTP rapor imza kontrollerini koruyun.
- Rapor aktarımının her zaman şifrelendiğini varsaymaktan kaçının.
Kurucu / Teknik Olmayan
Tahsilat sorumluluğunu atayın
Bir hedefin yayınlanması, herhangi bir kişiyi arızalar karşısında harekete geçmekten sorumlu kılmaz.
Sonraki adımlar
- Toplayıcıyı ve olay sahibini adlandırın.
- Arşiv ve kontrol paneli ilişkisini tanımlayın.
- Gerçekçi katılım ve zamanlama beklentileri belirleyin.
[ SSS ]
Sık sorulan sorular
TLS-RPT kaydı nerede yayınlanır?
Politika alanı altındaki _smtp._tls adresinde, TLSRPTv1 sürümü ve rua hedefleriyle TXT kullanılıyor. Bu MTA-STS politika dosyasından ayrıdır.
RFC 8460 hangi hedef planlarını destekler?
Desteklenen şemalar mailto ve https'dir. HTTPS raporları POST'u kullanır; mailto raporları belirtilen posta kutusu dağıtım yolunu kullanır.
Harici bir hedef DMARC tarzı bir yetkilendirme kaydı gerektiriyor mu?
RFC 8460 DMARC tarzı DNS anlaşmasını tanımlamaz. Organizasyonel onayı ve koleksiyoncuya özel katılımları ayrı ayrı onaylayın; bir protokol kaydı icat etmeyin.
İki rua URI'nin her biri her raporu alacak mı?
Mutlaka değil. Bir muhabir birden fazla desteklenen hedefi deneyebilir veya birini seçebilir. Bir uç noktada başarılı bir kabul, teslimatı tatmin edebilir.
SMTP raporlarına hangi bütünlük kontrolü uygulanır?
l=. olmadan geçerli bir raporlama alanı DKIM imzası gerektirirler. Anahtar s=tlsrpt; alıcı, bu hizmet beyanının bulunmadığı raporları göz ardı edebilir.
HTTPS onayı işlemenin başarılı olduğunu kanıtlar mı?
Hayır. Başarılı bir yanıt teslimatı onaylar ve toplayıcı daha sonra işlem yapabilir. Kuyruk, ayrıştırıcı ve ilişkilendirme sonuçlarını ayrı ayrı izleyin.
Günlük raporlar garanti ediliyor mu?
Hayır. Tam bir UTC günü aralığı ve gecikmeli teslimat önerilir, ancak raporlar isteğe bağlıdır ve evrensel bir günlük alındı vaadi yoktur.
İki geçerli TLS-RPT ilkesi kaydı yayınlanırsa ne olur?
" v=TLSRPTv1; " harfi önekiyle başlamayan TXT kaynak kayıtlarını attıktan sonra gönderenin kalan tam olarak bir kayıt bulması gerekir. Sıfır veya birden fazla bulursa RFC 8460 , TLS-RPT uygulanmadığını varsaymasını gerektirir. Kayıt sınırları önemlidir: bir TXT kaydındaki birden fazla dize, tek başına birden fazla politika kaydı anlamına gelmez.
[ Kaynaklar ]
Kaynaklar
- RFC 8460
Bölümler §3. Raporlama Politikası · §4.1 Rapor Zaman Çerçevesi · §4.3 Sonuç Türleri · §5.2 Sıkıştırma · §5.3 E-posta Aktarımı · §5.4 HTTPS Aktarımı · §5.5 Teslimatı Yeniden Deneme · §5.6 Meta Veri Farklılıkları · §7. Güvenlik Hususları
[ Sözlük ]
Sözlük
- Rapor tanımlayıcı
- Bir raporu tanımlamak ve mükerrer gönderimlerin tespit edilmesine yardımcı olmak için kullanılan meta veriler.
- Koleksiyoncu sözleşmesi
- Hedef mülkiyeti, veri işleme ve işleme kanıtlarını kapsayan teklif edilen anlaşma.
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.
SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi