MX-запись

Запись почтового обменника ( запись MX ) определяет почтовый сервер, ответственный за прием сообщений электронной почты от имени доменного имени. Это запись ресурса в системе доменных имен (DNS). Можно настроить несколько записей MX, обычно указывающих на массив почтовых серверов для балансировки нагрузки и резервирования.

Обзор

См. также: MXlo

Записи ресурсов являются основным информационным элементом системы доменных имен (DNS). Запись MX является одной из них, и в домене может быть настроено одно или несколько из них, как показано ниже:

Domain			TTL   Class    Type  Priority      Host
example.com.	1936	IN		MX		10         onemail.example.com.
example.com.	1936	IN		MX		10         twomail.example.com.

Характеристическая полезная информация записи MX. — это значение предпочтения (выше помечено как «Приоритет») и доменное имя почтового сервера («Хост» выше).

Поле приоритета определяет, какой почтовый сервер следует предпочесть — в этом случае оба значения равны 10, поэтому ожидается, что почта будет поступать равномерно как на onemail.example.com , так и на twomail.example.com — общая конфигурация. Имя хоста должно напрямую сопоставляться с одной или несколькими адресными записями (A или AAAA) в DNS и не должно указывать ни на какие записи CNAME .

Когда сообщение электронной почты отправляется через Интернет, отправляющий агент передачи почты (MTA) запрашивает в системе доменных имен записи MX доменного имени каждого получателя . Этот запрос возвращает список имен хостов серверов обмена почтой, принимающих входящую почту для этого домена, и их настройки. Затем агент-отправитель пытается установить SMTP-соединение, сначала пробуя хост с наименьшим значением «Приоритета». Система позволяет высокодоступные кластеры почтовых шлюзов. при необходимости построить для одного домена

Механизм MX не предоставляет возможности предоставлять почтовые услуги на альтернативных номерах портов , а также не предоставляет возможности распределять доставку почты по набору почтовых серверов с неравным приоритетом путем присвоения каждому из них весового значения.

Предпочтение MX, расстояние и приоритет

Согласно RFC 5321, записи с наименьшим номером являются наиболее предпочтительными. Эта формулировка может сбивать с толку, поэтому число предпочтений иногда называют расстоянием : меньшие расстояния более предпочтительны. В более старом RFC, RFC 974, указано, что если номера предпочтений одинаковы для двух серверов, они имеют одинаковый приоритет , поэтому эти два термина используются как взаимозаменяемые.

Номер предпочтения является беззнаковым 16-битный поле, поэтому допустимые значения варьируются от 0 до 65535.

Основы

В простейшем случае в домене может быть только один почтовый сервер. Например, если MTA ищет записи MX для example.com, а DNS-сервер ответил только mail.example.com с номером предпочтения 50, тогда MTA попытается доставить почту на указанный сервер. В этом случае число 50 могло быть любым целым числом, разрешенным спецификацией SMTP.

Если для запроса MX возвращается более одного сервера, сначала необходимо опробовать сервер с наименьшим номером предпочтения. Если существует более одной записи MX с одинаковым номером предпочтения, необходимо опробовать их все, прежде чем переходить к записям с более низким приоритетом. Клиент SMTP должен иметь возможность попробовать (и повторить) каждый из соответствующих адресов в списке по порядку, пока попытка доставки не будет успешной.

Распределение нагрузки

Стандартный подход к распределению нагрузки входящей почты по массиву серверов заключается в возврате одного и того же номера предпочтения для каждого сервера в наборе. При определении того, на какой сервер с одинаковым предпочтением отправлять почту, «SMTP-отправитель ДОЛЖЕН рандомизировать их, чтобы распределить нагрузку между несколькими почтовыми обменниками для конкретной организации», если только нет явной причины отдать предпочтение одному из них.

Альтернативный подход — использовать многосетевые серверы, где один хост возвращает несколько IP-адресов. Этот метод возлагает нагрузку на DNS, а не на SMTP-отправителя для выполнения балансировки нагрузки, которая в этом случае будет предоставлять список IP-адресов в определенном порядке клиентам, запрашивающим запись A почтового обменника. Поскольку RFC требует, чтобы SMTP-отправитель использовал порядок, указанный в запросе записи A, DNS-сервер может осторожно манипулировать своей балансировкой на основе любого метода, включая циклический DNS , загрузку почтового сервера или какую-либо нераскрытую схему приоритетов.

«Резервный» MX

Некоторые домены будут иметь несколько записей MX, одна из которых предназначена как «резервная» — с более высоким номером предпочтения, чтобы она обычно не выбиралась в качестве цели для доставки электронной почты.

Однако в случае ошибок на хостах с меньшим номером (возможно, из-за какого-либо сбоя) отправка почтовых серверов будет доставляться на «резервный» хост — Queue.example.com в приведенном ниже примере:

Domain          TTL   Class    Type  Priority   Host
example.com.    1936    IN      MX   10         onemail.example.com.
example.com.    1936    IN      MX   10         twomail.example.com.
example.com.    1936    IN      MX   100        queue.example.com.

Если резервный сервер имеет прямой доступ к почтовым ящикам пользователей, почта будет отправляться туда, но в противном случае она, скорее всего, будет поставлена ​​в очередь на Queue.example.com до тех пор, пока сбой не будет устранен.

