Приложение 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