Kein Mailversand mehr an T-Online möglich

danton

Debian User
Du suchst die eine der vorhandenen Domains aus oder registriest noch eine neutrale Domain. Für die konfigurierst du dann Einträge im DNS:
mail.domain.de A IP.VOM.SER.VER
Bei 1&1 im Kundenmenü stellst du dann als ReverseEintrag für deine IP mail.domain.de ein.
Außerdem kommt in die me-Datei auch mail.domain.de
Und um das ganze richtig rund zu bekommen, trägst du noch für alle anderen Domains auf deinem Server im DNS einen dazu passenden MX ein:
anderedomain.de MX mail.domain.de
 

Domi

Blog Benutzer
@wewe, das Thema hatte ich ja mit danton schon in einem anderen Topic ein wenig angekratzt, da ich vor der gleichen Problematik stand.. mein 1und1 Server wurde vor einer Woche von T-Online geblockt :rolleyes:

Was danton nun meint (wenn ich es richtig verstehe), nimm Dir eine Domain domain1.tld, diese trägst Du in die "me" Datei ein, bei dem Server änderst Du dann den reverse-DNS Eintrag von s1234xxxx.onlinehome-server.info -> domain1.tld und die ersten kleinen Schritte sind gemacht.

Wenn Du jetzt den DNS für deine Domains (domain2.tld etc.) verändern kannst, erstellst Du diese wie folgt...
- domain2.tld A 127.0.0.1 (natürlich deine IP!!)
- mail.domain2.tld MX domain1.tld

- domain3.tld A 127.0.0.1
- mail.domain3.tld MX domain1.tld

so habe ich es zumindest in einem Topic von mir verstanden.
 

wewe

New Member
ok. Kapiert!

kriegen dann aber die "anderen domains" keine Probleme (domain2.tld und domain3.tld)? Die Mails werden ja jetzt von einem "fremden" Mailserver (domain1.tld) verschickt?
 

Domi

Blog Benutzer
Also wenn dein Postfix (oder Qmail) eine Email an einen anderen Server sendet, sagt er "hallo ich bin bla bla", das ist helo/ehlo. Darin befindet sich auch der Name von deinem Server (domain1.tld)!

Wenn Du nun eine Email von [email protected] an eine GMX Adresse sendest, sagt dein Server erstmal "hallo ich bin domain1.tld", GMX nimmt das Paket an und freut sich. Wenn durch GMX (oder wer auch immer das macht) eine Überprüfung kommt (z.B. mail.domain2.tld) und diese verweist auf domain1.tld, sollte es keine Probleme geben.

So habe ich das ganze zumindest verstanden. Ich hatte ja mit unserem 1und1 Server (und Qmail) das gleiche Problem. Allerdings habe ich noch einen Server bei Hetzner der noch nicht konfiguriert ist, da muss ich das dann alles richtig einstellen. Hatte das Thema hier auch schon mal angesprochen :D

Bist also nicht der erste / einzige der von t-online geblockt wird.
Mfg. Anubis
 

wewe

New Member
ok.

gleich noch eine (vermutlich blöde) Frage hinterher: der reverse DNS Eintrag kann der "domain1.tld" lauten oder muss der "full qualified" sein wie z.B. "mail.domain1.tld"? Und falls Zweiteres, kann ich mir dann irgendeinen hostnamen ausdenken (wie hier z.B. "mail") oder hat das auch wieder irgendwelche Auswirkungen?

P.S. Hab jetzt mal angefangen, meine Einträge anzupassen ... werd berichten, wie's läuft. Ich denke, dass derzeit 'ne Menge Leute hier mitlesen.

mfg
Wolfgang
 

Domi

Blog Benutzer
Öhm, jetzt wird es etwas speziell... Aber wenn ich so durch meine Config von Postfix gucke, muss es ein FQDN sein. Denn eine Regel in der Config besagt "reject_non_fqdn_...", und wenn ich mir so die Config Dateien von anderen Anschaue, ist die wohl sehr zu Empfehlen.

Also zähle ich jetzt mal 1 und 1 zusammen, und sage "ja, ein fqdn ist sehr zu empfehlen!" :) Meine Server bekommen auch so etwas wie "srv01.domain.tld" ;)
 

danton

