EXCH - HELO server.lokaldomain.local wird abgewiesen
Hallo,
wir versenden mit fast allen Exchange Servern über einen Smarthost hinaus. Bei einem allerdings erfolgt der Versand direkt (über DNS). Nun werden GMX-Empfänger abgewiesen. Nachgefragt beim Support (mailsecurity@gmxnet.de) erhielt ich folgende Nachricht:
Ihr E-Mail-Server ist bei der Zustellung einer E-Mail in unser System abgewiesen worden, weil Ihr Server ein HELO geschrieben hat, das nicht rückwärts aufgelöst werden konnte (vermutlich "Server.lokaldomain.local").
Dies ist eine Fehlkonfiguration (siehe RFC5321) und weist in der Regel auf ein mit schädlicher Software verseuchtes System hin.
Der Exchange DNS ist als mail.beispieldomain.at registriert.
In den Empfangs u. Sendeconnectoren erlaubt mir Exchange das Eintragen des externen DNS-Namens nicht.
Ist bestimmt nur eine Kleinigkeit - bitte um kurze Hilfe!
Danke für jeden Tipp!
Problem gelöst: Ich hab als EHLO Eintrag in den Sendeconnector jenen externen DNS-Namen eingetragen, der die ext. IP auflöst. Nun scheint es zu funktionieren. Interessant, dass das Problem plötzlich aufgetreten ist, früher ging alles...
Problem gelöst: Ich hab als EHLO Eintrag in den Sendeconnector jenen externen DNS-Namen eingetragen, der die ext. IP auflöst. Nun scheint es zu funktionieren.
Na, ja. So richtig gelöst hättest Du es erst, wenn Du, wie Dukel schon geschrieben hat, einen Reverse-DNS-Eintrag bei Deinem Internet-Provider für den MX-Eintrag (mail.beispieldomain.at) setzten lässt.
Interessant, dass das Problem plötzlich aufgetreten ist, früher ging alles...
Weil GMX erst jetzt einen Reverse-Lookup auf die Mail-Domain macht und die Mails ohne diesen nicht mehr annimmt? Mittlerweile ist das allerdings Standard.
erzänzend hierzu, als Anmerkung auf #5: Der Reverse Eintrag muss zum FQDN im Connector passen, also im zum Mail HELO, nicht zum MX. Der MX kann natürlich woanders hin zeigen, dann man muss selbst verständlich nicht mit der gleichen IP/Name senden, wie man empfängt (wäre bei Mail-Provider auch technisch gar nicht wirklich machbar).
Die Prüfung sieht in der Regel wie folgt aus:
Verbindung meldet sich mit IP w.x.y.z und FQDN "mail.irgendwoher.tld". Wir testen Reverse-Eintrag für den Namen (siehe bei iDiddi) und müssen die IP w.x.y.z rausbekommen. Kommt da eine andere -> Fehler.
Und noch eine kleine Ergänzung zu iDiddi: Bei dem Eintrag hier "<Mailserver-IP>.in-addr.arpa" wird die IP rückwärts angezeigt. Das ist ok, Revers-Einträge sind immer rückwärts.
Der MX kann natürlich woanders hin zeigen, dann man muss selbst verständlich nicht mit der gleichen IP/Name senden, wie man empfängt (wäre bei Mail-Provider auch technisch gar nicht wirklich machbar).
Ja. Das stimmt. Wenn er über einen Smarthost versenden würde. Was er in diesem Fall ja nicht tut.
Und noch eine kleine Ergänzung zu iDiddi: Bei dem Eintrag hier "<Mailserver-IP>.in-addr.arpa" wird die IP rückwärts angezeigt. Das ist ok, Revers-Einträge sind immer rückwärts.
Sie werden halt nur nicht immer rückwärts angezeigt. Wie z.B. standardmäßig im DNS-Server von Microsoft
Ja. Das stimmt. Wenn er über einen Smarthost versenden würde. Was er in diesem Fall ja nicht tut.
Mir ging es auch um die allgemeine Aussage, der MX stimmt. MX ist in diesem Fall unwichtig.
Zitat von iDiddi
Sie werden halt nur nicht immer rückwärts angezeigt. Wie z.B. standardmäßig im DNS-Server von Microsoft
Ja, aber bei NSLOOKUP: Man gibt vorwärts ein und bekommt sie rückwärts zurück. Das MSFT in anderen Programmen die Arbeit erleichtern/erschweren will, ist ein anderes Thema
EXCH - HELO server.lokaldomain.local wird abgewiesen
