Bahkan hanya sekilas protokol SMTP akan membuat Anda memperhatikan bahwa selain HELO biasa, ada juga EHLO, yang menjadikan Diperpanjang Server SMTP mengiklankan kemampuannya melampaui standar asli. Salah satunya adalah DSN. DSN? Apakah DNA dan DDT tidak cukup?
Untuk membantah bahwa email tidak dapat diandalkan, bahwa seseorang harus " … beri makan server mereka lebih baik; itu memakan surat saya … "Ini tidak biasa. Namun tidak ada banyak alasan untuk mendukung kecurigaan ini.
Pengiriman S tatus N otification telah ada sejak RFC 821 (dari 1982). Segera setelah bagian DATA dari protokol SMTP selesai dan server telah menerima email untuk pengiriman, itu bertanggung jawab untuk itu. Jika karena alasan apa pun ia tidak bisa membawanya ke penerima, ia harus mengirimnya kembali dengan pemberitahuan kesalahan ke pengirim aslinya. Ini menghasilkan beberapa email yang tidak jelas.
Terlepas dari itu, konvensi lama ini berarti bahwa Anda mendapat pesan kesalahan atau Anda mendapatkannya tidak ada dalam hal ini Anda tahu tidak ada : email mungkin telah tiba atau tidak. Pesan kesalahan dalam banyak kasus sama membantu karena tidak ada pesan kesalahan. Dengan email menjadi lebih dan lebih penting ini tidak lagi memuaskan (seolah-olah itu sebelumnya).
Ekstensi DSN ke SMTP
RFC 1891 mengusulkan beberapa ekstensi ke protokol SMTP yang seharusnya menghasilkan sistem DSN yang lebih andal dan lebih dapat digunakan. Ini adalah satu set ekstensi untuk perintah MAIL dan RCPT.
Tanpa EHLO, Tidak Menyenangkan
Pertama, kita harus memastikan bahwa server mendukung DSN. Jadi, kita harus mengatakan EHLO padanya dan dengarkan baik-baik. Jika merespon dengan DSN di suatu tempat dalam daftar fitur, kita dapat berasumsi bahwa ia akan dapat melayani permintaan kami. Jika tidak, maka tidak: kita dapat mencoba server lain atau hanya kembali ke email tanpa DSN. Sebagai contoh:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Agustus 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Halo localhost 127.0.0.1, senang bertemu dengan Anda250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 BANTUAN Untungnya, di antara hal-hal lain, kami menemukan DSN. Perintah berikutnya biasanya adalah MAIL FROM. Dengan DSN, ini tidak berbeda. Tetapi ada dua opsi tambahan yang dapat Anda terbitkan: RET dan ENVID. Opsi RET agak sewenang-wenang ditempatkan dalam perintah MAIL, tetapi cocok di sini juga di mana pun. Tujuannya adalah untuk menentukan berapa banyak pesan asli Anda yang harus dikembalikan jika terjadi kegagalan pengiriman. Argumen yang valid adalah FULL dan HDRS. Yang pertama berarti bahwa pesan lengkap harus dimasukkan dalam pesan kesalahan, HDRS menginstruksikan server untuk hanya mengembalikan header dari email yang gagal. Jika RET tidak ditentukan, terserah kepada server apa yang harus dilakukan. Dalam banyak kasus, HDRS akan menjadi nilai default. ENVID benar-benar milik pengirim karena dia atau (lebih tepatnya) klien emailnya akan menjadi satu-satunya yang memanfaatkan ini pengidentifikasi amplop . Tujuannya adalah memberi tahu pengirim yang mengirim email tentang pesan kesalahan yang mungkin dikeluarkan. Format ID ini pada dasarnya diserahkan kepada imajinasi pengirim. Kami tidak akan menggunakan ENVID dalam contoh kami: MAIL FROM: [email protected] RET = HDRS250 [email protected] … Pengirim, ok Rupanya, kami hanya ingin mendapatkan kembali header di DSN kami. RCPT TO: mendapat bagian yang adil dari ekstensi juga: NOTIFY dan ORCPT. NOTIFY adalah jantung asli DSN. Ini memberitahu server kapan untuk mengirim pemberitahuan status pengiriman. Nilai pertama yang mungkin adalah TIDAK PERNAH yang berarti bahwa dalam situasi apa pun DSN harus dikembalikan ke pengirim. Ini tidak mungkin tanpa DSN. Lalu ada SUCCESS, yang akan memberi tahu Anda ketika surat Anda telah sampai di tempat tujuan. FAILURE adalah mitra SUCCESS: DSN akan tiba jika kesalahan terjadi saat pengiriman. Opsi terakhir adalah DELAY: Anda akan diberitahu jika ada keterlambatan pengiriman yang tidak biasa, tetapi hasil pengiriman yang sebenarnya (sukses atau gagal) belum diputuskan. TAK PERNAH harus menjadi satu-satunya argumen jika ditentukan, tiga lainnya mungkin muncul dalam daftar, dipisahkan oleh koma. SUKSES dan KEGAGALAN membentuk tim yang cukup kuat bersama-sama, memberi tahu Anda hampir (dalam hal apa pun) apa yang terjadi pada email Anda. Tujuan ORCPT adalah untuk mempertahankan asli penerima pesan email, misalnya, jika diteruskan ke alamat lain. Argumen ke opsi ini adalah alamat email penerima asli bersama dengan jenis alamat. Jenis alamat datang pertama, diikuti dengan titik koma dan akhirnya alamat. Sebagai contoh: RCPT TO: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Penerima ok (akan antri) Ini diikuti oleh DATA seperti yang kita ketahui dan akhirnya, mudah-mudahan, pemberitahuan status pengiriman yang memberitahukan Anda tentang keberhasilan. Tentu saja, semua keindahan ini dan itu hanya akan berfungsi jika agen transportasi surat dari pengirim ke penerima mendukung DSN. Suatu hari mereka akan melakukannya. Ekstensi Pengirim DSN
Ekstensi Penerima DSN
Apakah DSN Bekerja?
