[ Taşıma güvenliği ]

Bir denetleyiciyi her teslimat yolunun kanıtı olarak değerlendirmeden taşıma güvenliğini test edin

Aktarım denetleyicisi çıktısını, neyin gözlemlendiğini, neyin çıkarıldığını ve hangi teslimat yollarının test edilmeden kaldığını tanımlayan kapsamlı bir test kaydına dönüştürün.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • İlgili her MX , adres ailesinin ve gönderen durumunun envanterini çıkarın.
  • İlkeyi, uç noktayı ve doğrulama bağlamını tam olarak koruyun.
  • Başka bir rotadan geçiş almak yerine, denenmemiş yolları test edilmemiş halde tutun.
Bu sayfada

Aktarım denetleyicisi, kuruluşunuzun gönderdiği veya aldığı her iletinin güvenliğini kanıtlamadan gerçek bir sorunu keşfedebilir. Çoğu kontrol, belirli bir çözümleyici ve doğrulama yöntemini kullanarak belirli bir zamanda seçilen bir uç noktayı gözlemler. Bu nedenle savunulabilir bir sonuç, yalnızca geçiş rozetini değil, kapsamı ve eksik kapsamı da içerir.

Teslimat rotası envanterini tanımlayın

Referanslar: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.

Alıcı etki alanlarını, MX ana bilgisayar adlarını, öncelikleri, IPv4 ve IPv6 adreslerini, barındırılan ağ geçitlerini ve yük devretme yollarını listeleyin. Testin sıradan MX yönlendirmesini mi yoksa açıkça yapılandırılmış bir akıllı ana bilgisayarı mı takip ettiğini unutmayın. Gönderenin uygulamasını ve destekleyip desteklemediğini kaydedin MTA-STS, DANE veya yerel zorunlu TLS politikası. Farklı gönderen sistemler aynı alıcı etki alanı için farklı kararlar verebilir.

Daha sonra her kontrolün destekleyebileceği iddiayı tanımlayın. Genel bir HTTPS isteği, bu bakış açısından politika kullanılabilirliğini belirleyebilir. Bir TLS probu, seçilen bir adreste sunulan bir sertifikayı gözlemleyebilir. Doğrulayıcı bir DNS sorgusu aşağıdakiler hakkında kanıt sağlayabilir: DNSSEC Belirtilen çözümleyici güven modeli kapsamındaki durum. Hiçbiri tek başına gerçek bir gönderim olduğunu kanıtlamaz MTA aynı verileri kullandı ve beklenen teslimat politikasını uyguladı.

Yalnızca sonuçlardan ziyade durumu yakalayın

Referanslar: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.

MTA-STS için keşif kaydını, tam HTTPS ilkesi baytlarını, alma süresini, modunu, ömrünü ve gönderenin önbellek durumunu saklayın. DANE için MX koruyun ve TLSA cevaplar, doğrulama durumu ve ilişkilendirme karşılaştırması. Her SMTP bağlantısı için seçilen ana bilgisayarı ve IP'yi yakalayın, STARTTLS müzakere, akran doğrulama sonucu ve teslimat kararı. RFC 8461 bölümleri 3-5, RFC 7672 bölümleri 2–3.

Başarısız bir prob, başarısızlık aşamasını kaydetmelidir. DNS zaman aşımı, TCP zaman aşımı, STARTTLS yokluğu, el sıkışma hatası ve sertifika uyumsuzluğu birbirinin yerine geçebilecek bulgular değildir. Başarılı bir el sıkışma aynı zamanda gönderenin gelecekte derecesi düşürülmüş bir bağlantıyı reddedeceği anlamına da gelmez. İzin verildiğinde, özellikle katı bir taşıma zorunluluğu getirilmeden önce kontrollü negatif vakaları dahil edin.

Kapsama boşluğu üzerinden çalışın

Bu sentetik envanter örneğinde mx1.example.net IPv4 ve IPv6 rotaları vardır ve mx2.example.net bir yedektir. Örnek bir gözlem yalnızca mx1'in IPv4 adresini kapsar. Envanter, başarıyı üçüne de yaymak yerine IPv6 ve yedekleme rotalarını test edilmemiş olarak işaretlemelidir. Gözlem açıkça sentetiktir ve gerçek bir bağlantı iddiası taşımamaktadır.

Geçerli bir uygulama ilkesi kullanan, destekleyici bir MTA için gönderen tarafı kabul satırı, boş önbelleğe sahip başka bir satır ve doğrulanmış TLSA'ya sahip DANE özellikli bir gönderen ekleyin. Bu satırlar, gerçek günlükler yakalanana kadar beklemede kalır. Bu, beklenen sonuçları ölçüm olarak sunmadan kabul planını faydalı kılar. Ayrıca olay müdahale görevlisinin başarısız rotanın uygulanıp uygulanmadığını görmesine de olanak tanır.

Raporları ve operasyonel kanıtları uzlaştırın

Referanslar: RFC 8460 §4.1, RFC 8460 §4.2.

