Экспериментальный чекер MG (Mail Group)
Запись MG (Mail Group) была невероятно амбициозной, ранней инженерной попыткой встроить функционал списков рассылки (mailing list) непосредственно в структуру Domain Name System. До появления менеджеров списков рассылки прикладного уровня (application-layer) сетевые инженеры предполагали, что могут использовать записи DNS для диктовки логики распределения групп по магистрали Интернета. Эта концепция была описана в RFC 1035 как экспериментальный механизм для обработки дублирования массовой рассылки (bulk email) на этапе маршрутизации сервер-сервер.
Дублирование Payload на уровне DNS
Механика записи MG полагалась на кластеризацию узлов DNS. Администратор создавал псевдодоменный узел, такой как dev-team.example.com. Затем он прикреплял к этому единственному узлу несколько записей MG, каждая из которых явно указывала на отдельные записи MB (Mailbox) членов команды. Когда внешний почтовый сервер пытался отправить электронное письмо на этот групповой адрес, он опрашивал DNS о записях MG. Авторитетный сервер имен возвращал полный массив (array) участников. Предполагалось, что отправляющий сервер затем продублирует Payload письма и инициирует отдельные SMTP-соединения для доставки сообщения на каждый отдельный почтовый ящик, указанный в ответе DNS.
Отказ кэширования и распространения
Протокол MG с треском провалился в реальных развертываниях из-за неотъемлемой природы кэширования DNS. DNS сильно зависит от значений Time-To-Live (TTL), когда промежуточные интернет-провайдеры кэшируют записи от 24 до 48 часов для снижения нагрузки на сеть. Если пользователь хотел отписаться от списка рассылки, сисадмину приходилось удалять его запись MG из файла зоны. Однако, поскольку внешние серверы кэшировали старый список группы, пользователь продолжал бы получать массовые письма в течение нескольких дней, пока не истечет глобальный TTL. Управление динамическими подписками пользователей с помощью статического редактирования зоны DNS было вычислительно неэффективным и крайне раздражающим для пользователей.
Развитие списков Application-Layer
Сетевые архитекторы единогласно пришли к выводу, что для списков рассылки требуется сложное управление состояниями (state management) — обработка отказов (bounces), обработка ссылок отписки (unsubscribe) и управление очередями модерации — для чего DNS никогда не был предназначен. Запись MG была полностью заброшена. Отрасль перешла к менеджерам списков на уровне приложений, таким как GNU Mailman, Majordomo и современным Distribution Groups в Exchange. Эти приложения располагаются за стандартной записью MX, получают один Payload письма и используют внутренние базы данных SQL для мгновенного управления дублированием и распределением, полностью отделяя логику списков рассылки от глобальных таблиц маршрутизации DNS.