Debian User
In die me Datei von qmail gehört der Name, der auch als PTR (ReverseDNS) für den Server konfiguriert ist. Grundsätzlich kann man sich was ausdenken, sofern es nicht lange Zahlenketten enthält, oder auf die IP schließen läßt, aber mail.domain.de oder srv01.domain.de o.ä. sind da eine gute Wahl.
Wichtig ist, daß dieser Name sich per A-Record im DNS auf die IP des Servers auflösen läßt (kein CNAME, also kein Alias). Außerdem sollten die MX-Einträge der anderen Domains auch darauf zeigen, das bedeutet ja nix anderes wie: Mails für domain2.de werden von mail.domain.de verwaltet (nix anderes machen ja auch große Webhoster).
Ein nslookup auf mail.domain.de muß die IP deines Servers zurück melden, ein nslookup auf die IP wiederum mail.domain.de:
Code:
mail.domain.de A 1.2.3.4
1.2.3.4 PTR mail.domain.de
domain.de MX mail.domain.de
anderedomain.de MX mail.domain.de
anderedomain2.de MX mail.domain.de
 

wewe

New Member
nachdem ich mit euer aller Hilfe einen meiner Server zurechtgebogen habe und ERFOLGREICH eine Mail an t-online geschickt habe, versuch ich mich jetzt einmal an einem "Kochrezept" - sozusagen von Halb-Profi zu Halb-Profi. Was ich schreibe, gilt für einen bei 1&1 gehosteten Server (ob Plesk im Spiel ist oder nicht spielt keine Rolle. Plesk wird hierfür nicht gebraucht).

Letztendlich gilt es den Zustand zu erreichen, der im Kasten obendrüber in danton's post steht.

Es sind vier Stellen, an denen eingegriffen werden muss (wenn eine Domäne im Spiel ist):

  • 1. Eine Sub-Domain erzeugen, die für den PTR genutzt werden soll.

    Einloggen in das 1&1 Control Center. Auf "Domains & Webspace" und dort auf "Domains" klicken.

    Falls du mehrere Domains auf diesem Server betreibst musst, du dich entscheiden, welche als "Mailer-Domain" genutzt werden soll. Diese wird dann für sich selbst und auch für die anderen Domains nach aussen hin als "Mailer" genannt. Hier z.B. "domain1.tld".

    Jetzt musst du eine Sub-Domain erzeugen wie z.B. "mail.domain1.tld". Dazu im Kästchen vor der betreffenden Domain einen Haken, dann auf "Neu" und "Subdomain anlegen". Dann hinten die Domain auswählen und vorne einen "beliebigen Namen" eintragen. Sinn macht z.B. "mail" (lange Nummern und was nach IP-Adresse aussieht, sind hier zu vermeiden). Dann auf "ok."

    Wenn du schon eine Sub-Domain hast, die du verwenden willst, kannst du diesen Schritt natürlich auslassen.

  • 2. MX-Eintrag der Domäne setzen

    Jetzt verpassen wir der Domäne, deren Mails von T-Online beanstandet werden, einen neuen MX-Eintrag. Das heisst, wenn von aussen angefragt wird, welche Domain für die Mails von dieser Domain zuständig ist, wird zurückgegeben, was hier als MX-Eintrag hinterlegt wird.

    Wieder in die 1&1 Domain Liste, einen Haken vor der betreffenden Domain, dann auf "DNS" und "Einstellungen bearbeiten".

    Unten im Formular bei "MX-Einträge" auf "Anderer Mailserver".

    Dann bei "MX0 / Server / Prio" auf "Ihr Server" und in der Auswahliste die oben erzeugte Sub-Domain auswählen (Beispiel: "mail.domain1.tld"). Im hintersten Feld "10" eintragen.

    Bei "MX1 / Server / Prio" (sozusagen der Ersatzserver) habe ich "Benutzerdefiniert" gewählt und dann den 1&1-Server, der vorher schon als Ersatzserver drin stand, wieder eingetragen (bei mir mx01.kundenserver.de). Im hintersten Feld "20" eintragen. Ob der Ersatzserver hier überhaupt nötig ist oder ob es reichen würde, nur den MX0 einzutragen, weiß ich nicht.

    Speichern!

  • 3. "PTR Eintrag" bzw. "ReverseDNS" bzw. "Reverse Mapping" (wie es bei 1&1 heisst)

    In das 1&1 Control Center. Auf "1&1 Server" klicken, dort dann auf "IP-Adressen".

    Auf die IP-Adresse des Servers klicken (z.B. 10.10.10.10).

    Dann in das Feld "Reverse Mapping" ebenfalls die oben erzeugte Subdomain eintragen ("mail.domain1.tld").

    Speichern!

  • 4. Den "Helo Eintrag" deines Mailservers anpassen

    Ja, jetzt geht's tatsächlich mal auf den Server! Also, einloggen, mit was auch immer du dich auf dem Server einloggst (ich mache das mit "ssh"), und für:
    qmail die Datei "/var/qmail/control/me" editieren. Dort steht etwas wie "s12345678.onlinehome-server.info". Dies ersetzen durch die oben erzeugten Sub-Domain (also "mail.domain1.tld")
    postfix die Datei "/etc/postfix/main.cf" editieren. Dort den Eintrag "myhostname" anpassen. Also "s12345678.onlinehome-server.info" ersetzen durch "mail.domain1.tld"

