Кратко

  • MX превратил домен в адресе из команды подключиться к одноимённой машине в устойчивый идентификатор. DNS мог назвать другого получателя или несколько получателей, не меняя адреса пользователей.
  • Общее правило осталось тонким: отправитель запрашивает MX, начинает с меньших чисел preference, считает равные значения равноправными и отсекает путь обратно к себе. MX целевого обменника не образует скрытую цепочку ответственности.
  • Управление авторитетной зоной даёт практическую власть перенаправить будущую почту, но не суверенитет над идентичностью. Кеши растягивают переход, разные имена могут иметь общий отказ, а MX не обеспечивает ни аутентификацию, ни конфиденциальность.

Когда адрес ещё совпадал с машиной

RFC 974 начинался с привычного случая: письмо для ящика на LOKI.BBN.COM обычно можно было передать по SMTP машине LOKI.BBN.COM. Публичное имя назначения и реализующий его хост казались одним объектом.

Исключения существовали давно. Некоторые узлы UUCP и CSNET не имели прямого подключения к Интернету, поэтому отправители хранили особые правила; почту CSNET, например, направляли на CSNET-RELAY.ARPA. SMTP из RFC 821 уже знал ретрансляцию, шлюзы и исходные маршруты. MX не изобрёл промежуточную доставку.

Плохо масштабировалось другое: исключения жили в конфигурации каждого отправителя. Владелец назначения не мог заменить машину и одновременно исправить удалённые таблицы. Если домен должен был стать долговечным адресом, требовался отдельный публичный ответ на вопрос, кто принимает его почту сейчас.

Два типа уступают одной упорядоченной записи

Ранний DNS в RFC 882 и RFC 883 использовал типизированные ресурсные записи. Для почты существовали MD — mail destination — и MF — mail forwarder. Они различали прямой приём и пересылку, но плохо описывали несколько альтернатив.

RFC 973 заменил оба типа на MX. Запись соединила беззнаковое 16-битное значение preference с именем почтового обменника. Меньшее число пробуется раньше; одинаковые числа означают одинаковый приоритет.

Это было не просто упрощение таблицы типов. MD и MF назначали хостам роли. MX публиковал упорядоченный набор возможных получателей: прямой узел, relay и резерв могли описываться одним механизмом. RFC 1035 сохранил эту компактную форму.

Запись не содержит полного маршрута, показателя нагрузки или договора об услуге. Общий слой сообщает ровно столько, сколько нужно независимым отправителям для действия.

Имя остаётся, реализация переезжает

RFC 974 сформулировал разрыв прямо: доменное имя обычно является хостом, но не всегда. Почтовая программа не могла просто соединиться с именем из адреса; ей следовало спросить DNS. Ответ мог указать совсем другую машину или набор машин.

Организация получила возможность сохранять пользовательские адреса, меняя оборудование, площадку, фильтрующий шлюз или провайдера. Отправителю не нужна история внутренней миграции — только актуальный MX и адреса его целей.

Это не превращает DNS в источник метафизической истины. Тот, кто контролирует авторитетную зону, способен перенаправить входящую почту. Но механизм разделил два срока жизни: знакомое корреспондентам имя и сегодняшнюю техническую систему, которая его обслуживает.

Опубликованный порядок исполняется локально

RFC 974 настоятельно рекомендовал запрашивать MX при каждой попытке доставки. Если основной приёмник ломался, администратор назначения менял DNS, и сообщения в удалённых очередях узнавали новый путь при следующей попытке — с поправкой на кеш.

Список толковал сам отправитель. Он начинал с наименьшего preference и переходил к большим значениям, пока обменник не принимал письмо или пригодные варианты не кончались. Если минимум делили несколько целей, следовало испробовать их все до окончательной ошибки.

RFC 5321 сохранил основу и уточнил поведение. Клиент должен уметь пробовать и повторно пробовать относящиеся к делу адреса. Если между целями с равным preference нет иного основания для выбора, порядок рандомизируется, чтобы DNS-порядок не стал постоянным фаворитом.

Preference — не задержка, расстояние, загрузка и не институциональный ранг. Десять стоит перед двадцатью потому, что домен опубликовал такой административный порядок. Резерв с номером 20 может быть ближе и быстрее, но всё равно идёт позже.

Центрального диспетчера почты здесь нет. DNS публикует малый набор вариантов; тысячи самостоятельно управляемых MTA выполняют поиск, ведут очереди, назначают повторы и решают, когда временный сбой станет возвратом.

Собственная позиция разрывает петлю

Альтернативы создают риск зацикливания. Поэтому RFC 974 требовал найти локальный хост в множестве MX. Если он там присутствовал, удалялись его запись и все записи с таким же или большим числом. Передавать письмо разрешалось только обменнику, предпочтительному относительно себя, то есть с меньшим номером.

Резерв с preference 20 может снова обратиться к основному на 10. Он не должен передавать на 20 или 30, откуда ответственность способна уйти вбок и вернуться. Порядок задаёт не только отказоустойчивость, но и допустимое направление передачи ответственности.

RFC 974 закрыл и менее очевидную лазейку. MX запрашивается для исходного назначения. Отправитель не запрашивает MX имени, полученного в ответе, чтобы построить ещё одну цепочку relay. Если некоторый узел является MX для обменника, это не делает его автоматически ответственным за все домены обменника.

