RFC: 1123
Оригинал: Requirements for Internet Hosts - Application and Support
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

5.3.7. Почтовый шлюз

Передача почты между различными почтовыми средами, использующими разные форматы и протоколы, является сложной задачей, для которой еще нет должного уровня стандартизации (см. примеры в [RFC987], [RFC1026]). Однако здесь приведены некоторые общие требования для почтовых шлюзов, обеспечивающих пересылку между Internet и другими почтовыми средами.

  • Пол заголовков могут переписываться при необходимости в процессе обработки сообщений почтовыми шлюзами.

    • Обсуждение
    • Основным вопросом является интерпретация локальной части адреса, рассмотренная в параграфе 5.2.16. Инородные почтовые системы при передаче сообщений в Internet обычно используют подмножество заголовков RFC 822, но некоторые из почтовых систем не имеют эквивалента конвертов SMTP. Следовательно, когда сообщение покидает среду Internet может потребоваться включение информации из конверта SMTP в заголовок сообщения. Возможным решением является создание новых полей заголовка для передачи информации из конверта (например, X-SMTP-MAIL: и X-SMTP-RCPT:); однако такое решение может потребовать изменений в почтовых программах чужой среды.
  • При пересылке сообщений в среду Internet или из нее, шлюз должен подготовить свою строку Received:, но недопустимо менять содержимое других строк Received: в полученном заголовке.

    • Обсуждение
    • Это требование является частью общих правил для строки Received:, рассмотренных в параграфе 5.2.8 и приведено здесь только для напоминания.

      Поля Received: сообщений из другой среды могут не соответствовать в точности RFC 822. Однако, наиболее важным применением строк Received: является обнаружение почтовых отказов и такая отладка может быть испорчена шлюзами, которые пытаются править строки Received:.

      Для шлюзов настоятельно рекомендуется указывать среду и протокол в предложениях "via" строки Received:, доставляемой шлюзом.

  • Со стороны Internet шлюзу рекомендуется принимать все допустимые форматы адресов в командах SMTP и заголовках RFC 822, а так же все допустимые сообщения RFC 822. Хотя шлюз должен воспринимать явно указанные маршруты RFC 822 (формат "@...:") в заголовке RFC 822 или в конверте, шлюз не обязан действовать на маршруте от отправителя (см. 5.2.6 и 5.2.19)

    • Обсуждение
    • Часто возникает искушение ограничить диапазон адресов, воспринимаемых почтовым шлюзом для упрощения трансляции адресов в форматы другой среды. Такая практика основывается на предположении, что пользователи почты имеют контроль над всеми адресами, по которым их почтовые программы шлют сообщения почтовому шлюзу. На практике, однако, пользователи имеют ограниченный контроль над адресами, которые они в конечном итоге используют, поскольку почтовые программы могут свободно менять адреса в любой допустимый формат RFC 822.
  • Шлюз должен гарантировать, что все поля заголовков сообщений, пересылаемых в Internet, соответствуют почтовым требованиям Internet. На практике все адреса в полях From:, To:, Cc: и т. п. должны быть преобразованы (при необходимости) в соответствии с требованиями синтаксиса RFC 822.

  • Алгоритму трансляции, используемый для преобразования почты Internet в другие почтовые системы, рекомендуется пытаться обеспечить гарантии доставки сообщений об ошибках из чужой среды по пути возврата из конверта SMTP, а не отправителю, указанному в поле From: сообщения RFC 822.

    • Обсуждение
    • Списки рассылок Internet обычно помещают адрес владельца списка (list maintainer) в конверт, но указывают реального отправителя в поле From:. Этот подход представляется разумным — ответ на письмо приходит его реальному отправителю, а сообщения об ошибках — администратору списка, который может исправить связанные со списком ошибки.
  • Подобно сказанному, при пересылке почты из чужой среды в Internet шлюзу рекомендуется установить в конверте путь возврата в соответствии с требованиями возврата сообщений об ошибках для инородной среды.

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