Das war's im Prinzip ...

Zum Timing: Punkt 1 sollte sofort greifen, auf die Sub-Domain wird innerhalb deines Servers verzeigert, Punkte 2 und 3 dauern ein paar Stunden. Die neuen Einträge müssen sich erst auf den entsprechenden Servern im Internet verbreiten. Punkt 4 greift wiederum sofort. Ich habe das also so gemacht, dass ich zuerst 1 und dann 2 und 3 durchgeführt habe, dann gewartet habe, bis 2 und 3 angekommen sind (wie das festgestellt werden kann, kommt weiter unten) und dann als letztes Punkt 4.

Bei mehreren Domains auf einem Server muss der zweite Punkt ("MX-Eintrag der Domäne setzen") für alle anderen Domains auch ausgeführt werden aber immer mit der gleichen oben erzeugten Sub-Domain. Also, auch wenn es um die "domain2.tld" geht, wird trotzdem "mail.domain1.tld" als MX-Eintrag verwendet.

Falls dein Server über mehrere IP-Adressen verfügt, musst du natürlich darauf achten, dass die obigen Punkte alle die gleiche IP-Adresse verwenden.

Nachprüfen, ob die neuen Einträge schon greifen, kann man z.B. damit: http://www.check-tools.net/dns-check/ oder damit: http://tools.ispservice.ch/host2ip-reversedns.php oder anderen Tools oder gar Kommandozeilen Befehlen (z.B. "nslookup -q=mx domain1.tld" für den MX Eintrag und "dig -x 10.10.10.10" für den PTR). Aber Vorsicht: die obigen Web-Tools scheinen einem Cache-Mechanismus zu unterliegen. Was beim einen noch angezeigt wird, ist möglicherweise beim anderen schon geupdated.

Im Prinzip gilt es zwei Sachen zu testen: ist der "PTR geupdated" und ist der "MX-Record geupdated". Nach meiner Erfahrung, sprechen sich die Änderungen so innerhalb von 2 bis 3 Stunden im Internet rum.

Den "Helo Eintrag" kannst du mit "telnet domain1.tld 25" testen. Dort sollte sich der Mailer mit dem neuen MX Eintrag melden (z.B. "220 mail.domain1.tld ESMTP Postfix").


Wenn alles geupdated ist, eine nette Mail an T-Online schicken, dass sie deine Mails doch jetzt bitte wieder zustellen mögen ... :)


mfg
Wolfgang

P.S. Falls ich groben Mist eingebaut habe, bitte ich die Voll-Profis unter uns helfend einzugreifen :D
 
Last edited by a moderator:

danton

Debian User
Eine kleine Anmerkung dazu habe ich noch: Man sollte wirklich nur einen MX eintragen und nicht mehrere, wenn die anderen MXe nicht auch unter der eigenen Kontrolle stehen. Der Grund sind Spam-Abwehr-Maßnahmen - diese sollten auf allen Mail-Servern gleich sein, damit bestimmte Mechanismen wie Grey- oder Blacklisting nicht umgangen werden können. Also die 1&1-Mailserver rauswerfen und nur noch den eigenen verwenden. Spammer versuchen gerne, ihren Müll bei Servern mit niedrigerer Prio abzukippen, weil diese oft weniger nicht ganz so scharfe Antispam-Maßnahmen haben.
 

Huschi

