Pemberitahuan pengiriman sering kali berisi beberapa nama server, tanggal dan alamat. Sistem yang mengirimkan laporan belum tentu merupakan sistem yang menolak pesan tersebut. Parsing bidang status pengirimannya dan hubungkan upaya awal sebelum membuat perubahan DNS atau kotak surat berdasarkan baris subjek laporan.
Identifikasi pelaporan dan sistem jarak jauh
RFC 3464 mendefinisikan format isi status pengiriman. Pelaporan-MTA mengidentifikasi sistem yang menghasilkan notifikasi. Remote-MTA, jika ada, mengidentifikasi sistem jarak jauh yang terkait dengan upaya pengiriman yang dilaporkan. Kode Diagnostik dapat mempertahankan respons protokol jarak jauh. Penjelasan yang dapat dibaca manusia sangat membantu, namun prosanya tidak boleh menggantikan bidang terstruktur. RFC 3464 bagian 2.2 dan 2.3.
Catat identitas sistem dan waktu yang dilaporkan. Relai yang menerima email dari aplikasi mungkin nantinya akan menerima penolakan dari server penerima dan membuat DSN itu sendiri. Memperlakukan nama relai sebagai tujuan penolakan dapat mengirimkan penyelidikan ke administrator yang salah dan mengaburkan respons SMTP asli.
Baca setiap blok penerima secara mandiri
Penerima Akhir mengidentifikasi penerima yang menerapkan blok status pengiriman. Penerima Asli, jika ada, dapat mempertahankan identitas penerima sebelumnya. Tindakan menggambarkan tindakan pengiriman, seperti gagal atau tertunda. Status membawa kode status yang ditingkatkan. Kode Diagnostik Opsional, Tanggal Percobaan Terakhir, dan Akan Coba Lagi-Sampai dapat memberikan konteks tambahan yang berguna, namun tidak semua laporan menyediakannya.
Ketika Kode Diagnostik ada, RFC 3464 bagian 2.3.6 menafsirkan MTA Jarak Jauh yang disediakan sebagai penerbitnya; tanpa Remote-MTA, diagnostik dikaitkan dengan Reporting-MTA. Aturan lapangan tersebut tidak membuktikan bahwa tidak ada upaya jarak jauh yang pernah terjadi sebelumnya. Kuatkan riwayat lengkap dengan log tepercaya.
DSN dapat menyertakan beberapa blok penerima dengan tindakan dan nilai status berbeda. Jangan terapkan satu kegagalan pada semua orang di header To atau Cc asli. Demikian pula, bidang opsional yang hilang bukan merupakan bukti bahwa peristiwa terkait tidak pernah terjadi. Pertahankan ketidakhadiran sebagai hal yang tidak diketahui dan gunakan bukti antrian atau jejak untuk mengisi kekosongan tersebut.
Baca pemberitahuan kedaluwarsa hipotetis
Bayangkan relay.example menerima pesan, lalu menerima 452 4.2.2 Kotak Surat penuh dari mx.example saat mencoba pengiriman. Setelah masa pengiriman yang dikonfigurasikan berakhir, relai menghasilkan DSN. Kutipan pengajaran dapat mengidentifikasi Reporting-MTA: dns; relay.example , MTA Jarak Jauh: dns; mx.example , Penerima Akhir: rfc822; recipient@example.test , Tindakan: gagal, Status: 5.4.7 dan Kode Diagnostik: smtp; 452 4.2.2 Kotak surat penuh.
Ini adalah penelusuran lapangan yang dibuat-buat, bukan laporan MIME lengkap atau pertukaran email yang dilakukan. Status terakhir menggambarkan berakhirnya waktu pengiriman, sedangkan diagnostik yang dipertahankan menggambarkan penolakan kapasitas terakhir. Bidang menjawab pertanyaan yang berbeda. Ini bukan pemetaan pilihan universal: RFC 3463 bagian 3.5 mengatakan untuk mengembalikan kode masalah pengiriman yang sebenarnya alih-alih kadaluwarsa jika memungkinkan. Pertahankan penyebab paling spesifik yang didukung. RFC 3464 juga mengizinkan Tindakan: gagal dengan Status 4.xx setelah pelaporan MTA telah mengabaikan upaya; penyebab sementara tidak berarti penyebab asli tetap berada dalam antrian.
Untuk laporan Anda sendiri, hubungkan penyerahan asli, upaya, keputusan kedaluwarsa, dan kedatangan laporan secara terpisah. Jangan berasumsi bahwa nama ilustratif, waktu, atau kolom cocok dengan penyedia. Pertahankan bidang opsional yang hilang tanpa mengisinya dengan nilai tebakan.
Berkorelasi sebelum bertindak
Cocokkan notifikasi dengan penerima amplop asli, waktu pengiriman dan pengidentifikasi antrian yang tersedia. Original-Envelope-Id dapat membantu korelasi jika ada; ID Pesan yang dikembalikan adalah petunjuk lain daripada cukup autentikasi notifikasi itu sendiri. Laporan dapat dipalsukan atau disebabkan oleh pemalsuan jalur kembali alamat, jadi pentalan yang tidak terduga tidak boleh secara otomatis memicu perubahan konfigurasi pengirim.
Gunakan log pengiriman tepercaya untuk memastikan bahwa organisasi benar-benar mengirimkan pesan tersebut. Hindari membuka lampiran yang dikembalikan atau mengikuti perintah kredensial hanya karena pesannya menyerupai pentalan. Jika tidak ada kiriman yang cocok, selidiki laporan tersebut karena berpotensi tidak diminta atau dipalsukan, alih-alih memperlakukannya sebagai bukti penyusupan akun.
Tetapkan koreksi ke lapisan kanan
Status pengalamatan masuk ke kotak surat atau pemilik kontak. Masalah rute atau koneksi memerlukan bukti transportasi. Diagnostik otentikasi memerlukan identitas pesan yang relevan dan evaluasi penerimaan. Pertahankan diagnosis lengkap sehingga spesialis dapat membedakan kegagalan yang serupa.
Setelah koreksi disetujui, hubungkan setiap upaya baru dengan antrean dan pengidentifikasi pesannya sendiri. Jangan menimpa laporan sejarah dengan hasil selanjutnya. Tutup kegagalan asli, perbaikan dan pengiriman pengganti sebagai peristiwa yang terkait namun berbeda. Hal ini menjaga garis waktu yang jujur ketika laporan tertunda tiba setelah pengiriman ulang berhasil.
Siapkan eskalasi khusus penerima
- Korelasi: mencocokkan laporan dengan penyerahan yang sah menggunakan bukti penerima, waktu dan antrian.
- Penerbit: simpan Pelaporan-MTA secara terpisah dari MTA Jarak Jauh dan penerbit diagnostik.
- Hasil: mempertahankan Tindakan, Status, dan Kode Diagnostik asli tanpa memaksanya untuk mencocokkan.
- Pemilik: tetapkan lapisan kegagalan sebenarnya, bukan hanya pengirim pantulan.
- Privasi: hanya menyediakan kolom laporan yang diperlukan; jangan meneruskan konten pesan kembali yang tidak terkait.