Wieder mal GMX und Web.de

Willi

New 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:~$
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
 

d3p

Blog Benutzer
Andere Domains funktionieren.
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
 

Willi

New Member
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.
 

Willi

New Member
Liegen diese Domains ebenfalls auf diesem Server bzw. ist der Server für den Mailversand und Mailempfang dieser Domains zuständig?
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.
 

Willi

New Member
Notfalls ändere den PTR mal auf etwas wie z.B.
Code:
mail.deinedomain.tld
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.
 

schweinsbratn

New Member
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!
 

Fusl

Blog Benutzer
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
 

schweinsbratn

New Member
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
 

Willi

New Member
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:

schweinsbratn

New Member
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!
 

danton

Debian User
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.
 

Willi

New Member
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 ;)
 

danton

Debian User
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.
 

Willi

New Member
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.
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.
 

danton

Debian User
Es wird in der Grundkonfiguration der Hostname genommen. Und der ist halt aus dem Strato-Netz. Also ein hnnnnnnn.stratoserver.net.
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.
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.
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.
 

[netcup] Felix

Blog Benutzer
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
 

Willi

New Member
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
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ß.

Nein, siehe oben - in den PTR gehört den Hostname und nicht der HELO des Mailservers.
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
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.
 

danton

Debian User
[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.
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...)
 
Top