Moderator
Staff member
Der MX-Record und Hostname; eine Welt voller Missverständnisse!

Sorry wewe, aber Dein "Kochrezept" ist viel zu lang, umständlich und Inhaltlich - wie soll ich sagen - sehr umständlich und verwirrend.
Du würfelst ein bisschen viel die MX und Hostnames durcheinander.

Nur mal so zur Richtigstellung:
- Ein MX sollte eh jede Domain haben (auch wenn es theoretisch auch ohne geht).
- Der MX ist immer eine Domain und keine IP. (Das nur der Vollständigkeit halber.)
- Als MX kann auf jede beliebige Domain eingesetzt werden die wiederum auf den gewünschten Server zeigt.
-> Der MX von domain1.tld kann also selber domain1.tld lauten.

Aber wenn das schon vorher funktioniert hat, braucht es hier auch keine Änderungen.

Wichtig für T-Online ist nur der Hostname des Servers und seine PTRs der IPs.
- Pro IP sollte eine eigene Subdomain angelegt werden und als PTR gesetzt werden.
- Dabei eben die "generischen Domains" überschreiben.
- Dann wird der Hostname der Haupt-IP auf dem Server gesetzt.
-> Geht bei Plesk am einfachsten über Plesk selbst. Das setzt alle nötigen Einstellungen (z.B. für Qmail/Postfix) selber und verhindert die "geisterhafte Änderungen" bei Plesk-Updates.

Probleme gibt es ggf. mit mehreren IPs auf dem Server, weil dann beim Versand der Helo-String ggf. nicht zur Absender-IP passen. Daher hier im Idealfall dafür sorgen, dass immer nur von der Haupt-IP verschickt wird.
Das ist aber ein Thema für sich...

huschi.
 

pangu

New Member
Ich stehe derzeit vor dem selben Problem. Es gibt tatsächlich einige Mail-Provider, die die eingehende IP checken und den PTR überprüfen. IP muss also auf PTR zeigen, und der Hostname ebenfalls auf diese IP. Ansonsten akzeptieren sie das gar nicht. Soweit verstehe ich das auch, ist auch in der RFC xyz (habs grad nicht parat) festgelegt.

Also ich habe meinem Server, der die IP 1.2.3.4 besitzt, den PTR mein.rootserver.net zugewiesen. Das ist auch weltweit propagiert und aktiv. Ich sollte also nicht an oben genannten Checks scheitern.

Ich stehe aber vor folgender Frage/Problem. Vorab: ich hab nur eine einzige IP und betreibe mehrere Sites durch vHosts. Damit ich nun für all gehosteten Domains unter meinem Rootserver ordnungsgemäß Mails versenden kann so daß nix geblockt wird, muss ich zwangsweise die Zuweisung 1.2.3.4 <--> mein.rootserver.net beibehalten, damit alle strengen Mailserverbetreiber draussen auf der Welt die Mails von meinem rootserver annehmen.

Ich kann jetzt für meine gehosteten Domains am Rootserver folgende Settings durchführen:

Für die Kundensite "domain1.de" gebe in seiner DNS-Zone einen A-record "mail" ein, der auf 1.2.3.4 verweist. Als MX-Eintrag lege ich Prio 10 an und der zeigt wiederum auf "Mail". Fertig!

Im Internet propagiert ist also der verantwortliche MX für domain1.de der hostname mail.domain1.de und dieser zeigt auf die IP 1.2.3.4
Soweit so gut, aber: wenn jetzt [email protected] eine Mail versendet an solch einen strengen Mailserver draussen im Internet, dann würde der strenge MTA die Mail rejecten. Warum? Weil er kriegt eine Anfrage von der domain1.de, löst diese auf und kriegt die IP 1.2.3.4 zurückgeliefert. Jetzt mach der MTA draussen aber noch einen Reverse-Check indem er die 1.2.3.4 auflöst, und kriegt plötzlich als Antwort "mein.rootserver.net".

Auflösung von domain1.de --->ergibt---> 1.2.3.4
Auflösung von 1.2.3.4 --->ergibt--->mein.rootserver.net

domain1.de<>mein.rootserver.net (also ungleich), die Verbindung wird rejected.


Oder hab ich 'nen Denkfehler soweit?
 

danton

