TLS-RPT: Şifreli Teslimat Hatalarını Kimse Şikayet Etmeden Görmek

Bir gönderen, MX'inize STARTTLS ile bağlanamadığında bunu size kimse söylemez. Sertifikanız süresi geçtiğinde, bir ara relay TLS'i strip ettiğinde ya da sunduğunuz zincir eksik olduğunda mektup ya sessizce düz metne düşer ya da — MTA-STS'i enforce moda aldıysanız — gönderenin kuyruğunda çürür. Her iki durumda da sizin logunuzda tek bir satır bile yoktur. Sorunu ilk öğrenme şekliniz genellikle bir müşterinin "size mail atamıyorum" demesi olur.

TLS-RPT (RFC 8460, SMTP TLS Reporting) tam olarak bu kör noktayı kapatır. Alıcı MX'inize yapılan şifreli teslimat denemelerinin sonucunu, gönderen tarafın toplayıp size günlük olarak raporlamasını sağlar. Makine-okunur, toplu (aggregate), gzip'li JSON. Kurulumu beş dakika; değeri, ilk certificate-expired raporunu insanlar şikayet etmeden görmekte.

Bu yazının önerisi net: TLS-RPT'yi MTA-STS'in bir eklentisi olarak değil, kendi başına bir gözlem aracı olarak kurun. Bir politikanız olmasa bile — raporlarda no-policy-found olarak görünür — opportunistic TLS hatalarını size raporlatır. Asıl iş kaydı yayınlamak değil; onlarca gönderenden gelen JSON yığınını sinyale çevirmektir.

TLS-RPT tam olarak neyi görünür kılar

SMTP'de STARTTLS opportunistic'tir: gönderen "TLS varsa kullanırım, yoksa düz metin giderim" der. Bu davranış bir downgrade saldırısına ya da basit bir yanlış yapılandırmaya karşı sizi savunmasız bırakır çünkü düşüş sessizdir. MTA-STS (RFC 8461) ve DANE (RFC 7672) bu sessizliği kırıp "TLS zorunlu" der. Ama zorlama gönderen tarafta olur; teslimat başarısız olduğunda hata gönderenin makinesinde kalır, sizin tarafınıza hiçbir iz düşmez.