В отсутствие такого рода договоренности, когда все почтовые серверы домена находятся в автономном режиме, отправляющие серверы должны ставить в очередь сообщения, предназначенные для этого домена, чтобы повторить попытку позже. Однако эти отправляющие серверы не имеют возможности получать уведомления о том, что серверы ранее отключенного домена теперь доступны, и поэтому прибегают к расписанию опроса - и обнаруживают, что домен доступен, только при следующей попытке доставки. Таким образом, задержка между подключением серверов принимающего домена к сети и моментом окончательной доставки отложенных сообщений может составлять от нескольких минут до нескольких дней, в зависимости от графика повторных попыток отправляющих серверов - и принимающий домен не имеет возможности видеть или контролировать это.

Спамеры

Спамеры могут намеренно сначала направлять почту на один из резервных (больших расстояний) MX-серверов домена, предполагая, что такой сервер будет иметь менее эффективные антиспам-фильтры. метод защиты от спама, называемый «нолистингом» На таком предположении основан .

Обработка сбоя доставки

SMTP RFC неясно, какие именно ошибки доставки должны привести к повторной попытке доставки через более удаленные записи MX (с более высокими значениями предпочтений).

Когда серверы указывают на временные сбои, либо явно отправляя ошибку 4xx, либо неожиданно завершая соединение (что должно рассматриваться как ошибка 451, согласно разделу 3.8 RFC), в разделе 4.5.4.1 говорится:

Отправитель ДОЛЖЕН отложить повторную попытку определенного пункта назначения после того, как одна попытка оказалась неудачной.

Однако когда отправитель повторяет попытку, RFC ничего не говорит о том, должна ли это быть запись на тот же сервер или более «отдаленная» запись MX. сказано В разделе 5.1 :

Если поиск успешен, сопоставление может привести к появлению списка альтернативных адресов доставки, а не одного адреса, из-за нескольких записей MX, множественной адресации или того и другого. Чтобы обеспечить надежную передачу почты, клиент SMTP ДОЛЖЕН иметь возможность проверять (и повторять) каждый из соответствующих адресов в этом списке по порядку, пока попытка доставки не будет успешной.

Некоторые серверы (например, Sendmail и Postfix 2.1 или новее), будет пытаться подключиться к следующему по дальности MX-серверу после некоторых типов временных сбоев доставки, таких как сбои приветствия. Другие серверы (например, qmail и Postfix 2.0 или более ранние версии) будут использовать более удаленные записи MX только в том случае, если с серверами, указанными в записях MX на кратчайшем расстоянии, вообще невозможно связаться. Несмотря на разницу, оба варианта поведения допустимы, поскольку RFC не является конкретным.

Возврат к записи адреса

При отсутствии записи MX отправители электронной почты попытаются доставить письмо на адресную запись, например example.com.

Это основано на RFC 5321 sec. 5.1, в котором говорится:

• Клиенты SMTP должны найти запись MX;
• Если ( и только если ) для домена нет записи MX, рассматривайте домен так, как если бы у него была запись MX с данным доменом в качестве целевого имени хоста и значением предпочтения 0.
• Выполните поиск A или AAAA, необходимый для определения IP-адреса целевого имени хоста.

Историческая справка

RFC 821 был опубликован в 1982 году. В нем содержатся только проходящие ссылки на DNS, поскольку на тот момент переход от HOSTS.TXT к DNS еще не начался. RFC 883, первое описание DNS, был опубликован год спустя, в конце 1983 года. В нем описывались экспериментальные и малоиспользуемые записи MD и MF. Согласно RFC 897 и RFC 921, переход на DNS начался в 1983 году, но прекращение использования HOSTS.TXT планировалось только в конце 1985 года и не было полностью прекращено до конца 1990-х годов.

В январе 1986 года RFC 973 и RFC 974 объявили устаревшими записи MD и MF, заменили их на MX и определили поиск MX с возвратом к A. RFC 974 рекомендует клиентам выполнять WKS. поиск на каждом хосте MX, чтобы проверить, действительно ли он поддерживает SMTP, и в противном случае отбросить запись MX. Однако RFC 1123 изменил это, указав, что WKS не следует проверять.

Это означает, что SMTP использовался как минимум год с использованием HOSTS.TXT, а затем еще пару лет с использованием A, MD и MF, прежде чем появился MX. MD и MF было сложно использовать, поэтому большинство людей просто использовали пластинку A. В таких обстоятельствах MX без возврата к A не работал бы из-за значительной установленной базы почтовых серверов, использующих записи A. Первоначально MX использовался для идентификации шлюзов к другим сетям, но он не получил широкого распространения до тех пор, пока в начале 1990-х годов не был широко распространен DNS.

Стандартные документы

• RFC 1035 (1987), Доменные имена. Реализация и спецификация.
• RFC 1912 (1996), Распространенные ошибки работы и конфигурации DNS.
• RFC 5321 (2008), Простой протокол передачи почты
• RFC 7505 (2015), «Нулевая запись ресурса службы MX» для доменов, которые не принимают почту.

Устаревший:

• RFC 974 (1986), Маршрутизация почты и доменная система (устарел RFC-5321)
• RFC 2821 (2001), Простой протокол передачи почты (устарел благодаря RFC-5321 )

См. также

• СРВ-запись
• Структура политики отправителей
• Список типов записей DNS
• Рекорд
• Нолистинг