Wieder mal GMX und Web.de

Willi

Willi

Member
Hallo,

ich habe einen Server bei Strato und bin vor kurzem Strato-intern umgezogen. Der Mailversand lief auch für ca. 3 Wochen problemlos. Aber seit gestern bekomme ich von GMX und Web.de die Meldung das keine SMTP-Verbindung aufgebaut werden kann und die Mail-Queue wird immer länger. Andere Domains funktionieren.

Ein Versuch sich per Telnet zu verbinden gibt dann folgende Meldung:

willi@h2504000:~$ telnet mx01.emig.gmx.net 25
Trying 212.227.17.5...
Connected to mx01.emig.gmx.net.
Escape character is '^]'.
554-gmx.net (mxgmx108) Nemesis ESMTP Service not available
554-No SMTP service
554-Bad DNS PTR resource record.
554 For explanation visit http://postmaster.gmx.com/en/error-messages?ip=81.169.244.186&c=rdns
Connection closed by foreign host.
willi@h2504000:~$
Click to expand...

Aber mein rDNS ist auf den Host gesetzt der auch in /var/qmail/Control/me steht. Ein Telnet auf meinen Server zeigt auch das der Banner korrekt ist. Ich stehe etwas auf dem Schlauch.

Es geht um den Server h2504000.stratoserver.net mit der IP-Adresse 81.169.244.186

Danke und Grüße,
Willi
 
Willi said:
Andere Domains funktionieren.
Click to expand...

Liegen diese Domains ebenfalls auf diesem Server bzw. ist der Server für den Mailversand und Mailempfang dieser Domains zuständig?

Netcup hatte vor kurzem auch den Fall, das Web.de und GMX deren rDNS (yourvserver.net) gesperrt haben.

Notfalls ändere den PTR mal auf etwas wie z.B.
Code: 
mail.deinedomain.tld
 
Ja, der ist für die ganzen Domains zuständig. Die entsprechenden MX-Records sind auch entsprechend definiert.

Ich habe GMX mal angeschrieben. Aber zu der Zeit jetzt rechne ich mit einer etwas verlängerten Wartezeit :D

Vielen Dank für den Tip. Ich befürchte fast das ich nicht darum herum komme.
 
d3p said:
Liegen diese Domains ebenfalls auf diesem Server bzw. ist der Server für den Mailversand und Mailempfang dieser Domains zuständig?
Click to expand...

Das hatte ich falsch verstanden. Ich meinte das der Versand zu anderen externen Domains funktioniert. Für die ist mein Server natürlich nicht zuständig.
 
d3p said:
Notfalls ändere den PTR mal auf etwas wie z.B.
Code: 
mail.deinedomain.tld
Click to expand...

Das habe ich jetzt mal gemacht. Das bringt es natürlich mit sich das ich auch /var/qmail/control/me und /var/qmail/control/local anpassen muss. Wenn ich mich aber erinnere werden die immer von Plesk bei einem Update wieder überschrieben. Deshalb wollte ich das eigentlich nicht tun. Auch wenn es jetzt erstmal wieder funktioniert.

Zunächst mal Danke. Ich melde mich wenn ich was von GMX gehört habe.
 
Gleiches Problem

Hallo zusammen,

leider haben wir ebenfalls seit gestern das gleiche Problem.
Es handelt sich dabei ebenfalls um einen Root-Server bei Strato auf dem mehrere Domains laufen.

Wenn ich jetzt vom Server folgendes telnet ausführe:
telnet mx01.emig.gmx.net 25
erhalte ich folgende Meldungen:
Connected to mx01.emig.gmx.net.
Escape character is '^]'.
554-gmx.net (mxgmx109) Nemesis ESMTP Service not available
554-No SMTP service
554-Bad DNS PTR resource record.
554 For explanation visit http://postmaster.gmx.com/en/error-messages?ip=81.169.224.63&c=rdns
Connection closed by foreign host.

Das gibts doch nicht!!!

