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

Приложение E. Другие вопросы, связанные со шлюзами

В общем случае, шлюзам между Internet и другими почтовыми системами следует пытаться сохранить семантику при передаче сообщения через границу между двумя почтовыми системами. Шлюзы, которые пытаются сделать «вырезки» путем отображения (например, передача информации из конверта одной среды в заголовок или тело сообщения в другой среде), в общем случае не могут обеспечить требуемого уровня передачи информации. Системы, транслирующие между средами, которые не могут поддерживать одновременно конверты и заголовки почты Internet, должны понимать, что в таких случаях потеря некоторой информации практически неизбежна.

Приложение F. Отмененные возможности RFC 821

Некоторые возможности RFC 821 признаны проблематичными и их не следует использовать в почте Internet

F.1. Команда TURN

Эта команда, описанная в RFC 821, затрагивает важные аспекты безопасности, поскольку в отсутствие жесткой аутентификации для хостов, запрашивающих смену ролей клиента и сервера, такую команду можно с легкостью использовать для переадресации почты. Использование этой команды осуждается и системам SMTP не следует применять ее без аутентификации клиента сервером.

F.2. Задаваемая отправителем маршрутизация

RFC 821 использует концепцию явного задания маршрута отправителем для доставки почты с одного хоста на другой через промежуточные трансляторы. Необходимость использования такой маршрутизации в обычной почте отпала после появления в DNS записей MX. Существенный вклад в отказ от такой маршрутизации внес документ RFC 1123, в соответствии с которым после символа @ в адресе должно указываться полное доменное имя (FQDN). Следовательно, единственной причиной поддержки source route является интероперабельность со старыми клиентами SMTP или агентами MUA, а также отладка почтовых систем. Однако такая маршрутизация может быть полезна при возникновении серьезных проблем временного характера (типа релевантности записей DNS).

Серверы SMTP должны продолжать восприятие синтаксиса source route в соответствии с данной спецификацией и RFC 1123. При необходимости серверы могут игнорировать явные маршруты, используя из адреса только доменное имя. При использовании source route сообщение должно пересылаться в первый указанный в адресе домен. В частности, для серверов недопустимо сокращение маршрута source route.

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

F.3. Команда HELO

Как было указано в параграфах 3.1 и 4.1.1, следует отдавать предпочттение команде EHLO, нежели устаревшей команде HELO. Серверы должны принимать и обрабатывать команды HELO для поддержки старых клиентов.

F.4. #-литералы

В RFC 821 указана возможность задания адресов Internet с помощью десятичного представления номера хоста с префиксом #. На практике с появлением TCP/IP актуальность такого представления была утрачена. В настоящее время этот вариант осуждается и недопустим для использования.

F.5. Даты и годы

При включении клиентами и серверами SMTP значений даты в сообщения (например, в поля трассировки) должно использоваться 4-значное представление года. Двухзначное представление осуждается, а трехзначное никогда не допускалось в почтовых системах Internet.

F.6. Дополнительные команды прямой передачи

В дополнение к спецификации механизма доставки сообщений в почтовые ящики пользователей, RFC 821 обеспечивает добавочные команды для прямой доставки сообщений на консоль пользователя. Эти команды (SEND, SAML, SOML) использовались в реализациях достаточно редко, а изменения в технологии рабочих станций и появление других протоколов могут привести к полному забвению этих команд даже при их поддержке в программах.

Клиентам не следует предоставлять услуги SEND, SAML или SOML, но серверы их могут реализовать. При реализации этих служб сервером должна использоваться модель, приведенная в спецификации RFC 821, а имена команд должны публиковаться в отклике на команду EHLO.

Адрес автора

John C. Klensin
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140 USA
EMail: moc.kcj@ptms+nhoj

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