Запись почтового обменника ( запись MX ) определяет почтовый сервер , ответственный за прием сообщений электронной почты от имени доменного имени. Это запись ресурса в системе доменных имен (DNS). Можно настроить несколько записей MX, обычно указывающих на массив почтовых серверов для балансировки нагрузки и резервирования.
Записи ресурсов являются основным информационным элементом системы доменных имен (DNS). Запись MX является одной из них, и в домене может быть настроено одно или несколько из них, как показано ниже:
Приоритет типа класса TTL домена example.com . 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com. Характеристической полезной информацией записи MX [1] является значение предпочтения (выше помечено как «Приоритет») и доменное имя почтового сервера («Хост» выше).
Поле приоритета определяет, какой почтовый сервер следует предпочесть — в этом случае оба значения равны 10, поэтому ожидается, что почта будет поступать равномерно как на onemail.example.com , так и на twomail.example.com — общая конфигурация. Имя хоста должно напрямую сопоставляться с одной или несколькими адресными записями (A или AAAA) в DNS и не должно указывать ни на какие записи CNAME . [2]
Когда сообщение электронной почты отправляется через Интернет, отправляющий агент передачи почты (MTA) запрашивает в системе доменных имен записи MX доменного имени каждого получателя . Этот запрос возвращает список имен хостов серверов обмена почтой, принимающих входящую почту для этого домена, и их настройки. Затем агент-отправитель пытается установить SMTP-соединение, сначала пробуя хост с наименьшим значением «Приоритета». Система позволяет при необходимости построить для одного домена высокодоступные кластеры почтовых шлюзов. [3]
Механизм MX не предоставляет возможности предоставлять почтовые услуги на альтернативных номерах портов , а также не предоставляет возможности распределять доставку почты по набору почтовых серверов с неравным приоритетом путем присвоения каждому из них весового значения.
Согласно RFC 5321, записи с наименьшим номером являются наиболее предпочтительными. [4] Эта формулировка может сбивать с толку, поэтому число предпочтений иногда называют расстоянием : меньшие расстояния более предпочтительны. В более старом RFC, RFC 974, указано, что если номера предпочтений одинаковы для двух серверов, они имеют одинаковый приоритет , поэтому эти два термина используются как взаимозаменяемые.
Номер предпочтения представляет собой беззнаковое [5] 16-битное [5] [6] поле, поэтому допустимые значения находятся в диапазоне от 0 до 65535.
В простейшем случае в домене может быть только один почтовый сервер. Например, если MTA ищет записи MX для example.com, а DNS-сервер ответил только mail.example.com с номером предпочтения 50, тогда MTA попытается доставить почту на указанный сервер. В этом случае число 50 могло быть любым целым числом, разрешенным спецификацией SMTP.
Если для запроса MX возвращается более одного сервера, сначала необходимо опробовать сервер с наименьшим номером предпочтения. Если существует более одной записи MX с одинаковым номером предпочтения, необходимо опробовать их все, прежде чем переходить к записям с более низким приоритетом. Клиент SMTP должен иметь возможность попробовать (и повторить) каждый из соответствующих адресов в списке по порядку, пока попытка доставки не будет успешной. [4]
Стандартный подход к распределению нагрузки входящей почты по массиву серверов заключается в возврате одного и того же номера предпочтения для каждого сервера в наборе. При определении того, на какой сервер с равным предпочтением отправлять почту, «SMTP-отправитель ДОЛЖЕН рандомизировать их, чтобы распределить нагрузку между несколькими почтовыми обменниками для конкретной организации», если только нет явной причины отдать предпочтение одному из них. [4]
Альтернативный подход — использовать многосетевые серверы, где один хост возвращает несколько IP-адресов. [3] Этот метод возлагает нагрузку на DNS, а не на SMTP-отправителя для выполнения балансировки нагрузки, которая в этом случае будет предоставлять список IP-адресов в определенном порядке клиентам, запрашивающим запись A почтового обменника. Поскольку RFC требует, чтобы SMTP-отправитель использовал порядок, указанный в запросе записи A, DNS-сервер может осторожно манипулировать своей балансировкой на основе любого метода, включая циклический DNS , загрузку почтового сервера или какую-либо нераскрытую схему приоритетов.
Некоторые домены будут иметь несколько записей MX, одна из которых предназначена как «резервная» — с более высоким номером предпочтения, чтобы она обычно не выбиралась в качестве цели для доставки электронной почты.
Однако в случае ошибок на хостах с меньшим номером (возможно, из-за какого-либо сбоя) отправляющая электронная почта будет доставлена на «резервный» хост — Queue.example.com в приведенном ниже примере:
Приоритет типа класса TTL домена example.com . 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com. example.com. 1936 IN MX 100 очередь.example.com. Если резервный сервер имеет прямой доступ к почтовым ящикам пользователей, почта будет отправляться туда, но в противном случае она, скорее всего, будет поставлена в очередь на Queue.example.com , пока сбой не будет устранен.
В отсутствие такого рода договоренности, когда все почтовые серверы домена находятся в автономном режиме, отправляющие серверы должны ставить в очередь сообщения, предназначенные для этого домена, чтобы повторить попытку позже. Однако эти отправляющие серверы не имеют возможности получать уведомления о том, что серверы ранее отключенного домена теперь доступны, и поэтому прибегают к расписанию опроса - и обнаруживают, что домен доступен, только при следующей попытке доставки. Таким образом, задержка между подключением серверов принимающего домена к сети и моментом окончательной доставки отложенных сообщений может составлять от нескольких минут до нескольких дней, в зависимости от расписания повторных попыток отправляющих серверов, и принимающий домен не имеет возможности видеть или контролировать это.
Спамеры могут намеренно сначала направлять почту на один из резервных (больших расстояний) MX-серверов домена, предполагая, что такой сервер будет иметь менее эффективные антиспам-фильтры. На таком предположении основан метод защиты от спама, называемый «нолистингом» .
В SMTP RFC [4] неясно, какие именно виды сбоев доставки должны привести к повторной попытке доставки через более удаленные записи MX (с более высокими значениями предпочтений).
Когда серверы указывают на временные сбои, либо явно отправляя ошибку 4xx, либо неожиданно завершая соединение (что должно рассматриваться как ошибка 451, согласно разделу 3.8 RFC), в разделе 4.5.4.1 говорится:
Отправитель ДОЛЖЕН отложить повторную попытку определенного пункта назначения после того, как одна попытка оказалась неудачной.
Однако когда отправитель повторяет попытку, RFC ничего не говорит о том, должна ли это быть ссылка на тот же сервер или на более «отдаленную» запись MX. В разделе 5.1 сказано:
Если поиск успешен, сопоставление может привести к появлению списка альтернативных адресов доставки, а не одного адреса, из-за нескольких записей MX, множественной адресации или того и другого. Чтобы обеспечить надежную передачу почты, клиент SMTP ДОЛЖЕН иметь возможность проверять (и повторять) каждый из соответствующих адресов в этом списке по порядку, пока попытка доставки не будет успешной.
Некоторые серверы (например, Sendmail и Postfix 2.1 или новее) [7] будут пытаться подключиться к следующему по дальности MX-серверу после некоторых типов временных сбоев доставки, таких как сбои приветствия. [8] Другие серверы (например, qmail и Postfix 2.0 или более ранние версии) будут использовать более удаленные записи MX только в том случае, если с серверами, указанными в записях MX на кратчайшем расстоянии, вообще невозможно связаться. Несмотря на разницу, оба варианта поведения допустимы, поскольку RFC не является конкретным.
При отсутствии записи MX отправители электронной почты попытаются доставить письмо на адресную запись, например example.com.
Это основано на RFC 5321 sec. 5.1, в котором говорится:
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 [ 9 ] на каждом хосте MX, чтобы проверить, он фактически поддерживает SMTP, а в противном случае отбрасывает запись MX. Однако RFC 1123 изменил это, указав, что WKS не следует проверять.
Это означает, что SMTP использовался как минимум год с использованием HOSTS.TXT, а затем еще пару лет с использованием A, MD и MF, прежде чем появился MX. MD и MF было сложно использовать, поэтому большинство людей просто использовали пластинку A. В таких обстоятельствах MX без возврата к A не работал бы из-за значительной установленной базы почтовых серверов, использующих записи A. Первоначально MX использовался для определения шлюзов к другим сетям, но он не получил широкого распространения до тех пор, пока DNS не получил должного признания в начале 1990-х годов. [10]
Устарело:
Для каждого MX необходимо выполнить запрос WKS, чтобы узнать, действительно ли указанное доменное имя поддерживает желаемую почтовую службу.
Записи MX, в которых перечислены доменные имена, не поддерживающие эту услугу, следует отбросить.
Этот шаг не является обязательным, но настоятельно рекомендуется.