Дознајте како DSN има за цел да го претстави статусот на испорака до е-пошта на SMTP.
Дали некогаш сте се прашувале што се случило со испратена е-пошта?
Дури и само краток поглед на SMTP протоколот ќе забележите дека покрај вообичаениот HELO, исто така постои и EHLO, што го прави продолжен SMTP сервер да ги рекламира своите способности надвор од оригиналниот стандард. Една од нив е DSN. DSN? Дали ДНК и ДДТ не се доволни?
Да се тврди дека е-поштата е несигурна, дека некој треба " ... да го нахрани нивниот сервер подобро, јадеше мојата пошта ... " не е невообичаено. Јас го правам тоа. Сепак, нема многу причина да ги поддржиме овие сомневања.
Испорака на тастатурата N otification е околу од RFC 821 (од 1982 година). Веднаш штом DATA-от дел од протоколот SMTP е завршен и серверот го прифатил е-поштата за испорака, тој е одговорен за тоа. Ако, поради некоја причина, не може да го добие преку примателот, мора да го испрати со известување за грешката до оригиналниот испраќач. Ова резултираше со некои нејасни е -пошта .
Освен тоа, оваа стара конвенција значеше дека или добивте порака за грешка или немав ништо во кој случај не знаевте ништо : е-поштата можеби пристигна или не може. Пораките за грешки во многу случаи беа исто толку корисни колку и пораки за грешки. Со тоа што е-поштата станува се поважна, ова повеќе не е задоволително (како да беше порано).
DSN екстензии до SMTP
RFC 1891 предлага некои проширувања на SMTP протоколот што треба да резултира со посигурен и поупотреблив DSN систем. Тоа е збир на проширувања на MAIL и RCPT командите (ако тоа не значи ништо за вас, прочитајте како функционира SMTP и потоа се враќа тука).
Не ЕХЛО, Не Забава
Прво, мораме да бидеме сигурни дека серверот поддржува DSN. Така, треба да му кажеме на ЕХЛО и внимателно да слуша. Ако тоа одговара со DSN некаде во списокот со карактеристики, можеме да претпоставиме дека ќе може да ги исполни нашите барања. Ако не, тогаш не: можеме да пробаме друг сервер или едноставно да се вратиме на е -пошта без DSN. На пример (мојот влез е сино, излезот на серверот е црно):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Не, 24 Август 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Здраво локален компјутер [127.0.0.1], со задоволство ве запознав
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 ПОМОШ
За среќа, меѓу другото наоѓаме DSN.
DSN испраќачи на екстензии
Следната команда обично е MAIL FROM :. Со DSN, ова не се разликува. Но, постојат две дополнителни опции што може да ги издадете: RET и ENVID.
Опцијата RET беше прилично произволно поставена во командата MAIL, но тука се вклопува и на друго место. Целта е да одредите колку од вашата оригинална порака треба да се врати во случај на неуспех во испораката. Валидните аргументи се FULL и HDRS. Првиот значи дека целосната порака треба да биде вклучена во пораката за грешка, HDRS му наредува на серверот само да ги врати заглавјата на неуспешната пошта. Ако RET не е одредено, серверот треба да направи што да прави. Во повеќето случаи HDRS ќе биде стандардната вредност.
ENVID навистина му припаѓа на испраќачот, бидејќи таа или (туку) нејзиниот е-мејл клиент ќе биде единствената која нè прави од овој плик идентификатор . Нејзината цел е да му каже на испраќачот дека е-пошта е веројатно издадена порака за грешка одговара на. Форматот на оваа лична карта во основа е оставен на имагинацијата на испраќачот. Ние нема да го користиме ENVID во нашиот пример (имагинација!):
MAIL ОД: sender@example.com RET = HDRS
250 sender@example.com ... Испраќачот е во ред
Очигледно, ние само сакаме да ги добиеме заглавјата назад во нашата DSN.
Проширувања за примачи на DSN
RCPT TO: добива фер удел на проширувања: NOTIFY и ORCPT.
ЗАБЕЛЕШКА е вистинското срце на DSN. Таа му кажува на серверот кога ќе испрати известување за статусот на испорака. Првата можна вредност е НИКОГАШ што значи дека под никакви околности DSN мора да се врати на испраќачот. Ова не беше можно без DSN. Потоа, тука е УСПЕХ, што ќе ве извести кога вашата пошта ќе биде напишана на нејзината дестинација. Неуспех е колега на УСПЕХ (!): DSN ќе пристигне ако се појави грешка за време на испораката. Последната опција е DELAY: ќе бидете известени ако има необично одложување во испораката, но вистинскиот резултат на испорака (успех или неуспех) сè уште не е одлучен. НИКОГАШ не мора да биде единствениот аргумент ако го наведе, другите три може да се појават на листа, ограничена со запирка. УСПЕШНОСТА И НЕДОСТАТОКОТ се составува прилично силен тим заедно (!), Кој ви кажува во (речиси) секој случај што се случи со вашата пошта.
Целта на ORCPT е да го заштити оригиналниот примач на е-порака, на пример ако се пренасочи на друга адреса. Аргументот за оваа опција е е-поштенската адреса на оригиналниот примач, заедно со типот адреса. Првиот тип на адреса е проследен со точка-запирка и, конечно, адресата. На пример:
RCPT TO: support@example.com ЗАБЕЛЕШКА = НЕШТО, ЗАДОЛЖИТЕЛНА ORCPT = rfc822; support@example.com
250 support@example.com ... Примачот е во ред (ќе чека ред)
Ова е проследено со ПОДАТОЦИ како што го знаеме и на крајот, се надевам, известување за статусот на испорака што ве известува за успех.
Дали DSN работи?
Се разбира, сета оваа убавина и духовитост ќе работи само ако агентите за транспорт на пошта од испраќачот до примачот поддржуваат DSN. Некој ден ќе.