Даведайцеся, як DSN мэтай ўвесці статус дастаўкі для SMTP электроннай пошты.
Заўсёды Здзівіўся Што здарылася з E-mail Вы Перададзеныя?
Нават проста беглы погляд на пратаколе SMTP будзе вам заўважыць , што апроч звычайнага HELO, ёсць таксама EHLO, што робіць пашыраны сервер SMTP рэкламаваць свае магчымасці за межамі першапачатковага стандарту. Адным з іх з'яўляецца DSN. DSN? Ці з'яўляюцца ДНК і ДДТ не хапае?
Для таго, каб сцвярджаць , што электронная пошта з'яўляецца ненадзейным, што хто - то павінен «... карміць іх сервер лепш, ён з'еў маю пошту ...» не з'яўляецца рэдкасцю. Я зраблю гэта сам. Тым не менш, існуе не так шмат прычын, каб падтрымаць гэтыя падазрэньні.
Дастаўка S ОСТОЯНИЕ N otification вакол з RFC 821 (з 1982 года). Як толькі частка дадзеных па SMTP пратаколу завершана , і сервер прыняў пошту для дастаўкі ён нясе адказнасць за гэта. Калі па якой-небудзь прычыне, ён не можа атрымаць яго да атрымальніка ён павінен адправіць яго назад з паведамленнем пра памылку да зыходнага адпраўніку. Гэта прывяло да якіх - то незразумелым электроннай пошце .
Акрамя таго, гэтая старая канвенцыя азначае , што альбо вы атрымалі памылку паведамленні або вы не атрымалі нічога , у гэтым выпадку вы нічога не ведалі: электронная пошта можа прыбыць ці не. Паведамленні пра памылкі ў многіх выпадках былі гэтак жа карысна, як якія-небудзь паведамленні пра памылкі. З электроннай поштай не становіцца ўсё больш і больш важным, гэта ўжо не здавальняючым (як калі б гэта было раней).
DSN Пашырэньні SMTP
RFC 1891 прапануе некаторыя пашырэння SMTP пратаколу , які павінен прывесці да больш надзейнай і больш карыснай сістэме апавяшчэння аб дастаўцы. Ён уяўляе сабой набор пашырэнняў для MAIL і RCPT каманды (калі гэта нічога не значыць для вас, чытайце хау SMTP працуе і затым вярнуцца сюды.).
Няма EHLO, No Fun
Па-першае, мы павінны пераканацца, што сервер падтрымлівае DSN. Такім чынам, мы павінны сказаць, EHLO да яго і ўважліва слухаць. Калі ён адказвае DSN somewher ў спісе функцый, мы можам выказаць здагадку, што яна будзе ў стане абслугоўваць нашы запыты. Калі няма, то няма: мы можам паспрабаваць іншы сервер або проста падаць назад на электронную пошту без DSN. Напрыклад (мой ўваход з'яўляецца сінім, чорным выхадам сервера):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Нд, 24 жнiуня 1997 18:23:22 +0200
EHLO лакальны
250-larose.magnet.at Здравствуйте лакальны [127.0.0.1], рады сустрэцца з вамі
250-EXPN
250-дзеяслоў
250-8BITMIME
250-РАЗМЕР
250-апавяшчэнне аб дастаўцы
250-ONEX
250-ETRN
250-XUSR
250 HELP
На шчасце, сярод іншых рэчаў, якія мы знаходзім DSN.
Пашырэння адпраўніка апавяшчэнняў аб дастаўцы
Наступная каманда, як правіла, з'яўляецца MAIL FROM:. З DSN, гэта нічым не адрозніваецца. Але ёсць дзве дадатковыя опцыі вы можаце выдаваць: RET і ENVID.
Опцыя RET была даволі адвольна змешчаны ў камандзе MAIL, але ён падыходзіць тут як гэта было б у іншым месцы. Мэта складаецца ў тым, каб паказаць, колькі зыходнае паведамленне павінна быць вернута ў выпадку збою дастаўкі. Дапушчальныя аргументы поўнай і HDRS. Першыя азначае, што поўнае паведамленне варта ўключыць ў паведамленні пра памылку, HDRS інструктуе сервер вяртаюць толькі загалоўкі якая не адбылася пошты. Калі RET не пазначаны, то на сервер, што рабіць. У большасці выпадкаў HDRS будзе значэнне па змаўчанні.
ENVID сапраўды належыць адпраўніку , як яна ці (а) яе кліенту электроннай пошты будзе толькі адзін , што робіць нас гэтым канверт ідэнтыфікатара. Яго мэта складаецца ў тым, каб паведаміць адпраўніку, які адрас электроннай пошты паведамленне, магчыма, выдаецца памылка адпавядае. Фармат гэтага ідэнтыфікатара ў асноўным засталося ва ўяўленні адпраўніка. Мы не будзем выкарыстоўваць ENVID у нашым прыкладзе (ўяўленне!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Sender нармальна
Мяркуючы па ўсім, мы толькі хочам атрымаць загалоўкі таму ў нашым DSN.
Пашырэння DSN атрымальнікаў
RCPT TO: атрымлівае сваю справядлівую долю пашырэньні, а таксама: NOTIFY і ORCPT.
Апавяшчэнне рэальнае сэрца DSN. Ён паведамляе сервер , калі для адпраўлення апавяшчэння аб стане дастаўкі. Першае магчымае значэнне ніколі не азначае, што ні пры якіх абставінах апавяшчэння аб дастаўцы павінны быць вернутыя адпраўніку. Гэта было немагчыма без DSN. Тады ёсць УСПЕХ, які паведаміць вам, калі ваша пошта, як arraved ў пункце прызначэння. Няўдача аналаг ПОСПЕХУ ў (!): А DSN прыбудзе, калі arror адбыўся падчас родаў. Апошні варыянт DELAY: вы будзеце апавешчаныя, калі маецца незвычайная затрымка ў дастаўцы, але вынік фактычнай пастаўкі (у поспех або няўдача), пакуль не вырашана. НІКОЛІ не павінен быць толькі адзін аргумент , калі ён паказаны, то астатнія тры могуць з'явіцца ў спісе значэнняў , падзеленых коскі. Поспех і няўдача складаюць для даволі моцнай каманды разам (!), Кажуць вам (амаль) любым выпадку, што здарылася з вашай поштай.
Мэта ORCPT з'яўляецца налітае першапачатковым атрымальнікам паведамленні электроннай пошты, калі ён накіроўваецца на іншы адрас. Аргумент гэтай опцыі з'яўляецца адрасам электроннай пошты арыгінальнага атрымальніка разам з тыпам адрасы. Тып адрасы прыходзіць першым, а затым кропкай з коскі і, нарэшце, адрас. Напрыклад:
RCPT TO: support@example.com NOTIFY = FAILURE, затрымка ORCPT = RFC822; support@example.com
250 support@example.com ... Адрасат нармальна (у чаргу)
Гэта вынікае з дадзеных, як мы ведаем, і ў рэшце рэшт, мы спадзяемся, апавяшчэнне аб дастаўцы з паведамленнем аб поспеху.
Ці ёсць DSN працы?
Вядома, уся гэтая прыгажосць і розум будзе працаваць толькі калі пошта транспартных агентаў ад адпраўніка да атрымальніка падтрымкі DSN. У адзін цудоўны дзень яны будуць.