Cari tahu bagaimana DSN bertujuan untuk memperkenalkan status pengiriman ke email SMTP.
Pernah Bertanya-tanya Apa yang Terjadi pada Email yang Anda Kirim?
Bahkan hanya sekilas protokol SMTP akan membuat Anda memperhatikan bahwa selain HELO biasa, ada juga EHLO, yang membuat server SMTP Extended 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 " ... memberi makan server mereka lebih baik; itu memakan email saya ... " tidak jarang. Saya melakukannya sendiri. Namun, tidak ada banyak alasan untuk mendukung kecurigaan ini.
Pengiriman S tatus N otification sudah 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 asli. Ini menghasilkan beberapa email yang tidak jelas.
Terlepas dari itu, konvensi lama ini berarti bahwa baik Anda mendapat pesan kesalahan atau Anda tidak mendapatkan apa - apa dalam hal ini Anda tidak tahu apa - apa : 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 seperangkat ekstensi untuk perintah MAIL dan RCPT (jika ini tidak ada artinya bagi Anda, baca bagaimana SMTP bekerja dan kemudian kembali ke sini.).
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 daftar fitur, kita dapat mengasumsikan 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 (masukan saya berwarna biru, output server hitam):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Agustus 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Halo localhost [127.0.0.1], senang bertemu dengan Anda
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 BANTUAN
Untungnya, di antara hal-hal lain, kami menemukan DSN.
Ekstensi Pengirim 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 kebanyakan kasus, HDRS akan menjadi nilai default.
ENVID benar-benar milik pengirim karena dia atau (lebih tepatnya) klien emailnya akan menjadi satu-satunya yang membuat kita pengenal amplop ini. 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 (imajinasi!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Pengirim, ok
Rupanya, kami hanya ingin mendapatkan kembali header di DSN kami.
Ekstensi Penerima DSN
RCPT TO: mendapat bagian yang adil dari ekstensi juga: NOTIFY dan ORCPT.
NOTIFY adalah jantung asli DSN. Ini memberitahu server kapan harus 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 email Anda terukir di tempat tujuan. FAILURE adalah mitra SUCCESS (!): DSN akan tiba jika terjadi arror selama 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. JANGAN PERNAH menjadi satu-satunya argumen jika ditetapkan, tiga lainnya mungkin muncul dalam daftar, dipisahkan oleh koma. SUKSES dan KEGAGALAN membentuk tim yang cukup kuat bersama-sama (!), Memberi tahu Anda dalam (hampir) hal apa pun yang terjadi pada email Anda.
Tujuan ORCPT adalah untuk melindungi penerima asli 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: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Penerima ok (akan antri)
Ini diikuti oleh DATA seperti yang kita ketahui dan akhirnya, mudah-mudahan, pemberitahuan status pengiriman yang memberitahukan Anda tentang keberhasilan.
Apakah DSN Bekerja?
Tentu saja, semua keindahan dan kecerdasan ini hanya akan berfungsi jika agen transportasi surat dari pengirim ke penerima dukungan DSN. Suatu hari mereka akan melakukannya.