ຊອກຮູ້ວິທີການ DSN ມີຈຸດປະສົງເພື່ອສະເຫນີສະຖານະການຈັດສົ່ງອີເມວ SMTP.
ເຄີຍຕົກຕະລຶງວ່າເກີດຫຍັງຂຶ້ນກັບອີເມວທີ່ທ່ານສົ່ງ?
ເຖິງແມ່ນວ່າພຽງແຕ່ເບິ່ງສັ້ນໆຢູ່ໃນ ໂປຣແກຣມ SMTP ທ່ານຈະສັງເກດເຫັນວ່ານອກເຫນືອຈາກ HELO ປົກກະຕິແລ້ວ, ຍັງມີ EHLO, ເຊິ່ງເຮັດໃຫ້ Server SMTP ຂະຫຍາຍ ຄວາມສາມາດຂອງຕົນອອກຈາກມາດຕະຖານເດີມ. ຫນຶ່ງໃນເຫຼົ່ານີ້ແມ່ນ DSN. DSN? DNA ແລະ DDT ບໍ່ພຽງພໍ?
ການໂຕ້ຖຽງວ່າອີເມວບໍ່ຫນ້າເຊື່ອຖື, ວ່າບາງຄົນຄວນ " ... ອາຫານເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາດີກວ່າ, ມັນກິນເມລຂອງຂ້ອຍ ... " ບໍ່ແມ່ນເລື່ອງແປກຫຍັງ. ຂ້ອຍເຮັດມັນດ້ວຍຕົນເອງ. ແຕ່, ບໍ່ມີເຫດຜົນຫຼາຍທີ່ຈະສະຫນັບສະຫນູນຄວາມສົງໄສເຫຼົ່ານີ້.
ການຈັດສົ່ງສິນຄ້າໄດ້ຖືກປະມານນັບຕັ້ງແຕ່ RFC 821 (ຈາກ 1982). ທັນທີທີ່ສ່ວນ DATA ຂອງໂປຣແກຣມ SMTP ຖືກສໍາເລັດແລ້ວແລະເຄື່ອງແມ່ຂ່າຍໄດ້ຮັບການຍອມຮັບອີເມວສໍາລັບການຈັດສົ່ງມັນແມ່ນຄວາມຮັບຜິດຊອບສໍາລັບມັນ. ຖ້າສໍາລັບເຫດຜົນໃດກໍ່ຕາມ, ມັນບໍ່ສາມາດເອົາມັນໄປຫາຜູ້ຮັບໄດ້, ມັນຕ້ອງສົ່ງຄືນກັບການແຈ້ງເຕືອນຂອງຄວາມຜິດພາດຕໍ່ຜູ້ສົ່ງຕົ້ນສະບັບ. ນີ້ໄດ້ຜົນໃນ ອີເມວທີ່ ບໍ່ຖືກຕ້ອງ.
ນອກຈາກນັ້ນ, ສົນທິສັນຍາເກົ່ານີ້ຫມາຍຄວາມວ່າທ່ານໄດ້ ຂໍ້ ຄວາມສະແດງຂໍ້ ຜິດພາດ ຫຼືທ່ານ ບໍ່ມີຫຍັງ ໃນກໍລະນີທີ່ທ່ານບໍ່ຮູ້ ຫຍັງເລີຍ : ອີເມວອາດຈະມາຮອດຫຼືມັນອາດຈະບໍ່. ຂໍ້ຄວາມຜິດພາດໃນຫຼາຍໆກໍລະນີແມ່ນພຽງແຕ່ເປັນປະໂຫຍດທີ່ບໍ່ມີຂໍ້ຄວາມຜິດພາດ. ມີອີເມວກາຍເປັນສິ່ງທີ່ສໍາຄັນກວ່ານີ້ແລະບໍ່ມີຄວາມຫນ້າພໍໃຈ (ເຊັ່ນວ່າກ່ອນຫນ້ານີ້).
DSN Extensions to SMTP
RFC 1891 ສະເຫນີບາງສ່ວນຂະຫຍາຍຂອງໂປຣແກຣມ SMTP ທີ່ຄວນຈະສົ່ງຜົນໃຫ້ລະບົບ DSN ທີ່ຫນ້າເຊື່ອຖືແລະສາມາດໃຊ້ໄດ້ຫຼາຍຂຶ້ນ. ມັນເປັນຊຸດຂອງການຂະຫຍາຍຄໍາສັ່ງ MAIL ແລະ RCPT (ຖ້າວ່ານີ້ຫມາຍຄວາມວ່າບໍ່ມີໃຫ້ທ່ານ, ອ່ານ ວິທີການເຮັດວຽກຂອງ SMTP ແລະຫຼັງຈາກນັ້ນກັບຄືນມານີ້).
ບໍ່ມີ EHLO, ບໍ່ມີຄວາມມ່ວນ
ຫນ້າທໍາອິດ, ພວກເຮົາຕ້ອງໃຫ້ແນ່ໃຈວ່າເຄື່ອງແມ່ຂ່າຍສະຫນັບສະຫນູນ DSN. ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງເວົ້າ EHLO ໃຫ້ລາວແລະຟັງຢ່າງລະມັດລະວັງ. ຖ້າຫາກວ່າມັນຕອບກັບ DSN somewhere ໃນບັນຊີລາຍຊື່ຄຸນນະສົມບັດທີ່ພວກເຮົາສາມາດສົມມຸດວ່າມັນຈະສາມາດຮັບໃຊ້ການຮ້ອງຂໍຂອງພວກເຮົາ. ຖ້າບໍ່, ຫຼັງຈາກນັ້ນບໍ່: ພວກເຮົາສາມາດລອງໃຊ້ເຄື່ອງແມ່ຂ່າຍອື່ນຫຼືພຽງແຕ່ກັບຄືນໄປຫາ ອີເມວ ໂດຍບໍ່ຕ້ອງ DSN. ຕົວຢ່າງ: (ຂໍ້ມູນຂອງຂ້ອຍແມ່ນສີຟ້າ, ຜົນຜະລິດຂອງເຄື່ອງແມ່ຂ່າຍສີດໍາ):
220 larosemagnetat ESMTP Sendmail 886/886 Sun, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at ສະບາຍດີ localhost [127.0.0.1], ຍິນດີທີ່ຈະພົບທ່ານ
250-EXPN
250 ເອກະສານ
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
ໂຊກດີ, ໃນບັນດາສິ່ງອື່ນໆທີ່ພວກເຮົາຊອກຫາ DSN.
DSN Sender Extensions
ຄໍາສັ່ງຕໍ່ໄປໂດຍປົກກະຕິແມ່ນ MAIL FROM:. ມີ DSN, ນີ້ແມ່ນບໍ່ແຕກຕ່າງກັນ. ແຕ່ມີສອງຕົວເລືອກເພີ່ມເຕີມທີ່ທ່ານອາດຈະອອກ: RET ແລະ ENVID.
ຕົວເລືອກ RET ຖືກຕັ້ງໄວ້ຢູ່ໃນຄໍາສັ່ງ MAIL ແທນທີ່ຈະຢູ່ໃນຄໍາສັ່ງ MAIL, ແຕ່ວ່າມັນເຫມາະສົມນີ້ແລະມັນຈະຢູ່ບ່ອນອື່ນ. ຈຸດປະສົງແມ່ນເພື່ອກໍານົດຈໍານວນຂອງຂໍ້ຄວາມຕົ້ນສະບັບຂອງທ່ານຄວນຈະຖືກສົ່ງກັບຄືນໃນກໍລະນີຂອງການລົ້ມເຫຼວຂອງການຈັດສົ່ງ. ການໂຕ້ຖຽງທີ່ຖືກຕ້ອງແມ່ນ FULL ແລະ HDRS. ອະດີດຫມາຍຄວາມວ່າຂໍ້ຄວາມຄົບຖ້ວນຄວນຖືກລວມເຂົ້າໃນຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດ, HDRS ແນະນໍາໃຫ້ເຄື່ອງແມ່ຂ່າຍກັບຄືນຫົວຂໍ້ຂອງອີເມວລົ້ມເຫລວເທົ່ານັ້ນ. ຖ້າ RET ບໍ່ໄດ້ກໍານົດ, ມັນແມ່ນຂຶ້ນກັບເຄື່ອງແມ່ຂ່າຍທີ່ຕ້ອງເຮັດ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ HDRS ຈະເປັນຄ່າເລີ່ມຕົ້ນ.
ENVID ກໍ່ເປັນຂອງຜູ້ສົ່ງເປັນນາງຫຼື (ແທນທີ່ຈະ) ລູກຄ້າອີເມວຂອງນາງຈະເປັນຫນຶ່ງດຽວທີ່ເຮັດໃຫ້ພວກເຮົາມີ ຕົວລະບຸຕົວຫນັງສື ນີ້. ຈຸດປະສົງຂອງມັນແມ່ນບອກຜູ້ສົ່ງທີ່ອີເມວຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດທີ່ອາດອອກມາເທົ່າກັບ. ຮູບແບບຂອງ ID ນີ້ແມ່ນພື້ນຖານໄວ້ໃຫ້ກັບຈິນຕະນາການຂອງຜູ້ສົ່ງ. ພວກເຮົາຈະບໍ່ນໍາໃຊ້ ENVID ໃນຕົວຢ່າງຂອງພວກເຮົາ (imagination!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com Sender ok
ປາກົດຂື້ນ, ພວກເຮົາພຽງແຕ່ຕ້ອງການທີ່ຈະໄດ້ຮັບ headers ກັບຄືນໃນ DSN ຂອງພວກເຮົາ.
DSN Recipient Extensions
RCPT TO: ໄດ້ຮັບສ່ວນແບ່ງຍຸດຕິທໍາຂອງການຂະຫຍາຍເຊັ່ນດຽວກັນ: NOTIFY ແລະ ORCPT.
NOTIFY ແມ່ນຫົວໃຈທີ່ແທ້ຈິງຂອງ DSN. ມັນບອກເຄື່ອງແມ່ຂ່າຍ ໃນເວລາທີ່ ຈະສົ່ງແຈ້ງການສະຖານະການຈັດສົ່ງ. ມູນຄ່າທີ່ເປັນໄປໄດ້ຄັ້ງທໍາອິດແມ່ນບໍ່ມີຄວາມຫມາຍທີ່ວ່າພາຍໃຕ້ເງື່ອນໄຂໃດກໍ່ຕາມ DSN ບໍ່ຕ້ອງສົ່ງຄືນໃຫ້ຜູ້ສົ່ງ. ນີ້ແມ່ນບໍ່ເປັນໄປໄດ້ໂດຍບໍ່ມີ DSN. ຫຼັງຈາກນັ້ນ, ມີ SUCCESS, ເຊິ່ງຈະແຈ້ງໃຫ້ທ່ານໃນເວລາທີ່ຈົດຫມາຍຂອງທ່ານໄດ້ຖືກຂູດຢູ່ທີ່ຈຸດຫມາຍປາຍທາງຂອງມັນ. ຄວາມລົ້ມເຫຼວແມ່ນຄູ່ຮ່ວມງານຂອງ SUCCESS (!): DSN ຈະມາຮອດຖ້າຫາກວ່າມີຄວາມຫຍຸ້ງຍາກໃນການຈັດສົ່ງ. ຕົວເລືອກສຸດທ້າຍແມ່ນ DELAY: ທ່ານຈະຖືກແຈ້ງໃຫ້ຊາບວ່າມີການຊັກຊ້າທີ່ຜິດພາດໃນການຈັດສົ່ງ, ແຕ່ຜົນໄດ້ຮັບຂອງການຈັດສົ່ງທີ່ແທ້ຈິງ (ຜົນສໍາເລັດຫຼືຄວາມລົ້ມເຫລວ) ແມ່ນຍັງບໍ່ທັນໄດ້ຕັດສິນໃຈເທື່ອ. ບໍ່ ຄວນຈະ ເປັນການໂຕ້ຖຽງເທົ່ານັ້ນຖ້າມັນລະບຸ, ສາມອັນອື່ນອາດຈະປາກົດຢູ່ໃນບັນຊີລາຍຊື່, ຖືກກໍານົດໂດຍສະມະການ. SUCCESS ແລະ FAILURE ເຮັດໃຫ້ທີມງານທີ່ມີຄວາມເຂັ້ມແຂງທີ່ດີ (!), ບອກທ່ານໃນ (ເກືອບ) ກໍລະນີທີ່ເກີດຂຶ້ນກັບອີເມວຂອງທ່ານ.
ຈຸດປະສົງຂອງ ORCPT ແມ່ນເພື່ອປົກປັກຮັກສາຜູ້ຮັບ ຕົ້ນສະບັບ ຂອງຂໍ້ຄວາມອີເມວ, ສໍາລັບຕົວຢ່າງ, ຖ້າມັນຖືກສົ່ງໄປຫາທີ່ຢູ່ອື່ນ. ການໂຕ້ຖຽງກັບຕົວເລືອກນີ້ແມ່ນທີ່ຢູ່ອີເມວຂອງຜູ້ຮັບຕົ້ນສະບັບພ້ອມກັບປະເພດທີ່ຢູ່. ປະເພດທີ່ຢູ່ເບື້ອງຕົ້ນມາເປັນຄັ້ງທໍາອິດ, ປະຕິບັດຕາມໂດຍລໍາດັບແລະໃນທີ່ສຸດແມ່ນຢູ່. ຍົກຕົວຢ່າງ:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822 support@example.com
250 support@example.com ... ຜູ້ຮັບ ok (ຈະວາງແຖວ)
ນີ້ແມ່ນປະຕິບັດຕາມຂໍ້ມູນດັ່ງທີ່ພວກເຮົາຮູ້ແລ້ວແລະໃນທີ່ສຸດ, ຫວັງວ່າ, ການແຈ້ງການສະຖານະການຈັດສົ່ງແຈ້ງໃຫ້ທ່ານຊາບຜົນສໍາເລັດ.
DSN ເຮັດວຽກບໍ?
ແນ່ນອນ, ທັງຫມົດຄວາມງາມແລະ wit ນີ້ຈະເຮັດວຽກພຽງແຕ່ຖ້າຫາກວ່າຕົວແທນການຂົນສົ່ງເມລຈາກຜູ້ສົ່ງກັບຜູ້ສະຫນັບສະຫນູນ DSN. ບາງມື້ເຂົາເຈົ້າຈະ.