Mon blog

Comment indiquer qu'un domaine ne reçoit jamais de courrier ? Jusqu'à présent, il n'existait pas de mécanisme standard, permettant d'indiquer aux clients de ne pas perdre de temps à essayer d'écrire. Ce nouveau RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l'enregistrement MX.

Normalement, un logiciel de messagerie qui veut envoyer du courrier à bob@example.net va chercher dans le DNS l'enregistrement MX du domaine example.net. (Le processus exact est décrit dans le RFC 5321, section 5.1.) A priori, si on ne veut pas recevoir de courrier, il suffit de ne pas mettre d'enregistrement MX, non ? Malheureusement, ce n'est pas le cas : le RFC 5321 précise que, s'il n'y aucun MX, on essaie alors les adresses IP associées au nom (règle dite du « MX implicite »).

Or, il existe des domaines qui ne reçoivent pas de courrier, parce qu'ils sont seulement réservés sans intention d'être utilisés, ou bien parce qu'ils ne servent que pour le Web ou bien encore pour toute autre raison. Si un message tente de parvenir à ces domaines, la machine émettrice va perdre du temps à essayer des MX délibérement invalides (avant la norme de notre RFC 7505, des gens mettaient un MX pointant vers localhost) ou bien des adresses où aucun serveur SMTP n'écoute. Ce n'est pas joli. Et cela peut prendre du temps (lorsque la délivrance échoue, l'émetteur met en attente et réessaie) donc l'utilisateur qui s'est trompé de domaine ne sera prévenu que plusieurs jours plus tard, lorsque le serveur émetteur renoncera enfin.

Au contraire, avec le nouveau « MX nul », dit officiellement No Service MX, le rejet sera immédiat et l'utilisateur, notifié tout de suite, pourra corriger son erreur.

La syntaxe exacte du MX nul figure en section 3. On utilise l'enregistrement MX (RFC 1035, section 3.3.9), avec une partie droite comprenant une préférence égale à zéro et un nom de domaine (exchange, dans la terminologie du RFC 1035) vide (de longueur nulle), ce qui se note, en représentation texte, par un simple point. Voici un exemple :

% dig +short MX  internautique.fr 
0 .

Ce nom ne pouvait pas être un nom de machine légal, il n'y a pas de risque de confusion avec les MX actuels. (Les enregistrements SRV du RFC 2782 utilisent le même truc pour dire qu'il n'y a pas de service disponible à ce nom : « A Target of "." means that the service is decidedly not available at this domain. ».)

La section 4 liste les effets de l'utilisation du MX nul. Comme indiqué plus haut, il permet une réponse immédiate à l'utilisateur, lorsque celui-ci s'est trompé d'adresse (bob@example.net alors qu'il voulait écrire à bob@example.com). L'erreur SMTP à utiliser dans ce cas est 556 (Server does not accept mail, RFC 7504) avec comme code amélioré (codes définis dans le RFC 3643) le nouveau 5.1.10 Domain has null MX.

Le MX nul sert aussi si, par erreur ou par usurpation, un serveur tente d'envoyer du courrier avec une adresse d'émission qui est un domaine à MX nul : le récepteur peut rejeter tout de suite ce message, pour la raison qu'il ne pourrait de toute façon pas lui répondre (ou pas lui envoyer de DSN). C'est ainsi que procèdent beaucoup de serveurs de messagerie avec les adresse d'émission dont le domaine n'existe pas. Dans ce cas, les codes d'erreurs à utiliser sont 550 (mailbox unavailable) avec le code étendu 5.7.27 (Sender address has null MX). (Les nouveaux codes sont dans le registre IANA.) Par exemple, Postfix signale, pour le domaine example.com, une erreur 5.1.0 et le message « <foobar@example.com>: Domain example.com does not accept mail (nullMX) ».

Notez enfin que ce RFC concerne le cas où on ne reçoit pas de courrier. Si on veut dire qu'on n'en envoie pas, le plus simple est un enregistrement SPF -all.

Tous les hébergeurs DNS ne permettent pas encore de mettre un MX nul. Par exemple, l'un d'eux m'envoie promener « La valeur et/ou la priorité MX est incorrecte ».