5.2.6. Трансляция почты: RFC 821, 3.6
Различают три типа пересылки почты (возможно, с промежуточным сохранением):
Проста программа пересылки (mail exchanger) рассылает сообщения с использованием частной (private) информации о получателях (см. RFC 821, 3.2).
Транслятор SMTP (mail relay) пересылает сообщения в среде SMTP с использованием явно заданного отправителем маршрута (explicit source route), как определено в параграфе 3.6 RFC 821. Функции SMTP relay используют форму "@...:" для задания маршрута в соответствии с RFC 822 (см. 5.2.19 ниже).
Почтовый шлюз (mail gateway) передает сообщения между различными средами. Правила работы почтовых шлюзов рассмотрены в параграфе 5.3.7.
Хостам Internet, пересылающим почту, но не являющимся шлюзами в другие почтовые среды (т. е., относящимся к типу (1) или (2)) не рекомендуется менять пол заголовков в сообщениях, хотя можно добавлять строку Received: в соответствии с требованиями параграфа 5.2.8.
Отправителям SMTP не рекомендуется передавать команду RCPT TO:, содержащую явный маршрут, с использованием адреса в формате "@...:". Таким образом, функции трансляции почты, определенные в параграфе 3.6 RFC 821, не рекомендуется использовать.
- Обсуждение
- Задача состоит в полном искоренении source routing and упразднении явного задания маршрутов для доставки почты в среде Internet. Задание маршрута не требуется и во всех случаях следует использовать простую форму адреса получателя — [email protected] Это является результатом принятия решения на уровне архитектуры почтовой среды об использовании универсального именования вместо явного задания маршрутов доставки почты. Таким образом, SMTP обеспечивает сквозную доставку (end-to-end connectivity), а DNS — уникальные в масштабе планеты и не зависящие от местоположения имена. Для обработки случаев, когда может потребоваться задание маршрута используются записи MX.
Получатель SMTP должен воспринимать синтаксис явного задания маршрута в конверте, но он может реализовать функции трансляции (relay) в соответствии с параграфом 3.6 RFC 821. Если функция трансляции не реализована, получателю рекомендуется попробовать доставить сообщение напрямую хосту, указанному в адресе справа от знака @.
- Обсуждение
Предположим для примера, что хост, не поддерживающий трансляции, получает сообщение с командой SMTP "RCPT TO:<@ALPHA,@BETA:[email protected] >"(ALPHA, BETA и GAMMA представляют доменные имена). Вместо отказа с возвратом ошибки 550 (как предлагается на стр.20 в RFC 821), хосту следует попытаться переслать сообщение напрямую в GAMMA с помощью команды RCPT TO:<[email protected] >». Поскольку этот хост не поддерживает трансляции, ему не требуется обновлять путь возврата.
Некоторые считают, что задание маршрута может иногда потребоваться при отправке почты вручную при наличии сбоев; однако, реальность и важность такого использования весьма сомнительны. Использование явной трансляции SMTP для решения таких задач не представляется разумным и, фактически, не обеспечивает успеха, поскольку многие хосту не поддерживают явного задания маршрутов. В некоторых случаях для решения таких задач используется "%-hack" (см. параграф 5.2.16).