“ Waktu SMTP habis” dapat menggambarkan beberapa peristiwa berbeda. Permintaan DNS mungkin telah habis waktunya, koneksi TCP mungkin belum selesai, atau koneksi yang dibuat mungkin menunggu terlalu lama untuk sambutan atau respons pesan akhir. Tahapan ini memiliki bukti yang berbeda dan risiko pengiriman duplikat yang berbeda. Identifikasi tahapan sebelum memilih perbaikan.
Selesaikan tujuan sebelum mengujinya
Catat domain penerima dan jawaban MX yang sebenarnya digunakan, termasuk nilai preferensi dan waktu pencarian. RFC 5321 menjelaskan pemilihan MX dan resolusi alamat, termasuk perilaku MX implisit ketika tidak ada data MX ada. Jika domain ada tetapi tidak memiliki data MX , penanganan MX implisit menggunakan domain itu sendiri dengan data alamat yang berlaku; NXDOMAIN dan kesalahan DNS sementara hasilnya berbeda. Hal ini berbeda dengan deklarasi null MX eksplisit, yang menandakan bahwa domain tidak menerima email berdasarkan RFC 7505 . Jangan ubah setiap hasil DNS yang tidak biasa menjadi tujuan yang dapat ditebak. RFC 5321 bagian 5.
Untuk setiap host yang dipilih, pertahankan hasil kelompok alamat yang relevan dan hasil koneksi. Pengujian IPv4 yang berhasil tidak membuktikan bahwa jalur IPv6 pengirim yang gagal berfungsi. Demikian pula, hasil penyelesai publik yang berfungsi tidak membuktikan apa yang dilihat oleh sistem pengirim tertentu sebelumnya. Catat kesalahan DNS secara terpisah dari jawaban berhasil yang mengarah ke host yang tidak dapat dijangkau.
Bedakan penolakan dari keheningan
Penolakan koneksi biasanya menunjukkan penolakan eksplisit terhadap upaya koneksi TCP. Batas waktu berarti peristiwa yang diharapkan tidak diamati dalam interval yang diizinkan. Tidak ada observasi yang dapat mengidentifikasi firewall, pemilik layanan, atau rute yang bertanggung jawab. Pemfilteran, kesalahan jaringan, ketersediaan pendengar, dan kondisi lainnya dapat menghasilkan gejala serupa yang terlihat oleh pengguna.
Setelah TCP berhasil, perhatikan apakah server mengirimkan salam SMTP -nya. Kemudian identifikasi perintah yang tepat menunggu respons. RFC 5321 menetapkan panduan batas waktu yang berbeda untuk beberapa tahapan SMTP . Batas waktu diagnostik yang singkat bagi operator adalah pilihan pengujian, bukan bukti produksi MTA melanggar atau memenuhi persyaratan tersebut. Jangan menerapkan satu batas waktu agresif pada setiap tahap dan menyebut hasilnya pasti.
Pertahankan ketidakpastian setelah transfer pesan
Batas waktu setelah data pesan terakhir lebih rumit daripada kegagalan tersambung. Penerima mungkin menerima tanggung jawab sementara tanggapan akhirnya hilang. Oleh karena itu, mengulangi transaksi dapat menghasilkan duplikat. Pertahankan status tanggapan akhir sebagai tidak diketahui kecuali pengiriman dan penerimaan bukti dapat menyelesaikan masalah tersebut; jangan secara otomatis memberi label pada pesan “tidak pernah diterima.” RFC 5321 bagian 4.5.3.2 dan 6.1.
Untuk kegagalan koneksi sebelum pertukaran SMTP apa pun, tidak ada pesan yang ditransfer pada koneksi tersebut. Kesimpulan yang lebih sempit ini masih belum menggambarkan upaya sebelumnya dalam antrean yang sama. Korelasikan semua upaya sebelum memutuskan apakah suatu transaksi bisnis memerlukan pengajuan lain.
Bandingkan tiga catatan batas waktu hipotetis
Kasus A tidak pernah menetapkan TCP ke MX yang dipilih. Pertahankan diagnosis pada tahap koneksi; tidak ada pesan SMTP yang melewati koneksi itu. Kasus B menetapkan TCP tetapi tidak mencatat salam 220 sebelum batas waktu yang dipilih alat diagnostik. Selidiki perilaku pendengar dan waktu tunggu salam yang relevan, daripada menyebutnya sebagai kegagalan yang sama seperti A.
Kasus C mentransmisikan data pesan dan terminatornya tetapi kehilangan respon akhir. Penerimaan tidak diketahui, jadi periksa antrian pengirim dan bukti penerima sebelum menambahkan salinan lain. Kasus-kasus yang ditemukan ini tidak berisi pengujian soket yang dijalankan, pemulihan terukur, atau klaim waktu penyedia. Batas waktu diagnostik yang singkat bukanlah rekomendasi produksi.
Untuk insiden MX yang benar-benar tidak tersedia, pertahankan host dan preferensi yang telah diselesaikan, setiap upaya rangkaian alamat, tahapan yang gagal, dan keputusan antrean. MX dengan prioritas lebih rendah yang berfungsi dalam pengujian mandiri tidak membuktikan pengirim yang terpengaruh menggunakannya; verifikasi riwayat upaya sebenarnya.
Perbaiki dan konfirmasi jalur yang terpengaruh
Tetapkan DNS , jaringan, dan bukti layanan email ke pemiliknya masing-masing. Uji ulang tujuan yang disetujui dan kelompok alamat yang sama setelah satu koreksi yang relevan, dan pertahankan perbandingan dari jaringan resmi lainnya hanya jika berguna. Konfirmasikan pemulihan antrean dan pesan penuaan sebelum menyatakan sukses. Jangan melemahkan otentikasi email karena sesi TCP tidak dapat dibuat.
Pilih pemilik tahap gagal
- Kegagalan DNS : pertahankan hasil dan waktu penyelesai aktual.
- Kegagalan TCP: catatan tujuan, keluarga alamat dan bukti jalur.
- Salam atau perintah tunggu: beri nama balasan yang hilang dan batas waktu yang dikonfigurasi.
- Balasan DATA akhir hilang: rekonsiliasi penerimaan sebelum pengiriman ulang secara manual.
- Pemulihan: memperhitungkan item antrian yang menua dan kedaluwarsa, bukan hanya satu koneksi yang berhasil.