TLS-RPT Nedir ve SMTP TLS Raporları Nasıl Çalışır?

Sesli Dinle — Makale

TLS-RPT (SMTP TLS Reporting), uyumlu posta aktarım sunucularının e-posta teslimindeki bağlantı güvenliği hakkında toplu rapor göndermesini sağlayan standarttır. MTA (Mail Transfer Agent), SMTP üzerinden ileti gönderirken bağlantıyı şifrelemek için TLS kullanmayı dener. Alıcı alan adı, raporların nereye iletileceğini DNS üzerindeki TXT kaydıyla bildirir.

TLS-RPT bağlantıyı şifrelemez, sertifika politikasını belirlemez ve teslimatı tek başına engellemez. Başarılı oturumları, TLS bağlantısının kurulması veya politika doğrulaması sırasında oluşan hataları görünür hale getirerek alan adı sahibine teşhis verisi sunar.

MTA-STS (SMTP MTA Strict Transport Security), MX kayıtlarıyla tanımlanan posta sunucularından hangilerine izin verildiğini ve doğrulanmış TLS sertifikası beklentisini yayımlar. DANE (DNS-Based Authentication of Named Entities) ise DNSSEC ile doğrulanan TLSA (TLS sertifikası veya anahtar eşleşmesini bildiren DNS kaydı) kayıtlarını kullanır. TLS-RPT, bu politikaların veya politika bulunmayan oturumların sonuçlarını raporlayabilir; MTA-STS ya da DANE güvenlik politikasının yerine geçmez.

TLS-RPT Raporlama Akışı

• Alıcı alan adı, _smtp._tls adında bir TXT kaydı yayımlayarak rapor hedefini bildirir.
• TLS-RPT'yi destekleyen gönderen MTA'lar, ilgili alan adına yapılan başarılı ve başarısız SMTP TLS oturumlarını sayar.
• Sonuçlar tek tek iletiler yerine belirli bir zaman aralığını kapsayan toplu raporlarda birleştirilir.
• Var olan SMTP bağlantısını TLS ile şifreli hale getiren STARTTLS komutundaki, sertifika doğrulamasındaki ve MTA-STS ya da DANE politika uygulamasındaki sorunlar ayrı hata türleriyle raporlanabilir.
• TLS-RPT gerçekleşen sonuçları bildirir; MTA-STS ve DANE ise güvenli teslimat için uygulanacak beklentileri tanımlar.

TLS-RPT DNS Kaydı Ne Bildirir?

TLS-RPT politikası, alan adının DNS bölgesinde TXT kaydı olarak yayımlanır. Kayıt, gönderen MTA'lara raporlama sürümünü ve toplu raporların teslim edileceği hedefi gösterir; alan adının MX kaydını veya sunucunun TLS sertifikasını değiştirmez.

TXT Kaydı _smtp._tls Alt Alanında Yayımlanır

Kayıt adı politika alan adının önüne _smtp._tls eklenerek oluşturulur. Örneğin alıcı alan adı example.com ise sorgulanan tam ad _smtp._tls.example.com olur. Bir alt alan adına doğrudan e-posta gönderiliyorsa TLS-RPT kaydı da o alt alanın politika adı altında ayrıca yayımlanır.

TLS-RPT Sürümü ve Rapor Hedefleri

Geçerli kayıt v=TLSRPTv1 sürüm ifadesiyle başlar ve zorunlu rua (toplu rapor adresi) alanında rapor hedefini belirtir. Hedef, e-posta için mailto şeması veya web uç noktası için HTTPS adresi olarak tanımlanabilir; birden fazla hedef virgülle ayrılabilir. Örnek bir e-posta hedefinde kayıt değeri v=TLSRPTv1; rua=mailto:tls-raporlari@example.com biçimini izler.

Aynı ad altında birden fazla geçerli TLS-RPT TXT kaydı bulunması önemli bir yapılandırma hatasıdır. Uyumlu gönderen MTA, sürümle eşleşen kayıtları ayıkladıktan sonra tam olarak bir kayıt bulamazsa alan adını TLS-RPT kullanmıyor kabul eder. Bu nedenle birden fazla e-posta hizmeti sağlayıcısının aynı DNS adına ayrı kayıt eklemesi yerine hedefler tek kayıtta birleştirilmelidir. Kayıt birden fazla TXT dizesi halinde dönüyorsa dizeler araya boşluk eklenmeden birleştirilir; sözdizimi geçerli olduğu sürece tanınmayan ek alanlar yok sayılır.

SMTP TLS Raporu Nasıl Oluşur?

Bir gönderen MTA, alıcı alan adının MX sunucusuna bağlanırken DNS çözümleme, STARTTLS bağlantısının kurulması, sertifika doğrulaması ve varsa MTA-STS veya DANE politikası uygulamasının sonucunu kaydedebilir. TLS-RPT, bu olayları raporlama dönemi sonunda politika ve hedef sunucu temelinde toplar.

Rapor Dönemi ve Makinece Okunabilir Rapor Yapısı

