Einige Absender empfangen aufgrund der DNS-Konfiguration keine E-Mails

9

Ich habe ein merkwürdiges Verhalten meiner Google Apps-Domain festgestellt. Die meisten E-Mails kommen wie erwartet durch, aber im Laufe der Zeit bin ich zu dem Schluss gekommen, dass E-Mails von bestimmten Absendern nicht eingehen. Nachdem ich einen solchen Absender identifiziert habe, dessen E-Mails nicht eingehen würden, habe ich ihn gebeten, mir eine E-Mail zu senden und die Antwort "Zustellungsfehler" an mein reguläres Google Mail-Konto weiterzuleiten.

Die Antwort auf einen Zustellungsfehler enthielt das folgende Snippet:

----- Protokoll der Sitzung folgt -----
<[email protected]>... Zurückgestellt: Zeitüberschreitung der Verbindung mit ghs.l.google.com.

Dies hat mir geholfen, das Problem durch eine schnelle Suche zu identifizieren, die mich zu dieser Seite im Google Apps-Hilfeforum führte. In der Tat habe ich den DNS- @Eintrag für meine Domain überprüft und war auf ghs.google.com eingestellt. (CNAME), was es nicht sein sollte. Durch Ändern von @ 74.125.93.121 (A)* wurde das Problem behoben.

Ich verstehe , dass in den Fällen , in denen die E - Mail nicht durchkommen würde, mein Domain - Name durch die kanonischen Namen durch einen CNAME - Lookup ersetzt wurde, so dass die E - Mail gesendet wurde [email protected]statt [email protected]. Aber warum hat es bei der überwiegenden Mehrheit der Absender funktioniert? Haben die Absender, deren E-Mails nicht eingehen würden, ein anderes E-Mail-Protokoll, seltsame DNS-Einstellungen verwendet oder was könnte es sein?

Nach dem, was ich bei der Untersuchung des Problems auf Google sehen konnte, scheint dies ein weit verbreitetes Problem zu sein (viele Leute, die sich über E-Mails von Battle.net beschweren, die nicht eingehen, wären ein beliebtes Beispiel), nur dass die Leute nicht scheinen um sich bewusst zu sein, dass das Problem in den eigenen DNS-Einstellungen liegt und nicht auf der Seite der Absender.

Wie kann das erklärt werden?

* Ich habe diese IP aufgrund dessen verwendet, was ich hier gelesen habe , aber ich denke, jede IP würde den Trick machen. Kann jemand das bestätigen? Beachten Sie, dass @das Problem durch einfaches Entfernen des Datensatzes nicht behoben, sondern geändert werden musste.

0sh
quelle

Antworten:

12

Aus RFC 2821 "Simple Mail Transfer Protocol", Abschnitt 5 "Adressauflösung und E-Mail-Bearbeitung":

Die Suche versucht zunächst, einen dem Namen zugeordneten MX-Datensatz zu finden. Wenn stattdessen ein CNAME-Datensatz gefunden wird, wird der resultierende Name so verarbeitet, als wäre er der ursprüngliche Name.

Im Allgemeinen funktionieren CNAMEs so. Sie werden oft missbraucht, falsch verstanden und falsch implementiert. :-)

Wenn Ihre Domain example.com ist, verfügen Sie wahrscheinlich über vorhandene MX-Einträge, die auf die üblichen Google Apps-Hosts verweisen.

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.

Es hört sich so an, als hättest du auch einen Eintrag wie diesen:

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

RFC 1034 "Domänenkonzepte und -einrichtungen" in Abschnitt 3.6.2 "Aliase und kanonische Namen" empfiehlt gegen diese Konfiguration:

Wenn an einem Knoten ein CNAME RR vorhanden ist, sollten keine anderen Daten vorhanden sein. Dies stellt sicher, dass die Daten für einen kanonischen Namen und seine Aliase nicht unterschiedlich sein können.

Im Falle des von Ihnen eingefügten Fehlers haben der Mailserver und / oder der DNS-Server auf der sendenden Seite versucht, MX-Einträge für Ihre Domain example.com zu suchen, und einen CNAME gefunden, der auf ghs.l.google verweist. com. Anschließend wurde versucht, die MX-Einträge für ghs.l.google.com nachzuschlagen. Diese Domain verfügt derzeit über keine MX-Einträge, sodass der Mailserver auf den A-Eintrag für ghs.l.google.com durchgefallen wäre. Diese IP-Adresse hat den SMTP-Port nicht überwacht. Das Ergebnis ist der Fehler "Zeitüberschreitung der Verbindung mit ghs.l.google.com".

Durch Entfernen des CNAME-Datensatzes haben Sie Ihre E-Mail-Probleme behoben. Möglicherweise treten Probleme auf, wenn die IP-Adresse, die Sie an ihrer Stelle definiert haben, von Google geändert wird.

Sie können stattdessen den c-Namen für www.example.com definieren:

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

Führen Sie einen kleinen Webserver auf der IP-Adresse aus, auf die Sie example.com verweisen, und führen Sie einfach eine HTTP-Umleitung zu http://www.example.com/ durch.

Es ist etwas überraschend, dass es so gut funktioniert hat wie es funktioniert hat. Ich glaube, das Postel-Gesetz wird dort anerkannt. :-)

Zurück zu RFC 1034 2.6.2:

CNAME-RRs verursachen spezielle Aktionen in der DNS-Software. Wenn ein Nameserver keine gewünschte RR in dem dem Domänennamen zugeordneten Ressourcensatz findet, prüft er, ob der Ressourcensatz aus einem CNAME-Datensatz mit einer übereinstimmenden Klasse besteht. In diesem Fall nimmt der Nameserver den CNAME-Datensatz in die Antwort auf und startet die Abfrage unter dem im Datenfeld des CNAME-Datensatzes angegebenen Domänennamen neu. Die einzige Ausnahme von dieser Regel besteht darin, dass Abfragen, die dem CNAME-Typ entsprechen, nicht neu gestartet werden.