Ответственность нетранзитивна. Согласие принимать почту для конкретного имени должно быть выражено непосредственно; оно не наследуется по произвольной DNS-связи.

Кеш делает изменение доступным, но не мгновенным

DNS смог расти благодаря кешированию. Следовательно, изменённый набор MX не появляется у всех отправителей одновременно. RFC 974 признавал, что устаревшие записи временно создают петли или ложные отказы до истечения кеша.

Теоретически каждый mailer мог бы всякий раз спрашивать авторитетный сервер и отвергать кеш. RFC счёл это непрактичным: без кеширования стоимость почты стала бы чрезмерной. Вместо этого администраторам предписывалось координировать добавление обменника, а усечённый ответ по датаграмме повторять через надёжное виртуальное соединение.

Кеш — не случайная бюрократия между политикой и реальностью, а часть механизма масштабирования. Оператор управляет TTL и планом перехода, но не всемирным синхронным рубильником. Старую и новую службу приходится держать параллельно, пока распределённое знание сходится.

Когда отсутствие записи всё равно означало попытку

Проект 1986 года включал правило совместимости. Если MX отсутствовал, mailer вёл себя так, словно домен имел неявный MX с preference 0, указывающий на самого себя. RFC 5321 сохраняет implicit MX: затем отправитель разрешает A или AAAA домена и пытается открыть SMTP.

Это помогало старым доменам войти в новую систему, но сделало отсутствие двусмысленным. Оно могло означать работающую старую конфигурацию, ошибку или домен, который вообще не предоставляет почту. Молчание нельзя было прочесть как отказ от услуги; отправители ставили письма в очередь и стучались в адреса, предназначенные, например, только для веба.

RFC 5321 проводит границу вокруг явных данных. Если MX опубликованы, но ни один непригоден, требуется ошибка: игнорировать список и откатываться к адресу домена нельзя. Цель MX должна разрешаться в адресные записи; использование CNAME в этой позиции не входит в современный стандарт.

Точка, означающая отсутствие почты

В 2015 году RFC 7505 добавил null MX. Домен, не принимающий почту, публикует ровно одну запись с preference 0 и корневой меткой DNS — точкой . — в поле exchange. Других MX быть не должно.

Точка — не сломанный сервер, а явное заявление, что обменника нет. Отправитель может немедленно вернуть ошибку вместо отката к A или AAAA, постановки в очередь и повторов в течение срока, который RFC описывал как обычно недельный. Это экономит ресурсы и быстрее даёт человеку исправимый результат.

Null MX появился через двадцать девять лет после RFC 974, поэтому его нельзя приписывать первоначальному проекту. Он важен именно как поздняя поправка: совместимость сделала неучастие неотличимым от недостающей настройки, а новая запись вернула явное состояние «услуги нет».

У него есть пределы. Домен, используемый в обратном адресе писем, не должен небрежно объявлять null MX: получатели могут отвергать сообщения, для которых невозможно вернуть уведомление. Это также не пустой обратный путь SMTP и не оправдание поддельной идентичности.

Полезное косвенное соответствие без невиновности

MX позволил адресу оставаться прежним при полной замене приёмного стека. Тем самым он сделал DNS чувствительной поверхностью управления: изменение авторитетной зоны направляет будущую корреспонденцию новому оператору.

Несколько имён MX не гарантируют независимости. Они могут делить провайдера, сеть, площадку, административную учётную запись или фильтры. Резерв принимает почту во время аварии, но получает доступ к метаданным или содержимому. DNSSEC защищает целостность опубликованной записи, а не юридическую личность получателя и не внутреннее поведение обменника.

Успешный SMTP-сеанс также не доказывает помещение письма в конечный ящик, прочтение пользователем или сохранение конфиденциальности. Он отмечает переход ответственности только на одной протокольной границе.

Правомерное утверждение MX уже суверенитета, но надёжнее: запись говорит, куда домен сейчас просит передавать ответственность за почту, в каком порядке и когда услуги нет. Этого достаточно для координации независимых систем, но недостаточно для определения истины.

Самая маленькая полезная карта почты

MX связал три разных времени жизни. Адрес мог быть долговечным, инфраструктура доставки — сменной, а знание о маршруте — истекающим по TTL в кешах. Их разделение разрешило миграцию без участия каждого корреспондента.

Общий слой остался компактным: домен назначения, имена обменников, preference, TTL и несколько правил для петель и совместимости. Дисциплина очередей, транспортная защита, внутреннее размещение ящиков и коммерческие отношения остались у операторов.

Поэтому адрес пережил сервер не потому, что DNS нашёл ему вечный дом, а потому, что дом стал явным и заменяемым соответствием.

Источники и пределы выводов

Контекст раннего SMTP и доменных адресов дают RFC 821, RFC 882 и RFC 883. Переход от MD и MF к MX зафиксирован в RFC 973, а алгоритм января 1986 года, петли, кеш и нетранзитивная ответственность описаны в RFC 974.

Формат записи сохраняет RFC 1035, требования и поправки к хостам содержит RFC 1123. Зрелая SMTP-логика, implicit MX и равный preference берутся из RFC 5321, явное состояние отсутствия услуги — из RFC 7505.

Документы относятся к разным эпохам протокола. Поздние правила показывают развитие и исправление, а не приписываются программам 1986 года. Операционные следствия за пределами нормативного текста обозначены как ограниченные выводы, а не как измерение всех развёртываний.