Зачем нужен RFC 7505 (Null MX)?

Потому что это не то, что вы должны использовать .invalid для. подобно .example он предназначен для локального тестирования и документации.

Кроме того, используя .invalid по-прежнему вызывает дополнительные вещи - дополнительные поиски DNS и очереди на почтовом сервере для повторных попыток для одного, о котором я думаю.

Используя "." формат должен вызвать немедленный отказ. Вынудить MTA немедленно прекратить попытки доставки. По крайней мере, так читается введение к RFC.

Вопрос в целом затрагивает несколько различных аспектов, которые необходимо принять во внимание, чтобы ответить, почему RFC7505 добавляет что-то полезное.

Прежде всего, определение того, как должна осуществляться доставка почты до RFC7505, не дает четкого указания, что попытки доставки почты не должны предприниматься для имени, имеющего записи адреса.

Из RFC7505 раздел 1:

У клиентов SMTP есть предписанная последовательность для идентификации сервера, который принимает электронную почту для домена. В разделе 5 [RFC5321] это подробно рассматривается; по сути, клиент SMTP сначала ищет запись DNS MX RR, и, если она не найдена, возвращается к поиску записи DNS A или AAAA. Следовательно, это перегружает запись DNS (которая имеет другое основное предназначение) семантикой почтового сервиса.

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

В этом документе определяется пустой MX, который приведет к немедленному сбою всех попыток доставки почты в домен, не требуя от доменов создавать SMTP-прослушиватели, предназначенные для предотвращения попыток доставки.

Тогда есть вопрос, как RFC7505 реализует это (IN MX 0 .).

Из RFC7505 раздел 3:

3. Записи ресурсов MX, указывающие пустой MX

   Чтобы указать, что домен не принимает электронную почту, он объявляет одну запись MX RR (см. Раздел 3.3.9 [RFC1035]) с разделом RDATA, состоящим из номера предпочтения 0 и метки нулевой длины, записанной в основных файлах как ". "в качестве домена обмена, чтобы обозначить, что для домена не существует почтового обменника. Поскольку "." не является допустимым именем хоста, пустую запись MX нельзя спутать с обычной записью MX. Использование "." как псевдо-имя хоста, означающее, что на SRV RR не моделируется доступная услуга [RFC2782], где он имеет аналогичное значение.

   Домен, который объявляет нулевой MX, НЕ ДОЛЖЕН рекламировать любую другую MX RR.

(курсив мой)

Как здесь отмечено, детали реализации "нулевого MX" основаны на уже установленном шаблоне из SRV Тип RR. Имеет смысл имитировать это как SRV Тип RR в большей или меньшей степени является обобщенной версией MX Тип RR.

Итак, решение по сути было принято уже при определении SRV Тип RR.

Итак, почему бы не использовать .invalid?

Из RFC2606 раздел2:

".invalid" предназначен для использования в онлайн-построении доменных имен, которые наверняка недействительны и которые, как очевидно с первого взгляда, являются недействительными.

Как видно здесь, этот зарезервированный TLD предназначен для потребления людьми. Нет прецедента определения специального обращения с этим в программном обеспечении.

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