Запись почтового обменника ( запись 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 queue.example.com. Если резервный сервер имеет прямой доступ к почтовым ящикам пользователей, почта будет поступать туда, но в противном случае, скорее всего, будет помещена в очередь на queue.example.com до тех пор, пока сбой не будет устранен.
При отсутствии такого рода соглашения, когда все почтовые серверы домена находятся в автономном режиме, отправляющие серверы должны ставить сообщения, предназначенные для этого домена, в очередь, чтобы повторить попытку позже. Однако эти отправляющие серверы не имеют возможности быть уведомленными о том, что серверы ранее отключенного домена теперь доступны, и поэтому прибегают к графику опроса - и узнают, что домен доступен, только когда они в следующий раз попытаются доставить. Задержка между тем, когда серверы принимающего домена подключаются к сети, и тем, когда задержанные сообщения наконец доставляются, может составлять от нескольких минут до нескольких дней, в зависимости от графика повторных попыток отправляющих серверов - и принимающий домен не имеет никакой видимости или контроля над этим.
Спамеры могут намеренно направлять почту сначала на один из резервных (на большом расстоянии) MX-серверов домена, предполагая, что такой сервер будет иметь менее эффективные антиспамовые фильтры. Антиспамовая техника, называемая nolisting, основана на предположении такого поведения.
В документе 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, раздел 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 RR, в которых перечислены доменные имена, не поддерживающие эту службу, следует отбрасывать. Этот шаг необязателен, но настоятельно рекомендуется.