In diesem Fall könnte also argumentiert werden, dass der DNS-Server dem CNAME bei einer MX-Suche nicht folgen würde / sollte, es sei denn, es wurden keine MX-Einträge gefunden.

Beim Senden von E-Mails versuchen Sendmail und qmail (und wahrscheinlich auch andere) standardmäßig, alle auf der rechten Seite einer E-Mail-Adresse verwendeten CNAME in den kanonischen Namen umzuschreiben.

In der Tat haben sich einige Websites auf dieses Verhalten verlassen. djb geht in seinem Dokument "CNAME-Datensätze in E-Mails" ausführlich darauf ein, warum er der Meinung ist, dass die Leute sich nicht mehr darauf verlassen sollten .

Jeff
quelle
Vielen Dank für diese ausführliche Antwort! :) Zusammenfassend lässt sich sagen, dass der Grund, warum es für einige, aber nicht für andere Absender funktioniert hat, darin besteht, dass sie unterschiedliche MTAs verwenden, die dem CNAME folgen, obwohl MX-Datensätze vorhanden sind, was laut RFC 1034 2.6.2 möglich ist als fehlerhaftes Verhalten angesehen?
0sh
Ich bin mir nicht sicher, ob ich das Verhalten "fehlerhaft" nennen würde. Die Konfiguration eines CNAME mit anderen Datensätzen (MX, NS usw.) wurde beschädigt / nicht empfohlen, und verschiedene Hosts haben sie unterschiedlich interpretiert.
Jeff
Ist das ein "allgemein ja", aber Sie sind nicht sicher, ob Sie das Verhalten als fehlerhaft bezeichnen würden, oder habe ich den Punkt völlig verfehlt?
0sh
Die
Jeff
Ein MTA sollte die Domain nach der @in der E-Mail-Adresse angegebenen Adresse für MX-Einträge abfragen und sonst nichts. Wenn dies der Fall ist, sollte sofort versucht werden, einen der niedrigsten MX-Datensätze zu übermitteln. Wenn alle MX-Server keine Verbindung herstellen können oder keine MX-Einträge gefunden werden, sollte versucht werden, eine Verbindung zur Domäne selbst herzustellen. Der betreffende MTA geht beim Auflösen von Informationen offensichtlich zu weit oder befolgt nicht die Regeln zum Bestimmen, mit welchem ​​Mailserver eine Verbindung hergestellt werden soll. Es sollte nichts Falsches daran sein, dass Ihre Domain auf einen CNAME verweist - aber Sie benötigen die MX-Einträge, damit E-Mails funktionieren.
Eli Sand
1

Das @Symbol in einem BIND-Datensatz ist nur eine Kurzform zum Schreiben der Domain. Wenn Sie einen Datensatz für erstellen example.com, @ist dies nur ein Alias ​​für example.com. Zu sagen, dass der @Datensatz eine IP sein musste, ist eine Aussage, der wichtige Informationen fehlen - Sie haben uns nicht gesagt, um welche Art von Datensatz es sich handelt.

Aus dem Übermittlungsbericht geht hervor, dass Sie möglicherweise etwas mit Ihrem DNS getan haben, um den Remote-Mailserver zu veranlassen, Ihre Domain in ghs.l.google.com umzuschreiben - sehr seltsam (PS, ein A-Eintrag muss eine IP sein, ein CNAME-Eintrag darf keine IP oder ein anderer CNAME-Eintrag sein).

Warum der Mailserver dieser Person Ihre Adresse neu schreibt, ist seltsam - es sollte nicht geschehen, es sei denn, diese Person hat etwas getan, um sie explizit anzuweisen, sie neu zu schreiben. Es sollte sich auch überhaupt nicht darum kümmern, wie die IP-Adresse Ihrer Domain lautet, es sei denn, es wurden keine MX-Einträge gefunden, da MX-Einträge die Art und Weise sind, wie Mailserver herausfinden, wohin E-Mails gehen.

Angesichts der wenigen Informationen klingt es für mich so, als hätten Sie die Google-Anweisungen zur ordnungsgemäßen Konfiguration Ihres DNS für E-Mails überhaupt nicht befolgt. Sie haben wahrscheinlich sogar einige Fehler in Ihrer Zonendatei - lassen Sie sie von einem kompetenten Zonenadministrator überprüfen.

Eli Sand
quelle
Zuerst habe ich erwähnt, dass der @Datensatz vom Typ CNAME ist. Zweitens ist das DNS, das ich verwende, das von Google beim Kauf bereitgestellte, daher habe ich nicht einmal Zugriff auf die Zonendatei. Ich habe die von Google bereitgestellten Standardeinstellungen verwendet. Und zu guter Letzt reichten die "sehr wenigen bereitgestellten Informationen" anscheinend für jemanden, der kompetent war, um eine hilfreiche, zufriedenstellende und (im Gegensatz zu Ihrer eigenen) herzliche Antwort zu geben.
0sh
Sie verstehen DNS eindeutig nicht und die Ablehnung war völlig ungerechtfertigt. Sie haben Ihre Frage auch bearbeitet, nachdem ich meine Antwort mit zusätzlichen Informationen veröffentlicht habe. Sie erwähnen auch nie einmal, dass Sie keinen Zugriff auf Ihre Zonendatei haben, obwohl Sie deutlich erwähnt haben, dass Sie sie geändert haben.
Eli Sand