Rapor döneminin UTC’ye göre 00.00 ile 24.00 arasındaki tam günü kapsaması önerilir. Alıcı sistemi aşırı yüklememek için raporun birkaç saatlik gecikmeyle gönderilmesi normaldir; bu nedenle TLS-RPT anlık uyarı mekanizması değildir.

Raporlar, yazılımların işleyebildiği JSON veri biçiminin birlikte çalışabilirlik kurallarını belirleyen I-JSON (Internet JSON) standardına uyar. Kuruluş adı, iletişim bilgisi, benzersiz report-id, tarih aralığı ve policies dizisi temel alanlardır. policies alanı tek politika uygulansa bile dizi olmalıdır; policy-type değeri tlsa, sts veya no-policy-found olabilir. Politika alan adı, MX kalıbı, başarı ve hata sayıları ile ayrıntılardaki gönderen MTA'nın IP adresi, alıcı MTA ana bilgisayar adı ve hata nedeni birlikte yorumlanır.

TLS Oturumlarının Başarı ve Hata Sayıları

Başarı sayısı, gönderen MTA'nın uyguladığı politikaya uygun bir TLS bağlantısını kurabildiği oturumları gösterir. Hata sayısı ise alıcı MX sunucusuyla gerekli bağlantının kurulamadığı veya politika doğrulamasının tamamlanamadığı oturumların toplu sayısıdır. Bu değerler e-posta teslim edildi bilgisinin birebir karşılığı değildir; raporun odağı taşıma katmanındaki TLS oturumudur.

SMTP TLS Raporlarındaki Hata Sınıfları

• STARTTLS ve sertifika hataları: starttls-not-supported, STARTTLS sunulmadığını; certificate-host-mismatch, sunucunun sertifikasının politikadaki kimlik koşullarıyla eşleşmediğini, örneğin MX sunucusu adını kapsamadığını; certificate-expired, sertifikanın süresinin dolduğunu; certificate-not-trusted ise bilinmeyen sertifika otoritesi veya sertifika zinciri hatası gibi güven doğrulama sorunlarını bildirir.
• MTA-STS hataları: sts-policy-fetch-error, politika dosyasının alınamadığını; sts-policy-invalid, politikanın geçersiz olduğunu; sts-webpki-invalid ise politika sunucusunun web sertifikasının doğrulanamadığını gösterir.
• DANE hataları: tlsa-invalid, TLSA kayıt kümesinde geçerli kayıt bulunmadığını; dnssec-invalid, recursive resolver (özyinelemeli DNS çözümleyicisi) üzerinden geçerli kayıt alınamadığını; dane-required ise DANE'nin zorunlu tutulduğu MX sunucusunda DNSSEC ile doğrulanmış TLSA kaydı bulunmadığını belirtir.
• Genel doğrulama hataları: validation-failure, daha özel bir sınıfa yerleştirilemeyen sorunu gösterir; failure-reason-code alanı kısa hata kodu veya açıklaması taşıyabilir.
• Geçici hatalar: Ağ yoğunluğu ve bağlantı zaman aşımı gibi geçici sorunların TLS-RPT raporuna eklenmesi zorunlu değildir.

Hata türleri birbirini dışlamaz. Tek bir SMTP denemesi birden fazla sorunla karşılaşırsa aynı oturum farklı hata ayrıntılarında sayılabilir; bu nedenle hata sınıfları benzersiz oturum sayısı gibi toplanmamalıdır.

MTA-STS, DANE ve TLS-RPT Arasındaki Farklar

Bu üç bileşen aynı SMTP TLS akışında birlikte görülebilir, ancak farklı sorumluluklara sahiptir. Aşağıdaki karşılaştırma, politika belirleme ile sonuç raporlama arasındaki ayrımı gösterir.

TLS-RPT açısından önemli olan, gönderen MTA'nın uyguladığı politikanın raporda belirtilmesi ve her hatanın doğru politika türüyle ilişkilendirilebilmesidir.

TLS-RPT Raporları Nasıl Yorumlanır?

Tek bir rapordaki hata sayısı, sorunun boyutunu tek başına açıklamaz. Önce raporun hangi gönderen kuruluşu, zaman aralığını, MX sunucusunu ve politikayı kapsadığını belirleyin.

1. Başarılı ve başarısız oturumların oranını aynı rapor dönemi içinde karşılaştırın.
2. Hataları MX ana bilgisayar adına ve uygulanan MTA-STS veya DANE politikasına göre gruplayın.
3. Tekrarlayan sertifika, STARTTLS, DNSSEC ya da politika alma hatalarını ayrı değerlendirin.
4. Hataların başladığı zamanı sertifika yenilemesi, MX değişikliği, DNSSEC yapılandırması veya politika güncellemesiyle karşılaştırın.
5. Düzeltmeden sonraki raporlarda aynı hata sınıfının azalıp azalmadığını izleyin.

Rapor gelmemesi, TLS bağlantılarının hatasız olduğunu kanıtlamaz. Alan adına o dönemde e-posta gönderilmemiş olabilir, gönderen MTA TLS-RPT'yi desteklemeyebilir, DNS kaydını görememiş olabilir veya rapor teslimi başarısız olmuş olabilir. Raporlar genellikle toplu ve gecikmeli geldiği için anlık izleme aracı gibi değerlendirilmemelidir.

