La question dans son ensemble touche à quelques aspects différents qui doivent tous être pris en considération pour savoir pourquoi la RFC7505 ajoute quelque chose d'utile.
Tout d'abord, la définition antérieure à la RFC7505 de la manière dont la remise du courrier doit être effectuée n'a aucun moyen d'indiquer clairement qu'aucune tentative de remise du courrier ne doit être effectuée pour un nom qui possède des enregistrements d'adresse.
De RFC7505 section 1 :
Les clients SMTP ont une séquence prescrite pour identifier un serveur qui accepte les e-mails pour un domaine. La section 5 de [RFC5321] couvre cela en détail; en substance, le client SMTP recherche d'abord un DNS MX RR et, s'il n'est pas trouvé, il revient à rechercher un DNS A ou AAAA RR. Par conséquent, cela surcharge un enregistrement DNS (qui a une mission principale différente) avec une sémantique de service de messagerie.
Si un domaine n'a pas d'enregistrements MX, les expéditeurs tenteront de remettre du courrier aux hôtes aux adresses dans les enregistrements A ou AAAA du domaine. S'il n'y a pas d'écouteurs SMTP aux adresses A / AAAA, la remise des messages sera tentée à plusieurs reprises pendant une longue période, généralement une semaine, avant que l'agent de transfert de courrier (MTA) expéditeur n'abandonne. Cela retardera la notification à l'expéditeur en cas de courrier mal acheminé et consommera des ressources chez l'expéditeur.
Ce document définit un MX nul qui entraînera l'échec immédiat de toutes les tentatives de remise de courrier vers un domaine, sans que les domaines ne créent d'écouteurs SMTP dédiés à la prévention des tentatives de remise.
Ensuite, il y a la question de savoir comment le RFC7505 implémente cela ( IN MX 0 .).
De la RFC7505 section 3 :
Enregistrements de ressources MX spécifiant Null MX
Pour indiquer qu'un domaine n'accepte pas les e-mails, il annonce un seul MX RR (voir la section 3.3.9 de la [RFC1035]) avec une section RDATA composée du numéro de préférence 0 et d'une étiquette de longueur nulle, écrite dans les fichiers maîtres comme ". ", en tant que domaine d'échange, pour indiquer qu'il n'existe aucun échangeur de messagerie pour un domaine. Puisque "." n'est pas un nom d'hôte valide, un enregistrement MX nul ne peut pas être confondu avec un enregistrement MX ordinaire.
L'utilisation de "." en tant que pseudo-nom d'hôte signifiant qu'aucun service disponible n'est modélisé sur le SRV RR [ RFC2782 ] où il a une signification similaire.
Un domaine qui annonce un MX nul NE DOIT PAS annoncer un autre MX RR.
(pas d'italique dans l'original)
Comme indiqué ici, les détails de mise en œuvre pour le "MX nul" sont basés sur un modèle déjà établi du SRVtype RR. Il est logique d'imiter cela car le SRVtype RR est plus ou moins une version généralisée du MXtype RR.
Ainsi, la décision a été essentiellement prise déjà lors de la définition du SRVtype RR .
Alors pourquoi ne pas en profiter .invalid?
De la RFC2606 section2 :
".invalid" est destiné à être utilisé dans la construction en ligne de noms de domaine qui sont sûrs d'être invalides et dont il est évident en un coup d'œil qu'ils ne sont pas valides.
Comme on peut le voir ici, ce TLD réservé est destiné à la consommation humaine. Il n'y a pas de précédent pour définir une gestion spéciale de cela dans le logiciel.
Certes, il aurait pu être implémenté d'une manière différente, mais ils ont choisi d'adopter l'approche minimale d'utilisation ., qui n'est pas un nom d'hôte valide et n'interfère donc pas avec l'utilisation normale de toute façon.