TLS-RPT raporlar, bir raporlama dönemi boyunca katılımcı gönderenler tarafından görülen hataları ortaya çıkarabilir ve belirli bir zamandaki araştırmaları tamamlayabilir. Oturum sayıları benzersiz mesaj sayıları değildir ve kapsamları evrensel değildir. Sessiz bir raporlama dönemi, tüm rotaların başarılı olduğunu kanıtlamaz ve tekrarlanan yeniden denemeler, iş etkisi tahminlerini karmaşık hale getirebilir. RFC 8460 bölüm 4.4.

Ham sonucu, zaman damgasını, araç sürümünü veya komutunu ve bundan çıkardığınız daha dar sonucu saklayın. Sertifika yenileme, MX geçişi, DNSSEC değişiklikleri ve politika güncellemelerinden sonra yeniden test edin. İnceleme paketi, sertifika yakalamaya ulaşan dört oturum için eş sertifika baytlarıyla birlikte, 7 Kasım 2026'ya ait tutulan yedi geri döngü transkriptini içerir. Bunlar, Internet SMTP , DNSSEC doğrulama zincirini, üretim MTA kuyruklarını veya tam MTA-STS sertifika profili uyumluluğunu değil, açıkça yapılandırılmış güven ve politika girişlerine sahip, oluşturulan bağlantı noktalarında yerel bir IPv4 Python istemcisini/sunucusunu kapsar. Tarihsel oturumlar incelendi ancak burada tekrar yürütülmedi. Örnek Internet IPv4 , IPv6 ve yedekleme yolları henüz test edilmemiştir; hiçbiri yerel geçiş hakkını devralmaz. Yeni yürütülen çevrimdışı kapsama modeli yalnızca bir sentetik gözlemlenen rotanın, listelenen diğer rotaları test edilmeden bıraktığını kontrol eder. Dağıtım güvencesini talep etmeden önce amaçlanan MTA'yı ve yönlendirme gözlemlerini yakalayın.

[ Götürmek ]

Başka bir rotadan geçiş almak yerine, denenmemiş yolları test edilmemiş halde tutun.

[ 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

Uç noktayı ve politika durumunu kaydedin

Tekrarlanabilir kanıtlar bir ekran görüntüsünden daha fazlasını gerektirir.

Sonraki adımlar

  1. Komutları ve süreleri kaydedin.
  2. Her iki adres ailesini de test edin.
  3. Gönderenin kararlarını yakalayın.

CISO / SecOps

Test edilmemiş maruziyeti takip edin

Bilinmeyen kapsam görünür kalmalıdır.

Sonraki adımlar

  1. Negatif vakalar gerektirir.
  2. Raporları dikkatli bir şekilde ilişkilendirin.
  3. Gözlemleri beklentilerden ayırın.

Kurucu / Teknik Olmayan

Rozetin neyi kapsadığını sorun

Kapsamlı bir sonuç, niteliksiz bir sözden daha faydalıdır.

Sonraki adımlar

  1. Envanter iş açısından kritik rotalar.
  2. Eksik testleri atayın.
  3. Değişiklikle tetiklenen kontrolleri inceleyin.

[ SSS ]

Sık sorulan sorular

Tek bir kontrol geçişi tüm MX ana bilgisayarlarını kapsıyor mu?

Hayır. Gerçekte test edilen ana bilgisayarları ve adresleri kaydedin.

Neden IPv4 ve IPv6 ayırasınız ki?

Farklı altyapı veya sertifika dağıtımlarına ulaşabilirler.

HTTPS ilkesinin kullanılabilirliği SMTP zorunlu kılındığını kanıtlayabilir mi?

Hayır. Gönderici politikası değerlendirmesi ve teslimat kararları ayrı kanıtlar gerektirir.

RFC 8461 §4 RFC 8461 §5

Bir arıza kaydı neleri içermelidir?

Zaman damgası, uç nokta, test yöntemi, hata aşaması ve ilgili politika durumu.

TLS-RPT eşit mesajları mı sayar?

Hayır. Aktarım oturumlarını özetlerler ve yeniden denemeleri yansıtabilirler.

RFC 8460 §4.2

Test edilmemiş yedeklemeler başarılı olarak işaretlenmeli mi?

Hayır. Test edilmemiş rotaları açık tutun.

Kontroller ne zaman tekrarlanmalı?

İlgili sertifika, yönlendirme, DNSSEC veya aktarım politikası değişikliklerinin yanı sıra rutin izleme sonrasında.

Gönderici gözlemlerinin kapsamı nedir?

Dahil edilen tutulan transkriptler, üretim-MTA veya Internet-rota kapsamını değil, 7 Kasım'a ait yedi sınırlı geridöngü istemci vakasını açıklamaktadır. Tekrar çalıştırılmadılar, incelendiler; yeni uygulama çevrimdışı bir kapsama modelidir.

[ Kaynaklar ]

Kaynaklar

  1. RFC 7672

    Bölümler §2 · §2.2 · §3

  2. RFC 8460

    Bölümler §4.1 · §4.2 · §4.4

  3. RFC 8461

    Bölümler §3 · §3.3 · §3.4 · §4 · §5 · §5.1

[ Sözlük ]

Sözlük

Bakış noktası
Testin gerçekleştirildiği ağ ve çözümleyici bağlamı.
Kapsam boşluğu
İddia edilen test kanıtlarının eksik olduğu bir rota veya durum.
Gönderen tarafı gözlemi
Gerçek gönderen sistemin politikasının ve bağlantı kararının kaydı.

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ı