Ketahui bagaimana DSN bertujuan memperkenalkan status penghantaran ke e-mel SMTP.
Pernah Bertanya Apa Yang Terjadi pada E-mel Anda Dihantar?
Malah sekadar melihat ringkas pada protokol SMTP akan mendapati bahawa selain HELO biasa, terdapat juga EHLO, yang menjadikan pelayan SMTP Lanjutan 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 " ... memberi makan pelayan mereka dengan lebih baik; ia memakan emel saya ... " tidak biasa. Saya buat sendiri. Namun, tidak banyak alasan untuk menyokong syak wasangka ini.
Penghantaran S tatus N 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. Jika, atas sebab apa pun, ia tidak dapat meneruskannya kepada penerima yang mesti dihantar 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 tiada apa - apa yang anda tidak tahu apa-apa : e-mel itu 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 (jika ini tidak bermakna kepada anda, baca bagaimana SMTP berfungsi dan kemudian kembali ke sini.).
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 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 (masukan saya menjadi biru, keluaran pelayan hitam):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hello localhost [127.0.0.1], senang bertemu dengan anda
250-EXPN
250-KERTAS
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Untungnya, antara lain kita dapati DSN.
Sambungan Pengirim DSN
Perintah seterusnya biasanya adalah MAIL DAR :. 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 menjadikan kami pengecam sampul ini. 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 (imaginasi!):
MAIL DARIPADA: sender@example.com RET = HDRS
250 sender@example.com ... 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 apabila 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 sebagai arraved di destinasinya. KEGAGALAN adalah rakan sejawatan SUCCESS (!): DSN akan tiba jika terjadi kecemasan 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. JANGAN mesti satu-satunya hujah jika ia ditentukan, tiga yang lain mungkin muncul dalam senarai, dibatasi oleh koma. SUKSES dan KESALAHAN membuat pasukan yang cukup kuat bersama-sama (!), Memberitahu anda dalam (hampir) apa-apa perkara yang berlaku pada mel anda.
Tujuan ORCPT adalah untuk menyelamatkan penerima asal mesej e-mel, contohnya 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: support@example.com NOTIFY = KEGAGALAN, ORCPT DELAY = rfc822; support@example.com
250 support@example.com ... 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 dan kecantikan ini hanya akan berfungsi jika ejen pengangkutan mel dari pengirim kepada DSN sokongan penerima. Beberapa hari nanti mereka akan.