Дори само кратък поглед към SMTP протокола ще забележите, че освен обичайното HELO, има и EHLO, което прави продължен SMTP сървърът рекламира възможностите си извън първоначалния стандарт. Един от тях е DSN. DSN? Дали ДНК и DDT не са достатъчни?
За да се твърди, че електронната поща е ненадеждна, някой трябва да " … захранват сървъра си по-добре; тя изяде пощата ми … "не е необичайно, но няма много причини да подкрепяме тези подозрения.
Доставка С СЪСТОЯНИЕ N Официалното съобщаване е наблизо след RFC 821 (от 1982 г.). Веднага след като частта от DATA на протокола SMTP завърши и сървърът приеме имейла за доставка, той отговаря за него. Ако по някаква причина не може да стигне до получателя, той трябва да го изпрати обратно с уведомление за грешката на оригиналния подател. Това доведе до някои неясни имейли.
Освен това тази стара конвенция означаваше, че имаш съобщение за грешка или имаш Нищо в който случай знаехте Нищо : имейлът може да е пристигнал или не. Съобщенията за грешки в много случаи бяха също толкова полезни, колкото и съобщенията за грешки. С електронната поща става все по-важно това вече не е задоволително (сякаш беше преди).
DSN разширения на SMTP
RFC 1891 предлага някои разширения на протокола SMTP, които трябва да доведат до по-надеждна и по-използваема система DSN. Това е набор от разширения на командите MAIL и RCPT.
Не EHLO, не е забавно
Първо, трябва да се уверим, че сървърът поддържа DSN. По този начин трябва да му кажем ЕХЛО и да го слушаме внимателно. Ако тя отговаря с DSN някъде в списъка с функции, можем да приемем, че ще може да изпълни нашите искания. Ако не, тогава не: можем да опитаме друг сървър или просто да се върнем към имейл без DSN. Например:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Слънце, 24 Авг 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Здравейте localhost 127.0.0.1, с удоволствие ви посрещам250 EXPN250 ГЛАГОЛ250-8BITMIME250 РАЗМЕР250 DSN250 OneX250 ETRN250 XUSR250 HELP За щастие наред с други неща намираме DSN. Следващата команда обикновено е MAIL FROM. С DSN това не е по-различно. Но има две допълнителни опции, които можете да издадете: RET и ENVID. Опцията RET е по-скоро произволно поставена в командата MAIL, но тя се вписва тук, както и навсякъде другаде. Целта е да се уточни колко от оригиналното ви съобщение трябва да бъде върнато в случай на неуспех на доставката. Валидните аргументи са FULL и HDRS. Първото означава, че цялото съобщение трябва да бъде включено в съобщението за грешка, HDRS инструктира сървъра да връща само заглавията на неуспешната поща. Ако RET не е посочено, сървърът трябва да направи това. В повечето случаи HDRS ще бъде стойността по подразбиране. ENVID наистина принадлежи на изпращача, тъй като тя или (по-скоро) нейният имейл клиент ще бъде единственият, който използва това идентификатор на плика , Неговата цел е да се каже на подателя кой имейл евентуално издаден съобщението за грешка съответства на. Форматът на този идентификационен номер основно се оставя на въображението на подателя. В нашия пример няма да използваме ENVID: ПОЩА ОТ: [email protected] RET = HDRS250 [email protected] … Sender ok Очевидно искаме само да върнем заглавията обратно в DSN. RCPT TO: получава също справедливия си дял от разширенията: NOTIFY и ORCPT. NOTIFY е истинското сърце на DSN. Тя казва на сървъра кога за изпращане на известие за състояние на доставка. Първата възможна стойност НИКОГА не означава, че при никакви обстоятелства DSN не трябва да се връща на подателя. Това не беше възможно без DSN. След това има успех, който ще ви уведоми, когато вашата поща е пристигнала на местоназначението си. FAILURE е насрещната страна на SUCCESS: DSN ще пристигне, ако възникне грешка по време на доставката. Последната опция е DELAY: ще бъдете уведомени, ако има необичайно забавяне на доставката, но резултатът от действителната доставка (успех или провал) все още не е решен. НИКОГА трябва да да бъде единственият аргумент, ако е посочен, другите три могат да се появят в списък, обозначен с запетая. УСПЕХЪТ и НЕПРАВИТЕЛСТВОТО компенсират един доста силен екип заедно, като ви казва (почти) всеки случай какво се е случило с вашата поща. Целта на ORCPT е да запази оригинал получател на имейл съобщение, например, ако бъде препратен към друг адрес. Аргументът към тази опция е имейл адресът на първоначалния получател заедно с типа адрес. Типът адрес е на първо място, последван от точка и запетая и накрая адреса. Например: RCPT TO: [email protected] NOTIFY = НЕЗАБАВНО, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Получател ok (ще бъде на опашка) Това е последвано от DATA, както го знаем, и в крайна сметка, надяваме се, уведомление за състоянието на доставката, което ви уведомява за успех. Разбира се, цялата тази красота и тя ще работи само, ако агентите за поща за транспортиране от изпращача до получателя поддържат DSN. Някой ден ще го направят. Разширенията на DSN Sender
Разширения за получатели на DSN
Дали DSN работи?