Debian User
Kleiner Denkfehler, du brauchst nur einen mail A-Eintrag, nämlich den für die Hauptdomain des Servers, also
mail.deinedomain.de A 1.2.3.4
bzw. umgekehrt:
1.2.3.4 PTR mail.deinedomain.de
Dann MX-Einträge für die verschiedenen Kundendomains:
kunde1.de MX mail.deinedomain.de (und nicht mail.kunde1.de)
kunde2.de MX mail.deinedomain.de
usw.
Netter Nebeneffekt: Wenn du den Mailserver mal auf einen anderen Server umziehst, brauchst du für Mail nur die IP von mail.deinedomain.de ändern und schon kommen alle Mails zur neuen IP.
Dann konfigurierst du noch einen SMTP-Daemon (Postfix, QMail, Exim, etc.) so, daß dieser sich im HELO auch als mail.deinedomain.de meldet.
Der Mailserver wird also gar nicht unter der Kunden-Domain betrieben, sondern unter der Domain der Betreibers (also deiner).
Verabschiede dich von dem Gedanken, daß der Domain-Part der E-Mail-Adresse zur Domain des MX-Eintrages passen muß.
Mailserver meldet sich als mail.deinedomain.de von der IP 1.2.3.4, die IP läßt sich zu mail.deinedomain.de auflösen und umgekehrt und hat keinen generischen (d.h. lange Ziffernfolgen enthaltenden) Charakter. Damit ist alles OK.
 
Last edited by a moderator:

Huschi

Moderator
Staff member
kunde1.de MX mail.deinedomain.de (und nicht mail.kunde1.de)
Es ist relativ egal auf welche Domain der MX zeigt. Es muss auch nicht der Hostname des Servers sein. Denn der MX-Record der versendenden Domain war bisher für niemanden interessant. Lediglich der MX-Record der empfangenden Domain wird ausgelesen um eine IP zu ermitteln.

Evtl. ist wahrscheinlich einigen unklar was der häufiger benannte HELO-String ist.
Dafür schauen wir uns eine SMTP-Sitzung an. Wenn Euer Server eine Email versendet, steht neben HELO der Euer Hostname. Und dieser wird von dem anderen Server per Reverse-PTR überprüft. Dies ist nur eine kleine Prüfung ob der einliefernde Server auch wirklich der ist, für den er sich ausgibt.

huschi.
 

danton

Debian User
Denn der MX-Record der versendenden Domain war bisher für niemanden interessant.
Ich könnte mit vorstellen, daß einige punktebasierte System da schon drauf schauen (einige Mail-Anbieter haben schon recht seltsame Policys). Aber prinzipiell ist es schon egal. Allerdings hat meine Methode durchaus Vorteile, einen hatte ich ja schon genannt.
 

Huschi

Moderator
Staff member
Minus-Punkte gibt es für Absenderdomains ohne (oder ohne gültigen) MX.
Der wirklich Vorteil den Hostnamen als MX einzutragen ist, wenn man ein (ordentliches!) Zertifikat für TLS verwendet. Denn das ist dann nur auf eine Domain ausgestellt. Wird aber bei jedem Kontakt angeboten.
Das Schlimmste was aber in dem Fall (MX != Zertifikats-Domain) passieren kann ist, dass die Daten nicht verschlüsselt übertragen werden.

huschi.
 

pangu

New Member
Vielen Dank an Alle. Hab das gelöst und funzt auch einwandfrei.

@dante: ja, so geht's natürlich auch. Aber aus kosmetischen Gründen :D möchte ich für jede Kundendomain einen mail.kundendomain.de verwenden, deswegen habe ich das auch so im DNS eingetragen, und beibehalten.

Der ausschlaggebende Punkt ist wirklich das von Huschi angesprochene:
letztendlich versendet meine MTA alle Mails der Kundendomains. Der Sender ist also IP 1.2.3.4 und hat den Domainnamen meinedomain.de und der PTR für 1.2.3.4 zeigt auf meinedomain.de somit ist alles gültig.

Ich dachte anfangs, dass die Gegenstelle-MTAs anhand des "MAIL FROM" oder "RETURN-PATH" den Domainursprung prüfen, aber das interessiert sie gar nicht. Was für die MTAs wichtig ist, ist von WELCHER IP die Verbindung stattfindet, und das ist in diesem Falle eben die 1.2.3.4 (meinedomain.de).

:rolleyes:

grüße
 
Top