Даже если кратко взглянуть на протокол SMTP, вы заметите, что помимо обычного HELO есть еще EHLO, который заставляет SMTP-сервер Extended рекламировать свои возможности, выходящие за рамки исходного стандарта. Одним из них является DSN. DSN? ДНК и ДДТ недостаточно?
Утверждать, что электронная почта ненадежна, что кто-то должен « … лучше кормить свой сервер; он съел мою почту… », не редкость. Тем не менее, нет особых оснований поддерживать эти подозрения.
Уведомление о состоянии доставки существует с RFC 821 (с 1982 года). Как только часть DATA протокола SMTP завершена и сервер принял электронное письмо для доставки, он отвечает за него. Если по какой-либо причине он не может получить его до получателя, он должен отправить его обратно с уведомлением об ошибке исходному отправителю. Это привело к неясной электронной почте.
Кроме того, это старое соглашение означало, что либо вы получили сообщение об ошибке, либо вы получили ничего , и в этом случае вы знали ничто : электронное письмо могло прийти или нет. Сообщения об ошибках во многих случаях были такими же полезными, как и без сообщений об ошибках. С электронной почтой становится все более и более важным, это больше не удовлетворительно (как будто это было раньше).
Расширения DSN для SMTP
RFC 1891 предлагает некоторые расширения протокола SMTP, которые должны привести к более надежной и более удобной системе DSN. Это набор расширений команд MAIL и RCPT.
Нет EHLO, нет веселья
Во-первых, мы должны убедиться, что сервер поддерживает DSN. Таким образом, мы должны сказать ему EHLO и внимательно слушать. Если он отвечает 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-VERB
250-8BITMIME
250-РАЗМЕР
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 FROM: sender@example.com RET = HDRS
250 sender@example.com ... Отправитель в порядке
По-видимому, мы только хотим вернуть заголовки в нашем DSN.
Расширения получателей DSN
RCPT TO: также получает свою долю расширений: NOTIFY и ORCPT.
УВЕДОМЛЕНИЕ – это настоящее сердце DSN. Он сообщает серверу когда отправить уведомление о состоянии доставки. Первым возможным значением является НИКОГДА, что означает, что ни при каких условиях DSN не должен возвращаться отправителю. Это было невозможно без DSN. Тогда есть УСПЕХ, который уведомит вас, когда ваша почта прибудет в пункт назначения. FAILURE – аналог УСПЕХА: DSN прибудет, если во время доставки произошла ошибка. Последний вариант – ЗАДЕРЖКА: вы будете уведомлены о необычной задержке доставки, но фактический результат доставки (успех или неудача) еще не определен. НИКОГДА не должен быть единственным аргументом, если он указан, остальные три могут появиться в списке, разделенном запятой. УСПЕХ и НЕДОСТАТКИ составляют довольно сильную команду вместе, рассказывая вам (почти) в любом случае, что случилось с вашей почтой.
Цель ORCPT – сохранить оригинального получателя сообщения электронной почты, например, если оно переадресовано на другой адрес. Аргументом для этой опции является адрес электронной почты исходного получателя вместе с типом адреса. Сначала указывается тип адреса, затем точка с запятой и, наконец, адрес. Например:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ...Получатель в порядке (будет в очереди)
За этим следуют ДАННЫЕ в том виде, в котором мы их знаем, и в конечном итоге, надеюсь, уведомление о состоянии доставки, уведомляющее вас об успехе.
DSN работает?
Конечно, все это прекрасно, и это будет работать только в том случае, если почтовые транспортные агенты от отправителя к получателю поддерживают DSN. Когда-нибудь они будут.