TLS-RPT Hangi Sorunları Gösterir, Hangilerini Kanıtlayamaz?

TLS-RPT, farklı gönderen MTA'larda aynı MX ya da sertifika hatasının tekrarlandığını gösterdiğinde yapılandırma sorununu daraltmaya yardımcı olur. Özellikle yalnız belirli gönderen MTA'larda görülen hatalar, karşılıklı TLS uyumluluğu veya gönderen MTA'daki politika uygulaması hakkında ipucu verebilir.

Bununla birlikte raporlar aktif saldırıyı kesin olarak kanıtlamaz. DNS yanıtını veya rapor kanalını engelleyebilen bir saldırgan, TLS-RPT kaydının keşfini de önleyebilir. DNS kaydının TTL’sinin yüksek tutulması ve DNSSEC bazı saldırı pencerelerini azaltabilir, ancak rapor sürekliliğini garanti etmez.

TLS-RPT Raporlarında Güvenlik ve Gizlilik

Rapor işleme sistemi, gelen içeriği güvenilmeyen veri olarak ele almalıdır. E-posta yoluyla gelen TLS-RPT raporları, raporlayan alan adına ait geçerli bir DKIM (DomainKeys Identified Mail) imzası taşımalıdır. Alıcı sistem, geçerli imzası olmayan raporları yok saymalıdır. DKIM imzası, imzalanan gövde uzunluğunu sınırlayan l= etiketini kullanamaz. DNS'teki DKIM anahtar kaydında s=tlsrpt hizmet türünün belirtilmesi önerilir; bu bildirim yoksa alıcı sistem raporu yok sayabilir.

Rapor iletisinde TLS-Report-Domain ve TLS-Report-Submitter başlıkları bulunmalıdır. İlki raporun ilgili olduğu alan adını, ikincisi raporu gönderen alan adını belirtir. İkinci değer, JSON raporunun contact-info alanındaki e-posta adresinin alan adıyla eşleşmelidir. Bu iki başlığın DKIM imzasına dahil edilmesi de önerilir.

Rapor hizmetini yöneten ekip, HTTPS uç noktasında istek sayısını ve içerik boyutunu sınırlayarak aşırı istek, bozuk içerik ve kaynak tüketimi risklerine karşı önlem almalıdır. Raporlar gönderen MTA'nın IP adresini ve altyapı ayrıntılarını içerebilir; TLS uygulaması, işletim sistemi veya bölgesi hakkında dolaylı bilgi de verebilir. Bu nedenle raporlara kimlerin erişebileceği ve verilerin ne kadar süre saklanacağı belirlenmelidir.

TLS-RPT Raporları Nasıl Toplanır ve İzlenir?

TLS-RPT'nin kullanılabilir olması için yalnız DNS kaydını eklemek yeterli değildir. Rapor işleme sistemi iletileri veya HTTPS isteklerini kabul etmeli, sıkıştırılmış raporları güvenli biçimde açmalı, JSON içeriğini doğrulamalı ve yinelenen hata sınıflarını izlenebilir hale getirmelidir.

E-posta yolunda rapor, iletinin parçalarını ve içerik türlerini tanımlayan MIME (Multipurpose Internet Mail Extensions) kapsamında multipart/report; report-type="tlsrpt" yapısıyla taşınır. İlk bölüm doğrudan okunabilen açıklama metnidir; makinece işlenen bölüm sıkıştırılmamışsa application/tlsrpt+json, gzip ile sıkıştırılmışsa application/tlsrpt+gzip medya türünü kullanır. Hem e-posta hem HTTPS tesliminde gzip sıkıştırması önerilir.

HTTPS hedefinde rapor POST yöntemiyle gönderilir ve alıcının genellikle 200 veya 201 başarı durumu döndürmesi beklenir. RFC 8460, rapor gönderenin HTTPS sertifika doğrulama hatalarını yok saymasına izin verir; amaç yanlış yapılandırma raporunun aynı yanlışlık nedeniyle kaybolmasını azaltmaktır. İlk teslimat başarısız olursa 24 saate kadar, giderek uzayan aralıklarla yeniden deneme önerilir ancak zorunlu değildir. Konu satırı veya dosya adı JSON gövdesiyle çelişirse JSON raporu esas alınır.

• Raporlar için ayrı ve izlenen bir posta kutusu veya HTTPS uç noktası kullanın.
• Birden fazla rapor hedefi gerekiyorsa bunları tek TLS-RPT kaydının rua alanında tanımlayın.
• Tek seferlik hatalardan çok yinelenen sorunları, belirli MX sunucularındaki yoğunlaşmayı ve ani değişimleri inceleyin.
• Sertifika, DNS, MTA-STS ve DANE sorumluluklarını ilgili altyapı ekipleriyle eşleştirin.
• Rapor işleme hizmetinin kapasitesini, erişim kontrolünü ve veri saklama politikasını belirleyin.