Питання в цілому стосується кількох різних аспектів, які потрібно врахувати, щоб відповісти, чому RFC7505 додає щось корисне.
Перш за все, визначення RFC7505 про те, як слід здійснювати доставку пошти, не може чітко вказати, що не потрібно робити спроб доставки пошти для імені, яке має записи адреси.
З розділу 1 RFC7505 :
Клієнти SMTP мають встановлену послідовність для ідентифікації сервера, який приймає електронну пошту для домену. Розділ 5 [RFC5321] детально висвітлює це питання; по суті, клієнт SMTP спочатку шукає DNS MX RR, і якщо цього не знайти, він повертається до пошуку DNS A або AAAA RR. Отже, це перевантажує запис DNS (який має іншу основну місію) семантичною службою електронної пошти.
Якщо у домену немає MX-записів, відправники намагаються доставити пошту хостам за адресами в записах домену A або AAAA. Якщо на адресах A / AAAA немає слухачів SMTP, доставку повідомлень здійснюватимуться повторно протягом тривалого періоду, як правило, за тиждень, до того, як агент, що пересилає пошту (MTA), відмовиться. Це затримає повідомлення відправника у випадку неправильно спрямованої пошти та споживатиме ресурси у відправника.
Цей документ визначає нульову MX, яка призведе до негайних помилок усіх спроб доставки пошти домену, не вимагаючи від доменів створення SMTP-слухачів, призначених для запобігання спробам доставки.
Тоді є питання про те, як RFC7505 реалізує це ( IN MX 0 .).
З розділу 3 RFC7505 :
MX Resource Records із зазначенням Null MX
Щоб вказати, що домен не приймає електронну пошту, він рекламує єдиний MX RR (див. Розділ 3.3.9 [RFC1035]) з розділом RDATA, що складається з номера уподобань 0 та нульової мітки, записаних у головних файлах як ". "як обмінний домен, щоб позначати, що не існує обмінника пошти для домену. Оскільки "." не є дійсним іменем хоста, нульовий запис MX не можна змішувати зі звичайним записом MX.
Використання "." як псевдо-ім'я хоста, що означає, що жодна послуга недоступна, моделюється на SRV RR [ RFC2782 ], де він має подібне значення.
Домен, який рекламує нульовий MX, НЕ МОЖЕ рекламувати будь-який інший MX RR.
(наголос додано)
Як зазначається тут, деталі реалізації для "null MX" базуються на вже встановленому шаблоні SRVтипу RR. Це має сенс імітувати, оскільки SRVтип RR в більшій чи меншій мірі є узагальненою версією типу MXRR.
Отже, рішення по суті було прийнято вже при визначенні SRVтипу RR .
Отже, чому б не скористатися .invalid?
З розділу RFC2606 :
".invalid" призначений для використання в онлайн-побудові доменних імен, які, безумовно, є недійсними та які, очевидно, на перший погляд є недійсними.
Як видно тут, цей зарезервований TLD призначений для споживання людиною. Немає прецеденту визначення спеціального поводження з цим програмним забезпеченням.
Звичайно, це могло бути реалізовано по-різному, але вони вирішили йти з мінімальним підходом до використання ., що не є дійсним іменем хоста і, таким чином, не заважає нормальному використанню.