Ne pas recevoir de mails de certains expéditeurs en raison d'une configuration DNS

J'ai remarqué un comportement particulier de mon domaine Google Apps. La plupart des courriers transitent comme vous vous en doutez, mais sur une période de temps, je suis arrivé à la conclusion que les courriers de certains expéditeurs ne transitent pas. Après avoir identifié un de ces expéditeurs, dont les e-mails ne passeraient pas, je lui ai demandé d'essayer de m'envoyer un e-mail et de transmettre la réponse "échec de livraison" à mon gmail habituel.

La réponse d'échec de livraison contenait l'extrait de code suivant:

----- La transcription de la session suit -----
<[email protected]>... Différée: la connexion a expiré avec ghs.l.google.com.

Cela m'a aidé à identifier le problème en effectuant une recherche rapide qui m'a conduit à cette page sur le forum d'aide de Google Apps. En effet, j'ai vérifié l'enregistrement DNS de mon domaine et j'ai @été défini sur ghs.google.com. (CNAME), ce qui ne devrait pas être le cas. Changer cela en @ 74.125.93.121 (A)* a résolu le problème.

Je comprends que dans les cas où le courrier ne passerait pas, mon nom de domaine a été remplacé par son nom canonique via une recherche CNAME, donc le courrier a été envoyé à la [email protected]place de [email protected]. Mais pourquoi cela a-t-il fonctionné pour la grande majorité des expéditeurs? Les expéditeurs dont le courrier ne transitait pas ont-ils utilisé un type de protocole de messagerie différent, des paramètres DNS étranges ou quoi?

D'après ce que j'ai pu voir en recherchant le problème sur Google, cela semble être un problème très répandu (beaucoup de gens se plaignent que les e-mails de battle.net ne passent pas, serait un exemple populaire), seulement que les gens ne semblent pas pour être conscient que le problème réside dans leurs propres paramètres DNS, plutôt que du côté des expéditeurs.

Comment expliquer cela?

^{* J'ai utilisé cette IP à cause de ce que j'ai lu ici , mais je pense que n'importe quelle IP ferait l'affaire. Quelqu'un peut-il confirmer cela? Notez que la simple suppression de l' @enregistrement n'a pas résolu le problème, il a dû être modifié.}

De RFC 2821 "Simple Mail Transfer Protocol", section 5 "Résolution d'adresse et traitement du courrier":

La recherche tente d'abord de localiser un enregistrement MX associé au nom. Si un enregistrement CNAME est trouvé à la place, le nom résultant est traité comme s'il s'agissait du nom initial.

En général, c'est ainsi que fonctionnent les CNAME. Ils sont souvent mal utilisés, mal compris et mal mis en œuvre. :-)

Si votre domaine est example.com, vous disposez probablement d'enregistrements MX existants pointant vers les hôtes Google Apps habituels.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Il semble que vous ayez également eu une entrée comme celle-ci:

example.com. CNAME ghs.l.google.com.

La RFC 1034 "Concepts et installations de domaine" indique dans la section 3.6.2 "Alias ​​et noms canoniques" déconseille cette configuration:

Si un CNAME RR est présent sur un nœud, aucune autre donnée ne doit être présente; cela garantit que les données d'un nom canonique et de ses alias ne peuvent pas être différentes.

Dans le cas de l'erreur que vous avez collée, le serveur de messagerie et / ou le serveur DNS côté expéditeur ont tenté de rechercher des enregistrements MX pour votre domaine, example.com, et ont trouvé un CNAME pointant vers ghs.l.google. com. Il a ensuite tenté de rechercher les enregistrements MX pour ghs.l.google.com. Ce domaine ne possède actuellement aucun enregistrement MX, de sorte que le serveur de messagerie serait passé à l'enregistrement A pour ghs.l.google.com. Cette adresse IP n'écoutait pas sur le port SMTP, le résultat est donc l'erreur "La connexion a expiré avec ghs.l.google.com".

En supprimant l'enregistrement CNAME, vous avez résolu vos problèmes de messagerie. Vous pourriez rencontrer des problèmes si l'adresse IP que vous avez définie à sa place est modifiée du côté de Google.

Vous pouvez à la place définir le cname pour www.example.com:

www.example.com. CNAME ghs.l.google.com.

Et exécutez un petit serveur Web sur l'adresse IP vers laquelle vous pointez example.com, qui effectue simplement une redirection HTTP vers http://www.example.com/

Il est quelque peu surprenant que cela ait aussi bien fonctionné. Je crois que la loi de Postel y trouve son compte. :-)

Retour à RFC 1034 2.6.2:

Les RR CNAME provoquent une action spéciale dans le logiciel DNS. Lorsqu'un serveur de noms ne parvient pas à trouver un RR souhaité dans l'ensemble de ressources associé au nom de domaine, il vérifie si l'ensemble de ressources se compose d'un enregistrement CNAME avec une classe correspondante. Si tel est le cas, le serveur de noms inclut l'enregistrement CNAME dans la réponse et redémarre la requête au nom de domaine spécifié dans le champ de données de l'enregistrement CNAME. La seule exception à cette règle est que les requêtes qui correspondent au type CNAME ne sont pas redémarrées.

Donc, dans ce cas, on pourrait faire valoir que le serveur DNS ne suivrait / ne devrait pas suivre le CNAME lors d'une recherche MX, sauf si aucun enregistrement MX n'a ​​été trouvé.

Lors de l'envoi de courrier, Sendmail et qmail (et probablement d'autres) tenteront par défaut de réécrire tout CNAME utilisé dans le côté droit d'une adresse e-mail avec le nom canonique.

En effet, certains sites se sont appuyés sur ce comportement. djb explique en détail pourquoi il pense que les gens devraient cesser de s’y fier dans son document "CNAME records in mail" .

Le @symbole dans un enregistrement BIND n'est qu'un raccourci pour écrire le domaine. Si vous créez un enregistrement pour example.com, il ne @s'agit que d'un alias pour example.com. Dire que l' @enregistrement devait être une adresse IP est une déclaration qui manque d'informations critiques - vous ne nous avez pas dit de quel type d'enregistrement il s'agissait.

D'après le rapport de livraison, il semble que vous ayez peut-être fait quelque chose avec votre DNS pour que le serveur de messagerie distant réécrive votre domaine sur ghs.l.google.com - très étrange (PS, un enregistrement A doit être une adresse IP, un enregistrement CNAME ne doit pas être une adresse IP ou un autre enregistrement CNAME).

La raison pour laquelle le serveur de messagerie de cette personne réécrit votre adresse est étrange - cela ne devrait pas l'être à moins que cette personne n'ait fait quelque chose pour lui demander explicitement de la réécrire. Il ne devrait pas non plus se soucier du tout de l'IP de votre domaine, à moins qu'il ne trouve aucun enregistrement MX, car les enregistrements MX sont la façon dont les serveurs de messagerie déterminent où va le courrier.

Il me semble que, compte tenu du peu d'informations fournies, vous n'avez pas du tout suivi les instructions de Google sur la façon de configurer correctement votre DNS pour la messagerie. Vous avez probablement même des erreurs dans votre fichier de zone - faites-les vérifier par un administrateur de zone compétent.