Unter welchen Umständen (falls vorhanden) sollte ein MX-Datensatz auf localhost verweisen?

Ich denke, dass es absolut keinen Grund oder eine Rechtfertigung dafür gibt, aber bevor ich meinen Mund öffne und einen Administrator in tiefem Kimchi bekomme, dachte ich, ich sollte fragen.

Gibt es einen Umstand, unter dem ein MX-Datensatz auf eine Loopback-Adresse verweisen sollte? Für mich bedeutet dies, dass jeder Mailserver, der versucht, an diese Domain zu senden, stattdessen an sich selbst sendet und fehlschlägt, aber ich bin kein Mail-Guru, also fehlt mir vielleicht etwas.

Ich bin bei der Fehlerbehebung bei einer E-Mail auf das unten stehende Problem gestoßen. Problem für einen Kunden, und ich habe Probleme, meinen Kopf darum zu wickeln. Vielleicht überdenke ich die Dinge aber auch.

Kurze Antwort: Es sollte nicht.

Lange Antwort: Wenn die betreffende Domain (DIQ) keine E-Mail empfangen soll, versucht der sendende Server, eine Loopback-Adresse für den MX-Eintrag einzugeben, um eine Verbindung zu sich selbst herzustellen. Dies spart dem DIQ einige wenige Bytes und bereinigt möglicherweise die Firewall-Protokolle (falls jemand sie überhaupt beobachtet), wenn andere Mailserver versuchen, eine Verbindung herzustellen. Meiner Meinung nach reicht die Bandbreitenersparnis jedoch nicht aus, um einen Verstoß gegen RFC 3330 zu rechtfertigen.

Definitiv ein NEIN, nicht mit einer 127.0.0.0-IP. Der gesamte 127.0.0.0-Bereich unter IPv4 fungiert als Loopback-Adresse. Wenn also ein Computer eine Verbindung zu IPs in diesem Bereich herstellt, versucht er, eine Verbindung zu sich selbst herzustellen.

Die IP-Adresse Ihres MX-Datensatzes sollte von außen zugänglich sein. Das Ergebnis sagt jedem Server, der eine MX-Abfrage ausführt, dass er versuchen soll, eine Verbindung zu sich selbst herzustellen.

Wenn mein Server versucht hat, Ihnen eine E-Mail zu senden, sucht er den MX-Eintrag und verbindet dann seine eigene IP-Adresse, sendet die E-Mail und schlägt fehl.

Die relevanten RFCs sagen:

• Der MX-Ressourceneintrag MUSS auf einen vollständig qualifizierten Domänennamen (keine IP-Adresse) eines Servers im öffentlichen Internet verweisen, der E-Mails für die Domäne akzeptiert. Beachten Sie, dass sich dieser Server nicht unbedingt in derselben Domäne wie der MX-Datensatz befinden muss. RFC 1035 Abschnitt 3.3.9

• Adressen im Bereich 127.0.0.0/8 dürfen niemals im öffentlichen Internet erscheinen. RFC 5735 Abschnitt 3

Beachten Sie, dass einige Mailserver E-Mails von Absendern ablehnen, die nicht den relevanten RFCs entsprechen .

Wenn ein Host in der Lage sein muss, E-Mails über verschiedene gehostete Domänen an sich selbst zu senden, aber keine externen E-Mails akzeptiert, "MX 0 localhost". ist akzeptabel. Verwenden Sie "MX 0", um anzuzeigen, dass ein Host überhaupt keinen Mailserver hat.

Der "MX 0." wird in RFC7505 detailliert beschrieben .

Nun, ich habe eine Situation, in der es notwendig erscheint, den MX einer Domain auf localhost zu setzen.

Im März 2012 habe ich eine süße Domain registriert, die ich überrascht fand. Es war für eine künstlerische Kollaborationsseite, die meine Tochter einrichten wollte. Ich habe den MX auf einen meiner anderen SMTP-Server eingestellt. Dies funktionierte gut, aber dann bekam ich viele E-Mail-Bounces für "unbekannte Benutzer" an xxx@cute-domain.com (nicht den tatsächlichen Domainnamen). Daher habe ich MailScanner verwendet, um alle eingehenden Nachrichten an diese Domäne mit Ausnahme einer legitimen Adresse zu blockieren. Es scheint, dass die Domain ab 2001 ein kostenloser E-Mail-Dienst war, aber anscheinend dunkel geworden war und ihren niedlichen Domain-Namen aufgegeben hatte.

Dies funktionierte gut, bis der SMTP-Server vor einigen Tagen (20.11.12) anfing, eingehende Nachrichten aufgrund übermäßiger offener Verbindungen abzulehnen. Ich denke, dies waren SMTP-Prozesse, die auf den Empfang von Antworten warteten. Ich habe mir den Verkehr angesehen und wurde von Tausenden von eingehenden Nachrichten für xxx@cute-domain.com von ebenso vielen SMTP-Relays auf der ganzen Welt bombardiert. (17.000 Nachrichten in einem Zeitraum von 24 Stunden)

Also habe ich den MX so geändert, dass er auf einen anderen Server verweist, auf dem SMTP nicht ausgeführt wird und Port 25 blockiert ist. Sicher genug, es tauchten Tausende von unterbrochenen Sitzungen auf. Da dieses Verhalten wie eine Art Spam-Torrent aussieht, möglicherweise aus einem Botnetz, habe ich mir gedacht, dass das Setzen des MX auf localhost erforderlich sein könnte.

Ich werde es für eine Weile so lassen. Wir brauchen überhaupt keine E-Mail für cute.domain.com, daher geht nichts verloren, außer Zyklen für das Botnetz.

Warum nicht ein MX-Ziel verwenden, das sich in nichts auflösen lässt? Z.B:

example.com. IN MX 10 etwas. Ungültig.

Spammer sehen den Auflösungsfehler und kümmern sich nicht um den nächsten MX-Datensatz, da sie glauben, das Ziel sei falsch konfiguriert. Echte Server versuchen den nächsten Datensatz. Dies wird den geschlossenen TCP-Port 25 von niemandem stören - dh keinen SMTP-Verkehr, nur DNS.