DSN: Pemberitahuan Status Penghantaran untuk E-mel SMTP

Malah sekadar melihat ringkas pada protokol SMTP akan mendapati bahawa selain HELO biasa, terdapat juga EHLO, yang menjadikan Dilanjutkan Pelayan SMTP mengiklankan keupayaannya melebihi standard asal. Salah satunya adalah DSN. DSN? Adakah DNA dan DDT tidak mencukupi?

Untuk membantah e-mel itu tidak boleh dipercayai, seseorang itu harus " … suapan pelayan mereka lebih baik; ia makan mel saya … "tidak biasa, tetapi tidak banyak sebab untuk menyokong syak wasangka ini.

Penghantaran S tatus N pengesahan telah berlaku sejak RFC 821 (dari tahun 1982). Sebaik sahaja bahagian DATA dari protokol SMTP selesai dan pelayan telah menerima e-mel untuk penghantaran ia bertanggungjawab untuk itu. Sekiranya sebab apa pun ia tidak dapat meneruskannya kepada penerima, ia mesti menghantar kembali dengan pemberitahuan kesilapan kepada penghantar asal. Ini mengakibatkan beberapa e-mel yang tidak jelas.

Selain itu, konvensyen lama ini bermakna bahawa anda mendapat mesej ralat atau anda mendapatnya tiada apa-apa di mana anda tahu tiada apa-apa : e-mel mungkin telah tiba atau mungkin tidak. Mesej kesilapan dalam banyak kes sama seperti tidak ada mesej ralat. Dengan e-mel menjadi semakin penting, ini tidak lagi memuaskan (seolah-olah sebelum ini).

Sambungan DSN ke SMTP

RFC 1891 mencadangkan beberapa pelanjutan kepada protokol SMTP yang akan menghasilkan sistem DSN yang lebih dipercayai dan lebih dapat digunakan. Ia adalah satu set sambungan kepada arahan MAIL dan RCPT.

Tiada EHLO, Tidak Suka

Pertama, kita perlu memastikan bahawa pelayan menyokong DSN. Oleh itu, kita perlu mengatakan EHLO kepadanya dan mendengar dengan teliti. Jika ia bertindak balas dengan DSN di suatu tempat dalam senarai ciri, kita boleh mengandaikan bahawa ia akan dapat memenuhi permintaan kami. Jika tidak, maka tidak: kami boleh cuba pelayan lain atau hanya kembali ke e-mel tanpa DSN. Sebagai contoh:

220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hello localhost 127.0.0.1, senang bertemu dengan anda250-EXPN250-KERTAS250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELP

Untungnya, antara lain kita dapati DSN.

Sambungan Pengirim DSN

Perintah seterusnya biasanya adalah MAIL DARI. Dengan DSN, ini tidak berbeza. Tetapi terdapat dua pilihan tambahan yang boleh anda berikan: RET dan ENVID.

Pilihan RET agak diletakkan dalam perintah MAIL, tetapi ia sesuai di sini dan di tempat lain. Tujuannya ialah untuk menentukan berapa banyak mesej asal anda harus dikembalikan sekiranya berlaku kegagalan penghantaran. Hujah-hujah yang sah adalah FULL dan HDRS. Yang pertama bermakna bahawa mesej lengkap harus dimasukkan dalam mesej ralat, HDRS mengarahkan pelayan untuk hanya mengembalikan tajuk surat yang gagal. Jika RET tidak ditentukan, terpulang kepada pelayan apa yang perlu dilakukan. Dalam kebanyakan kes, HDRS akan menjadi nilai lalai.

ENVID benar-benar kepunyaan pengirim kerana dia atau (sebaliknya) klien e-melnya adalah satu-satunya yang menggunakannya pengecam sampul surat . Tujuannya adalah untuk memberitahu pengirim yang menghantar e-mel mesej ralat yang mungkin berkaitan dengannya. Format ID ini pada dasarnya dibiarkan kepada imaginasi penghantar. Kami tidak akan menggunakan ENVID dalam contoh kami:

MAIL DARIPADA: [email protected] RET = HDRS250 [email protected] … Pengirim ok

Rupa-rupanya, kami hanya mahu mendapatkan tajuk utama dalam DSN kami.

Sambungan Penerima DSN

RCPT TO: mendapat bahagian yang adil dari sambungan juga: NOTIFY dan ORCPT.

NOTIFY adalah hati sebenar DSN. Ia memberitahu pelayan bila untuk menghantar pemberitahuan status penghantaran. Nilai kemungkinan pertama adalah JANGAN yang bermaksud bahawa dalam keadaan apa-apa DSN mesti dikembalikan kepada pengirim. Ini tidak mungkin tanpa DSN. Kemudian ada SUCCESS, yang akan memberitahu anda apabila mel anda telah tiba di destinasinya. KEGAGALAN adalah rakan sejawatan SUCCESS: DSN akan tiba jika terjadi kesilapan semasa penghantaran. Pilihan terakhir adalah DELAY: anda akan dimaklumkan jika terdapat kelewatan yang tidak biasa dalam penghantaran, tetapi hasil penghantaran sebenarnya (kejayaan atau kegagalan) belum diputuskan. TIDAK PERNAH mestilah menjadi satu-satunya hujah jika ia ditentukan, tiga yang lain mungkin muncul dalam senarai, dibatasi oleh koma. KEBERHASILAN dan KEGAGALAN membuat pasukan yang cukup kuat bersama-sama, memberitahu anda dalam (hampir) sebarang kes yang terjadi pada mel anda.

Tujuan ORCPT adalah untuk memelihara asal penerima mesej e-mel, sebagai contoh, jika ia diteruskan ke alamat lain. Hujah kepada pilihan ini ialah alamat e-mel penerima asal bersama dengan jenis alamat. Jenis alamat datang terlebih dahulu, diikuti dengan titik koma dan akhirnya alamatnya. Sebagai contoh:

RCPT TO: [email protected] NOTIFY = KEGAGALAN, ORCPT DELAY = rfc822; [email protected]250 [email protected] … Penerima ok (akan beratur)

Ini diikuti oleh DATA seperti yang kita tahu dan akhirnya, diharapkan, pemberitahuan status penghantaran memberitahu anda tentang kejayaan.

Adakah DSN Bekerja?

Sudah tentu, semua kecantikan ini dan ia hanya akan berfungsi jika ejen pengangkutan mel dari pengirim kepada DSN sokongan penerima. Suatu hari nanti mereka akan.