550 Invalid RDNS entry -> RDNS ist aber iO
- Thread starter SPQRInc
- Start date
GwenDragon
Registered User
Dann teste deinen Server erst mal auf http://mxtoolbox.com/
Denn so geheime Server wie 212.212.212.212 sind uns unbekannt.
Denn so geheime Server wie 212.212.212.212 sind uns unbekannt.
D
Deleted member 11691
Guest
Hi,
ich kann dir nur das sagen, was GwenDragon auch bereits erwähnt hat: Ohne genauere Infos welche IP/Domain das ist, können wir nicht viel sagen. Crawling-Bots finden Domains und IPs so oder so irgendwann, da hilft dir das Zensieren hier im Forum sehr wenig.
ich kann dir nur das sagen, was GwenDragon auch bereits erwähnt hat: Ohne genauere Infos welche IP/Domain das ist, können wir nicht viel sagen. Crawling-Bots finden Domains und IPs so oder so irgendwann, da hilft dir das Zensieren hier im Forum sehr wenig.
GwenDragon
Registered User
Kann ja sein dass der Empfängerserver noch keine gültige NS-Daten von deinem Server bekam und deswegen rumzickt.
Das kann seltnen bis zu 24 Stunden dauern.
Wann hast du zu letzten Mal deine NS-Daten geändert?
Ansonsten ist es sinnlos rumzustochern im Nebel anhand nur eines Bouncemails.
So wie es jetzt ist, kann dir nur jemand bezahlt helfen, wenn du alles anonym willst.
Das kann seltnen bis zu 24 Stunden dauern.
Wann hast du zu letzten Mal deine NS-Daten geändert?
Ansonsten ist es sinnlos rumzustochern im Nebel anhand nur eines Bouncemails.
So wie es jetzt ist, kann dir nur jemand bezahlt helfen, wenn du alles anonym willst.
Joe User
Zentrum der Macht
"invalid" ist hier wohl ausschlaggebend und das prüft mxtoolbox nunmal nicht (ebenso sind die restlichen Test kaum brauchbar, keine Ahnung warum der Dienst so gehyped wird).
Wie ein PTR korrekt auszusehen hat, habe ich hier schon oft genug geschrieben und auch oft genug auf den entsprechenden RFC verwiesen, daher spare ich mir die erneute Wiederholung.
Wie ein PTR korrekt auszusehen hat, habe ich hier schon oft genug geschrieben und auch oft genug auf den entsprechenden RFC verwiesen, daher spare ich mir die erneute Wiederholung.
GwenDragon
Registered User
Man kann auch mit dig +trace diverse NS-Abrufe tätigen, um zu sehen wo es hakt.
nexus
Well-Known Member
Kannst du das bitte etwas genauer ausführen?
Nach meinem Verständnis macht der Webdienst doch letztlich dieselben Abfragen, wie ich sie auch mit diversen CLI-Tools tätigen kann und bereitet die Ergebnisse nur hübsch im GUI auf...
Joe User
Zentrum der Macht
Bleiben wir beim PTR:
mxtoolbox gibt sein OK zu einem PTR der auf die Domain lautet, dies ist definitiv RFC-widrig und somit falsch. Der PTR hat auf den Hostnamen zu lauten und auf absolut nichts Anderes.
Dagegen hat das SMTP-Banner auf den FQDN des Mailservers zu lauten und nicht auf den PTR. mxtoolbox interessiert dieser Fakt nicht, im Gegenteil, sie empfehlen SMTP-Banner=PTR.
Es gibt noch ein paar weitere kleine Fehler, die aber glücklicherweise nicht ganz so schlimm sind wie obige.
Wer seinen Mailserver mit den beiden obigen Fehlern konfiguriert nur um mxtoolbox und/oder vergleichbare Dienste zufriedenzustellen, der gehört zu Recht vom Mailverkehr ausgeschlossen. Die RFCs existieren nicht grundlos und glücklicherweise halten sich die gängigsten Mailserver (Postfix, Exim, Exchange) heutzutage OOTB an die RFCs (man muss sie also schon absichtlich kaputt konfigurieren, indem man auf mxtoolbox und Co oder diverse miserable Blogs/Foren/etc hört).
Leider werden auch hier im SSF allzu oft obige Falschkonfigurationen propagiert, obwohl die "Helfenden" es besser wissen sollten.
Disclaimer: Bin erst seit Mitte 1998 Postmaster, daher habe ich nur wenig Ahnung von der Materie, also nicht allzu ernst nehmen...
mxtoolbox gibt sein OK zu einem PTR der auf die Domain lautet, dies ist definitiv RFC-widrig und somit falsch. Der PTR hat auf den Hostnamen zu lauten und auf absolut nichts Anderes.
Dagegen hat das SMTP-Banner auf den FQDN des Mailservers zu lauten und nicht auf den PTR. mxtoolbox interessiert dieser Fakt nicht, im Gegenteil, sie empfehlen SMTP-Banner=PTR.
Es gibt noch ein paar weitere kleine Fehler, die aber glücklicherweise nicht ganz so schlimm sind wie obige.
Wer seinen Mailserver mit den beiden obigen Fehlern konfiguriert nur um mxtoolbox und/oder vergleichbare Dienste zufriedenzustellen, der gehört zu Recht vom Mailverkehr ausgeschlossen. Die RFCs existieren nicht grundlos und glücklicherweise halten sich die gängigsten Mailserver (Postfix, Exim, Exchange) heutzutage OOTB an die RFCs (man muss sie also schon absichtlich kaputt konfigurieren, indem man auf mxtoolbox und Co oder diverse miserable Blogs/Foren/etc hört).
Leider werden auch hier im SSF allzu oft obige Falschkonfigurationen propagiert, obwohl die "Helfenden" es besser wissen sollten.
Disclaimer: Bin erst seit Mitte 1998 Postmaster, daher habe ich nur wenig Ahnung von der Materie, also nicht allzu ernst nehmen...
nexus
Well-Known Member
Danke für die Erklärung.
Ich als CLI-Junkie nutze solche GUI's sowieso nur sehr selten. mxtoolbox kenne ich eigentlich auch nur vom Namen her, hab aber schon öfters gelesen, daß die Resultate nur bedingt richtig sind...daher auch die Rückfrage.
Der war gut...
ALso nicht auf zu altes Wissen zurückgreifen
Joe User
Zentrum der Macht
Auch mein erster Mailserver, der gute alte Hamster von Jürgen Haible (http://www.elbiah.de/hamster/), hat heute kein Problem im Mailverkehr, denn er wurde RFC-konform entwickelt 
Disclaimer: Ich bin der Autor der OE-FAQ für den Hamster.
Disclaimer: Ich bin der Autor der OE-FAQ für den Hamster.
Last edited by a moderator:
Hallo zusammen,
das interessiert mich dann jetzt doch noch einmal.
Ich habe folgende Konfiguration:
Normaler Mailserver (nennen wir ihn "Server A") mit Postfix verfügt über mehrere IPs. Über all diese IPs wird gesendet - und zwar über einen geschlossenen SMTP-Relayserver ("Server B").
Alle IPs, die für den Server A konfiguriert sind, haben einen RDNS-Eintrag auf den Hostnamen; der FQDN wird auch als SMTP-Banner verwendet.
Der Relayserver verfügt nur über eine IP, die auch einen RDNS aufweist (FQDN des Relayservers).
Server A hat zudem einen MX-Record, sowie einen A-Record im DNS.
Server B hat einen A-Record aber keinen MX-Record.
Eigentlich sollte die Konfiguration doch passen, oder?
Was mir auffällt: Im Header einer Email, die ich mal an mich selbst geschrieben habe, steht:
Die in eckigen Klammern stehende IP hat aber einen RDNS-Eintrag auf den FQDN des Server A. Könnte hier der Fehler liegen?
Allerdings ist Server A ja nicht die letzte Station vor dem Kunden, die Mail geht ja noch über Server B. Bei Server B tritt dieses Phänomen nicht auf.
das interessiert mich dann jetzt doch noch einmal.
Ich habe folgende Konfiguration:
Normaler Mailserver (nennen wir ihn "Server A") mit Postfix verfügt über mehrere IPs. Über all diese IPs wird gesendet - und zwar über einen geschlossenen SMTP-Relayserver ("Server B").
Alle IPs, die für den Server A konfiguriert sind, haben einen RDNS-Eintrag auf den Hostnamen; der FQDN wird auch als SMTP-Banner verwendet.
Der Relayserver verfügt nur über eine IP, die auch einen RDNS aufweist (FQDN des Relayservers).
Server A hat zudem einen MX-Record, sowie einen A-Record im DNS.
Server B hat einen A-Record aber keinen MX-Record.
Eigentlich sollte die Konfiguration doch passen, oder?
Was mir auffällt: Im Header einer Email, die ich mal an mich selbst geschrieben habe, steht:
Die in eckigen Klammern stehende IP hat aber einen RDNS-Eintrag auf den FQDN des Server A. Könnte hier der Fehler liegen?
Allerdings ist Server A ja nicht die letzte Station vor dem Kunden, die Mail geht ja noch über Server B. Bei Server B tritt dieses Phänomen nicht auf.
danton
Debian User
Wo hast du den PTR zu der IP den definiert? Die Zone mit den PTRs verwaltet der Inhaber der IP, also i.d.R. der Server-Anbieter. Bei den meisten kannst du sie im Kundenmenü des Serveranbieters selbst setzen.
Falls du den PTR auf einem DNS-Server erstellt hast, den du selbst betreibst oder auf dem deines Domain-Anbieters mit eingetragen hast, dann wird er ignoriert.