5. Преобразование адресов и обработка почты
5.1. Обнаружение целевого хоста
После того, как клиент SMTP лексически идентифицирует домен, для которого предназначена передаваемая на обработку почта (см. параграфы 2.3.5 и 3.6), должно выполняться обращение к серверу доменных имен (DNS lookup) для преобразования доменного имени (RFC 1035 [2]). Предполагается, что в адресах используются полные имена (FQDN) — механизм определения FQDN по частичному имени или локальному псевдониму выходит за пределы данной спецификации. В силу сложившейся практики, серверам SMTP, используемым для начального представления сообщений, не следует выполнять преобразований неполных имен (серверы представления сообщений [18] имеют более мощные механизмы таких преобразований), а для транслирующих серверов SMTP такие преобразования недопустимы.
При поиске сначала предпринимается попытка найти локальную запись MX, связанную с именем. Если взамен этого будет найдена запись CNAME, полученное в результате имя обрабатывается как исходное. Если сервер имен сообщает об отсутствии искомого домена, должно генерироваться сообщение об ошибке. При возврате сообщения о временной ошибке письмо должно помещаться в очередь для последующего повтора попытки передачи (см. параграф 4.5.4.1). Если возвращается пустой список записей MX, адрес трактуется, как связанный с неявной записью MX RR, имеющей уровень предпочтения 0 и указывающей на данный хост. Если записи MX присутствуют, но ни одна из них не может быть использована, или неявная запись MX не может быть использована, должно генерироваться сообщение об ошибке.
Если для данного имени найдена одна или несколько записей MX, для системы SMTP недопустимо использовать какие-либо адресные записи, связанные с этим именем, пока они не найдены с использованием записей MX; приведенное выше правило неявных записей MX применимо только в случаях отсутствия реальных MX. Если записи MX присутствуют, но ни одна из них не может быть использована, должно генерироваться сообщение об ошибке.
Когда найдено доменное имя, связанное с MX RR, и полученое соответствующее поле данных, этот отклик должен включать доменное имя. При запросе по этому имени должна возвращаться по крайней мере одна адресная запись (например, A или AAAA), которая дает IP-адрес сервера SMTP для отправки тому сообщения.
Все прочие отклики, включая значения, возвращающие при запросе запись CNAME, выходят за пределы рассмотрения данного стандарта. Запрет меток, которые преобразуются в записи CNAME более подробно рассматривается в параграфе 10.3 RFC 2181 [38].
После успешного поиска доменного имени в DNS преобразование может дать не один адрес, а несколько, в результате наличия множества записей MX и/или поддержки хостом нескольких адресов (multihoming). Для обеспечения надежной доставки почты клиент SMTP должен быть способен пытаться (включая повторы) использовать все адреса в соответствии с их порядком в списке, пока доставка не завершится успехом. Однако может существовать конфигурационное ограничение числа используемых альтернативных адресов. В таких случаях клиенту SMTP следует предпринимать попытки по крайней мере для двух адресов.
Для ранжирования адресов хостов используется два типа данных — множественные записи MX и многодомные хосты.
Записи MX содержат информацию о предпочтениях, которая должна использоваться при сортировке списка, если число записей превышает 1 (см. ниже). Меньшие значения MX указывают на более предпочтительные адреса доставки. При наличии нескольких адресов с одинаковыми значениями MX нет явных причин для предпочтения того или иного адреса и отправитель SMTP должен выбирать порядок таких адресов случайным образом для распределения нагрузки между разными почтовыми серверами одной организации.
Хост получателя (возможно с предпочтительной записью MX) может оказаться многодомным — в таких случаях доменное имя будет преобразовываться в список адресов IP. Ответственность за упорядочивание этого списка лежит на интерфейсе преобразователя имен (domain name resolver), который должен упорядочивать список в порядке снижения предпочтений, а отправитель SMTP должен пытаться использовать адреса в предложенном порядке.
Хотя поддержка попыток доставки с использованием множества адресов требуется от реализации, возможность таких попыток для конкретной инсталляции может быть ограничена или отключена совсем. Вопрос о целесообразности использования разных адресов многодомных хостов остается спорным. Основным аргументом в пользу таких попыток является повышение вероятности своевременной доставки сообщений, а в некоторых случаях — просто обеспечение возможности доставки. Противники такого подхода считают, что он ведет к излишнему расходу ресурсов. Отметим, что использование ресурсов сильно зависит от выбранной стратегии передачи, как было показано в параграфе 4.5.4.1.
Если сервер SMTP принимает сообщение, для адресата которого данный сервер означен в записи MX, этот сервер может транслировать сообщение (потенциально, после получения переписанных адресов для MAIL FROM и/или RCPT TO), обеспечивая его окончательную доставку, или передать его дальше, используя тот или иной механизм, не относящийся к транспортной среде SMTP. Естественно, для второго случая сначала должен быть проверен список записей MX.
Если сервер определяет, что ему следует транслировать сообщение без переписывания заголовков, он должен отсортировать записи MX для определения нужной. Высший приоритет для передачи сообщения будет иметь запись с минимальным значением MX. Хост-транслятор должен проверить список на предмет наличия в нем имен или адресов, известных для данной транзакции. Если найдена соответствующая запись, все остальные записи, для которых уровень предпочтения не выше найденного, должны исключаться из рассмотрения. Если таких записей нет, это говорит об ошибке и сервер должен вернуть сообщение, как недоставляемое. С оставшимися в списке записями следует повторять попытки доставки сообщения в порядке снижения приоритета записи.