6. Обнаружение и решение проблем
6.1. Гарантированная доставка и отклики по электронной почте
Когда получатель SMTP принимает порцию почты (передав отклик 250 OK в ответ на команду DATA), он принимает на себя ответственность за доставку или трансляцию сообщения. К этой ответственности следует относиться серьезно. Недопустима потеря сообщений по незначительным причинам, типа последующего «падения» хоста или предсказуемой нехватки ресурсов. Некоторые серьезные причины потери сообщений рассмотрены в следующем параграфе и параграфе 7.8.
Если после восприятия сообщения обнаруживается невозможность его доставки, получатель SMTP должен подготовить и передать уведомление об этом. При передаче уведомления должен использоваться пустой ("<>") путь возврата в конверте. Получателем такого уведомления должен быть адрес из обратного пути в конверте (или строке Return-Path:). Если обратный путь пустой ("<>"), для сервера SMTP недопустима передача уведомления. Обычно, ничто не запрещает на локальном уровне (в той же среде, к которой относится получатель SMTP) принимать решение о протоколировании или иной фиксации сведений о пустом пути возврата. Если адресом является явный маршрут source route, из него должен выделяться последний интервал (final hop).
В качестве примера предположим, что нужно передать уведомление для сообщения, принятого по команде:
MAIL FROM:<@a,@b:[email protected] >
Уведомление должно передаваться с помощью команды:
RCPT TO:<[email protected] >
Некоторые проблемы с доставкой после того, как система SMTP восприняла сообщение, неизбежны. Например, у принимающего сервера SMTP может не быть возможности проверки всех адресов доставки в командах RCPT по причине некритических (soft) ошибок в системе доменных имен, поскольку адресатом является список рассылки (см. описание RCPT), или сервер действует как транслятор и не имеет непосредственного доступа к системе доставки.
Во избежание дублирования сообщений в результате тайм-аутов, получатель SMTP должен пытаться минимизировать время отклика на индикатор завершения данных <CRLF>.<CRLF>. Подробное обсуждение этого вопроса приводится в RFC 1047 [40].