Разберете как DSN има за цел да въведе състоянието на доставка до SMTP имейл.
Някога се чудехте какво се е случило с имейла, който сте изпратили?
Дори само кратък преглед на SMTP протокола ще забележите, че освен обичайното HELO, има и EHLO, което прави Extended SMTP сървъра да рекламира възможностите си извън оригиналния стандарт. Един от тях е DSN. DSN? Дали ДНК и DDT не са достатъчни?
Да се твърди, че имейлът е ненадежден, че някой трябва да " ... храни сървъра си по-добре, той изяде пощата ми ... " не е необичайно. Аз го правя сам. И все пак, няма много причини да се подкрепят тези подозрения.
Доставка S tatus N otification е около RFC 821 (от 1982 г.). Веднага след като частта от DATA на протокола SMTP завърши и сървърът приеме имейла за доставка, той отговаря за него. Ако по някаква причина не може да го получи до получателя, трябва да го изпрати обратно, като уведоми за грешката на оригиналния подател. Това доведе до някои неясни имейли .
Освен това тази стара конвенция означаваше, че или имате съобщение за грешка, или не сте получили нищо, в който случай не сте знаели нищо : електронната поща може би е пристигнала или не. Съобщенията за грешки в много случаи бяха също толкова полезни, колкото и съобщенията за грешки. С електронната поща става все по-важно това вече не е задоволително (сякаш беше преди).
DSN разширения на SMTP
RFC 1891 предлага някои разширения на протокола SMTP , които трябва да доведат до по-надеждна и по-използваема система DSN. Това е набор от разширения на командите MAIL и RCPT (ако това не означава нищо за вас, прочетете как функционира SMTP и след това се върнете тук).
Не EHLO, не е забавно
Първо, трябва да се уверим, че сървърът поддържа 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 Здравейте localhost [127.0.0.1], с удоволствие ви посрещам
250 EXPN
250 ГЛАГОЛ
250-8BITMIME
250 РАЗМЕР
250 DSN
250 OneX
250 ETRN
250 XUSR
250 HELP
За щастие наред с други неща намираме DSN.
Разширенията на DSN Sender
Следващата команда обикновено е MAIL FROM :. С DSN това не е по-различно. Но има две допълнителни опции, които можете да издадете: RET и ENVID.
Опцията RET е по-скоро произволно поставена в командата MAIL, но тя се вписва тук, както и навсякъде другаде. Целта е да се уточни колко от оригиналното ви съобщение трябва да бъде върнато в случай на неуспех на доставката. Валидните аргументи са FULL и HDRS. Първото означава, че цялото съобщение трябва да бъде включено в съобщението за грешка, HDRS инструктира сървъра да връща само заглавията на неуспешната поща. Ако RET не е посочено, сървърът трябва да направи това. В повечето случаи HDRS ще бъде стойността по подразбиране.
ENVID наистина принадлежи на изпращача, тъй като тя или (по-скоро) нейният имейл клиент ще бъде единственият, който ни прави този идентификатор на плика . Неговата цел е да се каже на подателя кой имейл евентуално издаден съобщението за грешка съответства на. Форматът на този идентификационен номер основно се оставя на въображението на подателя. Ние няма да използваме ENVID в нашия пример (въображение!):
ПОЩА ОТ: sender@example.com RET = HDRS
250 sender@example.com ... Sender ok
Очевидно искаме само да върнем заглавията обратно в DSN.
Разширения за получатели на DSN
RCPT TO: получава също справедливия си дял от разширенията: NOTIFY и ORCPT.
NOTIFY е истинското сърце на DSN. Той съобщава на сървъра кога да изпрати известие за състоянието на доставката. Първата възможна стойност НИКОГА не означава, че при никакви обстоятелства DSN не трябва да се връща на подателя. Това не беше възможно без DSN. След това има успех, който ще ви уведоми, когато вашата поща, както е разрешено на местоназначението. FAILURE е насрещната страна на SUCCESS (!): DSN ще пристигне, ако се появи аромат по време на доставката. Последната опция е DELAY: ще бъдете уведомени, ако има необичайно забавяне на доставката, но резултатът от действителната доставка (успех или провал) все още не е решен. Никога не трябва да бъде единственият аргумент, ако е посочен, другите три могат да се появят в списък, обозначен с запетая. УСПЕХЪТ и НЕПРАВИТЕЛСТВОТО компенсират доста силен екип заедно (!), Като ви казва (почти) всеки случай какво се е случило с вашата поща.
Целта на ORCPT е да запази първоначалния получател на имейл съобщение, например ако бъде препратен на друг адрес. Аргументът към тази опция е имейл адресът на първоначалния получател заедно с типа адрес. Типът адрес е на първо място, последван от точка и запетая и накрая адреса. Например:
RCPT TO: support@example.com NOTIFY = НЕЗАБАВНО, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Получател ok (ще бъде на опашка)
Това е последвано от DATA, както го знаем, и в крайна сметка, надяваме се, уведомление за състоянието на доставката, което ви уведомява за успех.
Дали DSN работи?
Разбира се, цялата тази красота и остроумие ще работят само ако агентите за поща за пренос на данни от подател до получател поддържат DSN. Някой ден ще го направят.