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

RFC 5321, Страница 48 из 75

В приведенном выше тексте предполагается, что окончательные почтовые данные будут начинаться со строки обратного пути, за которой будет следовать одна или несколько строк с временными метками. После этих строк будет следовать оставшаяся часть почтовых данных — почтовый заголовок и тело сообщения (RFC 5322 [4]).

В некоторых случаях серверу SMTP сложно определить обеспечивает ли он окончательную доставку, поскольку пересылка и другие операции могут происходить после восприятия сообщения для доставки. Поэтому все последующие почтовые системы (трансляторы, шлюзы, системы пересылки) могут удалять строку обратного пути и перестраивать команду MAIL, обеспечивая в доставленном сообщении единственную строку обратного пути.

Return-path. Для серверов SMTP, обеспечивающих трансляцию, недопустимо проверять данные сообщения и, особенно, наличие поля заголовка Return-path. Сервер SMTP, обеспечивающий окончательную доставку, может удалять имеющийся заголовок Return-path перед добавлением своего.

Основным назначением Return-path является указание адреса, по которому следует доставлять сообщения об ошибках. Для однозначности следует включать в сообщение единственный вариант обратного пути. Системам, использующим синтаксис RFC 822 с отличным от SMTP транспортом, следует указывать однозначный адрес, связанный с транспортным конвертом, по которому должна возвращаться информация об ошибках (например, о невозможности доставки).

Историческое замечание: Приведенные в RFC 822 сведения, отвергающие использование заголовка Return-path (или адреса возврата из команды MAIL в конверте) для доставки информации об ошибках, неприменимы в среде Internet. Адрес обратного пути (копируемый в Return-path) должен использоваться для доставки всех сообщений об ошибках в процессе доставки.

В частности:

  • Шлюзам из SMTP в другие среды следует вставлять обратный путь, если у них нет информации о том, что другая среда также использует в адресах доменные имена Internet и поддерживает отдельный конверт с адресом отправителя.
  • Шлюзам из других сред в SMTP следует удалять из заголовка строку обратного пути и копировать эту информацию в конверт SMTP или объединять ее с присутствующей в конверте информацией из другой транспортной системы для построения обратного пути для команды MAIL в конверте SMTP.

Отчасти, это может произойти, если после приема нескольких адресов получателей и почтовых данных для них сервер SMTP обнаружит, что возможна доставка только некоторым из указанных адресатов. В таких случаях на команду DATA должен возвращаться отклик OK. Однако сервер SMTP должен подготовить и передать уведомление о невозможности доставки отправителю сообщения.

Страница 48 из 75

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