Kann mir bitte jemand erklären, was bei dem telnet geprüft wird, dass das so nicht mehr geht?
Auf einem anderen Server funktioniert der telnet Aufruf und der Service meldet sich als "ready" :-(

Ich habe unseren Server mit mxtoolbox.com geprüft und es sieht wirklich alles sehr gut aus.

Ich wäre sehr dankbar wenn mir das jemand erklären könnte.

Danke!
 
Ein Glück muss ich zu GMX keine Mails schicken:

Code: 
root@mail:~# netcat mx01.emig.gmx.net 25
220 gmx.net (mxgmx112) Nemesis ESMTP Service ready
EHLO mail.fuslvz.ws
421 gmx.net Service closing transmission channel - command timeout
Code: 
root@mail:~# netcat mx01.emig.gmx.net 25
220 gmx.net (mxgmx112) Nemesis ESMTP Service ready
EHLO mail.fuslvz.ws
MAIL FROM:<testing@meo.ws>
RCPT TO:<testing@gmx.de>
DATA
421 gmx.net Service closing transmission channel - command timeout
 
Frage an Willi

Welchen PTR hast du, und wo, geändert?
Hast du im Strato-Backend den Rechnernamen von (h2504000.stratoserver.net) umbenannt?

Bin gerade etwas verloren :-(

Danke
 
Moin, moin,

ich habe im Strato-Backend unter Domainverwaltung -> DNS-Reverse habe ich den Eintrag in "mail.domain.tld" unter "anderen FQDN angeben" eingetragen. dann noch die /var/qmail/control/me" und "/var/qmail/control/locals" anpassen und ein bisschen warten. Dann nimmt GMX auch wieder Mails an.

Ich bin mir aber noch unschlüssig ob das der Weisheit letzter Schluss ist.
 
Last edited by a moderator:
Danke!

aha okay. Da bin ich auch gerade drüber gestolptert.
Hast du dann aber auch für jede Domain den MX Eintrag geändert?

Das ist doch alles ziemlich merkwürdig.

GMX hat sich bei dir auch noch nicht gemeldet, oder? Meine Anfrage gestern wurde nämlich noch nicht beantwortet.

Was ich ziemlich seltsam finde:
Laut Logfile haben wir die Probleme auf unserem Server seit dem 13.12.2015, vorher ging alles einwandfrei.

Auch die Prüfungen mit mxtoolbox.com schauen alle sauber aus :-(
Ich verstehe einfach nicht woran es liegt...wenn du jetzt mit der geänderten Einstellung auf deinem Server per telnet an den mx01.emig.gmx.net gehst, funktioniert das dann auch wieder?

Danke!
 
Die Verwendung eines PTRs, der nicht auf einen FQDN innerhalb der Strato-Domain liegt, sondern auf eine Subdomain der eigenen Domain zeigt ist immer eine gute Idee. Gerade PTRs, die einen generischen Charakter haben, scheitern auch gerne mal an irgendwelchen Spamfiltern. Das wurde hier im Forum schon oft genug diskutiert.
 
Was mich bei meiner Lösung noch gestört hat war die Änderung der "me" und der "locals" da Plesk diese gerne bei Updates wieder überschreibt. Aber ich habe dabei eine Möglichkeit übersehen. Wenn im Verzeichnis "/var/qmail/control" die Datei "helohost" liegt wird diese für das Banner verwendet. Existiert diese nicht wird "me" verwendet. Also habe ich diese Datei angelegt und dort dann "mail.domain.tld" eingetragen und den rDSN wie oben beschrieben gesetzt. Damit funktioniert es auch. Mails werden an GMX gesendet und "me" bzw. "locals" sind unverändert. Damit kann ich jetzt gut leben.

MX-Records habe ich keine verändert. Das würde keinen Sinn machen.

Bei mir funktioniert es damit jetzt.

GMX hat sich noch nicht gemeldet. Werde das hier kundtun sollte sich das noch ändern. Du hoffentlich auch ;)
 
Du solltest den HELO-String in Plesk ändern können, wenn Plesk diesen wieder überschreibt (da ich kein Plesk nutze, kann ich dir aber nicht sagen, wo).
Außerdem hat der HELO nix mit dem PTR zu tun, die können unterschiedlich sein (und sind es oft auch, ist bei mir z.B. der Fall). Was sein muß:
Es muß zum PTR einen passenden A-Record geben, der wieder die IP zurückliefert. Ebenso muß der HELO per A-Record zur IP des Servers auflösen.
Joe User hat es mal hier gepostet, ist zwar für Postfix gilt aber analog auch für qmail.
 
danton said:
Du solltest den HELO-String in Plesk ändern können, wenn Plesk diesen wieder überschreibt (da ich kein Plesk nutze, kann ich dir aber nicht sagen, wo).
Außerdem hat der HELO nix mit dem PTR zu tun, die können unterschiedlich sein (und sind es oft auch, ist bei mir z.B. der Fall). Was sein muß:
Es muß zum PTR einen passenden A-Record geben, der wieder die IP zurückliefert. Ebenso muß der HELO per A-Record zur IP des Servers auflösen.
Joe User hat es mal hier gepostet, ist zwar für Postfix gilt aber analog auch für qmail.
Click to expand...

Nein, in Plesk kann man den HELO-String nicht ändern. Es wird in der Grundkonfiguration der Hostname genommen. Und der ist halt aus dem Strato-Netz. Also ein hnnnnnnn.stratoserver.net. Das wird auch in die entsprechende qmail-Konfigurations-Datei geschrieben die für alles mögliche, so auch für den Banner, genommen wird falls keine andere Angaben gemacht werden. Und diese Datei wird bei einem Plesk-Update auch immer wieder überschrieben.

Alle anderen Angaben die Joe User gemacht hat treffen auch zu. Nur das halt in der Grundeinstellung dieser Strato-Name genommen wird zu dem es aber auch keinen MX-Eintrag gibt.

Das führt dann bei GMX und angeschlossenen Hostern zum Problem. Denn wenn aufgrund des HELO-Strings ein Check auf rDSN und eventuell auch auf MX-Eintrag gemacht wird gibt es einen Fehler.

Nachdem ich nun den rDSN auf mail.domain.tld gesetzt habe und den HELO-String korrekt gesetzt habe funktioniert es ja.
 
Willi said:
Es wird in der Grundkonfiguration der Hostname genommen. Und der ist halt aus dem Strato-Netz. Also ein hnnnnnnn.stratoserver.net.
Click to expand...

Und den kannst und solltest du auch ändern, z.B. auf host.domain.de (und dazu passend der A-Record und ggfl. AAAA-Record güt IPv6). Dieser gehört auch in den/die PTR rein, nicht mail.domain.de

Alle anderen Angaben die Joe User gemacht hat treffen auch zu.
Click to expand...
Nein, siehe oben - in den PTR gehört den Hostname und nicht der HELO des Mailservers.

Nur das halt in der Grundeinstellung dieser Strato-Name genommen wird zu dem es aber auch keinen MX-Eintrag gibt.
Click to expand...

Warum auch? Der MX-Eintrag ist im Zusammenhang mit dem Mail-Versand völlig uninteressant, er wird nur für den Mail-Empfang benötigt. Ganz davon ab könntest du bei deinen Domains ja problemlos einen MX anlegen, der auf hXXX.stratoserver.net zeigt...
Das Problem bei Namen wie hXXX.stratoserver.net ist, dass diese gerne mal "in Massenhaft" genommen werden, d.H. wenn mehrere Hosts auffällig geworden sind, wird die Domain gesperrt und nicht nur einzelne Subdomains.
 
Guten Tag,


es ist rein vom RFC her nichts verwerfliches daran, einen rDNS wie servername.anbietername.tld zu nutzen, wenn die Domain auch per A bzw. optional auch per AAAA auf die IP-Adressen des Servers zeigt.

Die Tochterunternehmen der United Internet AG web.de und gmx scheinen aktuell vermehrt Mailserver zu sperren die nicht in einem Zusammenhang mit der United Internet AG stehen, wie z.B. Server von 1 und 1. Das kann durchaus als Schachzug aufgefasst werden, um Unternehmen die im Wettbewerb zu 1 und 1 stehen die Arbeit zu erschweren.

Wir waren auch von dem Blacklisting betroffen und hatten dadurch vermehrt Supportanfragen und am Ende deutliche Kosten.


Viele Grüße

Felix
 
danton said:
Und den kannst und solltest du auch ändern, z.B. auf host.domain.de (und dazu passend der A-Record und ggfl. AAAA-Record güt IPv6). Dieser gehört auch in den/die PTR rein, nicht mail.domain.de
Click to expand...

Das ich den ändern sollte kann ich noch nicht wirklich nachvollziehen. Was spricht dagegen den Namen beizubehalten? Z.B. kann ich bei Beibehaltung des Namens das Plesk-Panel Domain-neutral auch den Kunden zur Verfügung stellen ohne das hier eine der gehosteten Domains genutzt werden muss. Das wäre der Fall sollte ich den Hostnamen ändern soweit ich weiß.

danton said:
Nein, siehe oben - in den PTR gehört den Hostname und nicht der HELO des Mailservers.
Click to expand...

Korrekt. Ich denke da habe ich mich unglücklich ausgedrückt. Aber das ist schon klar. Wobei der HELO auf dieselbe IP auflösen muss und die IP auch wieder auf den HELO.

[netcup] Felix;371384 said:
Guten Tag,


es ist rein vom RFC her nichts verwerfliches daran, einen rDNS wie servername.anbietername.tld zu nutzen, wenn die Domain auch per A bzw. optional auch per AAAA auf die IP-Adressen des Servers zeigt.

Die Tochterunternehmen der United Internet AG web.de und gmx scheinen aktuell vermehrt Mailserver zu sperren die nicht in einem Zusammenhang mit der United Internet AG stehen, wie z.B. Server von 1 und 1. Das kann durchaus als Schachzug aufgefasst werden, um Unternehmen die im Wettbewerb zu 1 und 1 stehen die Arbeit zu erschweren.

Wir waren auch von dem Blacklisting betroffen und hatten dadurch vermehrt Supportanfragen und am Ende deutliche Kosten.


Viele Grüße

Felix
Click to expand...

Danke. Genau das "wollte" ich hören. Soll heissen: das war mein Verständnis der Sachlage aber mir fehlte irgendwie der Glaube das dies so passierte.
 
[netcup] Felix;371384 said:
es ist rein vom RFC her nichts verwerfliches daran, einen rDNS wie servername.anbietername.tld zu nutzen, wenn die Domain auch per A bzw. optional auch per AAAA auf die IP-Adressen des Servers zeigt.
Click to expand...

Was nützt das tollst RFC, wenn die Praxis leider anders aussieht. Wie ich oben schon schrieb, ist das Problem ja eben nicht der RFC, sondern vielmehr die Tatsache, dass einigen Anbieter eine "Sippenhaft" vornehmen.
Und wenn ich deine Nachricht so lese, dass nicht nur Strato betroffen ist, dann scheint United Internet wohl mehrere Anbieter im Fadenkreuz zu haben... (ein Schelm, wer böses dabei denkt...)
 
You must log in or register to reply here.
Back
Top