RFC: 5321
Оригинал: Simple Mail Transfer Protocol
Предыдущие версии: RFC 772, RFC 780, RFC 788, RFC 821, RFC 974, RFC 1425, RFC 1651, RFC 1869, RFC 2821
Категория: Проект стандарта
Дата публикации:
Автор:
Перевод: Николай Малых

3.6.3. Серверы представления сообщений как трансляторы

Существует множество клиентов, передающих почту (часто эти же программы служат для приема почты по протоколу POP3 или IMAP), которые не обеспечивают полную поддержку данной спецификации (например, поддержка очередей для последующей передачи). Для таких клиентов обычной практикой является организация частного соглашения с сервером для отправки ему всей почты с целью последующей обработки и доставки. Как указано здесь, SMTP не является идеальным решением для таких задач. Разработан стандартизованный протокол представления почтовых сообщений (RFC 4409 [18]), учитывающий опыт использования систем SMTP. В любом случае, частный характер соглашения между сервером и клиентами выводит этот вопрос за пределы данной спецификации.

Важно отметить, что записи MX могут указывать на серверы SMTP, которые действуют как шлюзы в другие среды, а не только выполняют трансляцию и окончательный прием почты (см. параграф 3.8 и раздел 5).

Если сервер SMTP принял на себя задачу трансляции почты и позднее обнаружил, что получатель указан некорректно или почту невозможно доставить по тем или иным причинам, этот сервер должен создать уведомление о невозможности доставки почты и переслать его отправителю недоставленного сообщения, указанному в обратном пути. Для уведомления следует (по возможности) использовать стандартные форматы (см., например RFC 3461 [32] и RFC 3464 [33]).

Это уведомление должно передаваться сервером SMTP с хоста-транслятора или хоста, который обнаружил невозможность доставки. Естественно, что для серверов SMTP недопустима отправка уведомлений о невозможностидоставки уведомлений. Одним из способов предотвращения петель при передаче сообщений об ошибках является использование пустой строки обратного пути в команде MAIL при передаче уведомления. При передаче такого сообщения строка обратного пути должна быть пустой — null (см. параграф 4.5.5). Команда MAIL с пустым обратным путем имеет вид:

MAIL FROM:<>

Как указано в параграфе 6.4, транслятору SMTP не нужно проверять и обрабатывать заголовки и тело транслируемых сообщений, а также недопустимо предпринимать какие-либо любые действия по отношению к сообщению, за исключением добавления к заголовку строки "Received:" (см. параграф 4.4) и (необязательной) попытки обнаружения петель в почтовой системе (см. параграф 6.3). Естественно, запрет распространяется и на изменение любых полей заголовка и текста сообщения (см. также параграф 7.9).

2007 - 2017 © Русские переводы RFC, IETF, ISOC.