Wawancara Backend: Bagaimana Anda Mendiagnosis Kegagalan SMTP TLS dengan TLS-RPT?

Pertanyaan dan skenario

Anda mengoperasikan domain penerima multi-MX di beberapa penyedia. Setelah mengaktifkan MTA-STS, beberapa pengirim melaporkan kegagalan handshake TLS. Jelaskan bagaimana Anda akan menggunakan SMTP TLS Reporting (TLS-RPT) untuk mengamati, mendiagnosis, dan meluncurkan perbaikan secara aman.

Apa yang sedang diuji oleh pewawancara

• Membedakan telemetri (TLS-RPT) dari penegakan kebijakan (MTA-STS dan DANE).
• Menghubungkan DNS, sertifikat, STARTTLS, file kebijakan HTTPS, dan jalur backup MX.
• Menggunakan peluncuran bertahap (staged rollout), metrik, peringatan, dan rollback untuk melindungi keterkiriman pesan (deliverability).

Pertanyaan klarifikasi sebelum menjawab

Konfirmasikan kumpulan MX domain, apakah MTA-STS atau DANE diaktifkan, tujuan TLS-RPT, rentang waktu laporan, dan apakah kegagalan bersifat global atau terkonsentrasi pada satu pengirim atau backup MX tertentu. Perjelas apakah tujuannya adalah mendeteksi penurunan ke plaintext, menjelaskan kegagalan pengiriman, atau memvalidasi peluncuran penegakan kebijakan.

Kerangka jawaban 30 detik

TLS-RPT, yang didefinisikan oleh RFC 8460, adalah telemetri; ini tidak menegakkan enkripsi. Saya akan memublikasikan rekaman TXT _smtp._tls, mengumpulkan laporan agregat, dan mengelompokkan kegagalan berdasarkan kebijakan, pengirim, MX, dan alasan. Kemudian saya akan memvalidasi STARTTLS, identitas dan rantai sertifikat, DNS, serta file HTTPS MTA-STS untuk setiap MX. Setelah memperbaiki masalah, saya akan mengamatinya dalam mode testing sebelum beralih ke penegakan (enforce) dan mempertahankan jalur rollback yang telah teruji.

Jawaban mendalam langkah demi langkah

1. Publikasikan rekaman seperti v=TLSRPTv1; rua=mailto:tls-reports@example.org; otorisasi tujuan serta verifikasi penguraian (parsing), retensi, dan redaksi data.
2. Urai agregat JSON RFC 8460 untuk kebijakan, MTA pengirim, MX, keberhasilan, dan alasan kegagalan. Kelompokkan berdasarkan waktu, penyedia, dan backup MX alih-alih mengandalkan satu angka tingkat kegagalan saja.
3. Untuk setiap MX, verifikasi DNS, port 25, STARTTLS, rantai sertifikat, dan nama. Bandingkan observasi pengirim dengan log email dan pemeriksaan eksplisit SMTP TLS.
4. Untuk MTA-STS, periksa _mta-sts, file HTTPS /.well-known/mta-sts.txt, modenya, pola MX, dan caching. Untuk DANE, periksa validasi DNSSEC dan kesesuaian TLSA dengan sertifikat.
5. Uji setiap MX, rekaman usang, dan jalur failover dalam mode testing sebelum beralih ke enforce. Pasang peringatan untuk tingkat kegagalan yang meningkat atau jalur/penyedia kritis.
6. Uji ulang dengan matriks yang sama setelah memperbaiki sertifikat, file kebijakan, DNSSEC, atau konfigurasi penyedia. Jika pengiriman terganggu, turunkan mode MTA-STS atau hapus entri kebijakan yang bermasalah sambil tetap mempertahankan pengumpulan data TLS-RPT.

dig TXT _smtp._tls.example.org
dig TXT _mta-sts.example.org
curl https://mta-sts.example.org/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org

Contoh jawaban berkualitas tinggi

Saya memperlakukan TLS-RPT sebagai telemetri, bukan sebagai sakelar enkripsi. Pertama, saya memublikasikan _smtp._tls dan mengirim laporan ke tujuan yang terkontrol, lalu membangun baseline berdasarkan pengirim, MX target, kebijakan, dan alasan kegagalan. Untuk setiap jalur yang dilaporkan, saya memeriksa STARTTLS, rantai dan nama sertifikat, TXT dan kebijakan HTTPS MTA-STS, atau DNSSEC/TLSA DANE; saya menyertakan backup MX dan TTL yang usang. Setelah remediasi, saya tetap berada dalam mode testing selama satu rentang laporan penuh dan melakukan uji failover sebelum memberlakukan enforce. Jika pengiriman gagal, saya melakukan rollback pada mode kebijakan sambil tetap mempertahankan laporan, alih-alih menerima plaintext secara diam-diam. Ini memisahkan observasi, perbaikan, dan penegakan ke dalam tahapan yang dapat dibatalkan (reversible).

Kesalahan umum

• Memperlakukan TLS-RPT sebagai penegakan TLS alih-alih sebagai pelaporan.
• Hanya memeriksa MX utama dan melewatkan jalur backup, DNS yang usang, atau jalur khusus penyedia.
• Memeriksa masa kedaluwarsa sertifikat tetapi tidak memeriksa SAN, rantai sertifikat, TLSA, atau pola mx pada file kebijakan.
• Beralih ke enforce tanpa rentang laporan yang lengkap, ambang batas, dan rencana rollback.
• Mengartikan ketiadaan laporan sebagai ketiadaan kegagalan tanpa mengonfirmasi cakupan pengirim dan otorisasi endpoint.

Pertanyaan lanjutan dan tanggapan

Apa batas antara TLS-RPT dan MTA-STS?

TLS-RPT mengagregasi bukti tentang hasil negosiasi. MTA-STS menggunakan kebijakan HTTPS untuk mewajibkan pengirim memvalidasi TLS. Keduanya bekerja sama: pelaporan memvalidasi peluncuran penegakan kebijakan.

Sebuah laporan menyebutkan certificate-mismatch. Apa yang Anda periksa terlebih dahulu?

Reproduksi handshake terhadap MX yang dilaporkan, periksa SAN, SNI, rantai sertifikat, dan DNS, lalu periksa apakah load balancer atau node cadangan masih menyajikan sertifikat lama.

Mengapa DANE memerlukan perhatian khusus pada DNSSEC?

Kepercayaan TLSA bergantung pada validasi DNSSEC. Rotasi sertifikat harus memperbarui TLSA secara atomik; jika tidak, pengirim yang mendukung DANE dapat menolak koneksi dan melaporkan kegagalan.

Bagaimana cara melakukan rollback setelah penegakan (enforcement)?

Simpan DNS dan file kebijakan yang berversi, turunkan MTA-STS dari enforce ke testing atau hapus entri yang salah, konfirmasikan bahwa pengiriman dan laporan telah pulih, lalu perbaiki akar masalah sementara TLS-RPT terus mengumpulkan data.