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


9

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 -----
<myusername@GHS.L.GOOGLE.COM>... 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 myusername@ghs.l.google.complace de myusername@mydomain.com. 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é.

Réponses:


12

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" .


Merci pour cette réponse exhaustive! :) Donc, pour résumer, vous diriez que la raison pour laquelle cela a fonctionné pour certains mais pas pour d'autres expéditeurs, est qu'ils utilisent différents MTA qui suivent le CNAME malgré les enregistrements MX qui, selon la RFC 1034 2.6.2, peuvent être considéré comme un comportement défectueux?
0sh

Je ne suis pas sûr d'appeler le comportement "défectueux". La configuration d'un CNAME avec d'autres enregistrements (MX, NS, etc.) est quelque chose qui a été cassé / non recommandé, et différents hôtes l'ont interprété de différentes manières.
jeff

Est-ce un «généralement oui» mais vous n'êtes pas sûr d'appeler le comportement défectueux, ou ai-je complètement raté le point?
0sh

Les détails sont un gâchis, donc 'généralement oui' :-)
jeff

Un MTA doit interroger le domaine après l' @adresse e-mail pour les enregistrements MX et rien d'autre. S'il en obtient, il doit immédiatement tenter la livraison vers l'un des enregistrements MX les plus bas. Si tous les serveurs MX ne parviennent pas à se connecter ou qu'aucun enregistrement MX n'est trouvé, il doit essayer de se connecter au domaine lui-même. Le MTA en question va évidemment trop loin dans la résolution des informations ou ne suit pas les règles pour déterminer à quel serveur de messagerie se connecter. Il ne devrait y avoir rien de mal à ce que votre domaine pointe vers un CNAME - mais vous avez besoin des enregistrements MX pour que le courrier électronique fonctionne.
Eli Sand

1

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.


Tout d'abord, j'ai mentionné que l' @enregistrement était de type CNAME. Deuxièmement, le DNS que j'utilise est celui fourni par Google lors de l'achat, donc je n'ai même pas accès au fichier de zone. J'ai utilisé les paramètres par défaut fournis par Google. Enfin et surtout, les «très peu d'informations fournies» étaient apparemment suffisantes pour qu'une personne compétente puisse fournir une réponse utile, satisfaisante et (contrairement à la vôtre) cordiale.
0sh

Vous ne comprenez clairement pas DNS et le downvote était complètement injustifié. Vous avez également modifié votre question après avoir publié ma réponse en ajoutant des informations supplémentaires. Vous ne mentionnez pas non plus une fois que vous n'avez pas accès à votre fichier de zone bien que vous ayez clairement indiqué que vous les avez modifiés.
Eli Sand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.