Managed Server / Telekom Mail BL

    Hallo netcup Forum,

    da ich mich vergangene Woche mit dem Thema managed Server und dem Telekom E-Mail Engineering Team auseinandersetzen durfte und dazu im Forum nichts gefunden hab, dachte ich, ich teile mich einfach mal mit. Ich nutze von Netcup den managed private Server. Dieser läuft flott und rund :), soweit so gut. Vergangene Woche wurde ich von einem Kunden darauf aufmerksam gemacht, dass er seine Mails (Weiterleitung von einem Wordpress-Kontaktformular ... ihr seht schon ...) nicht mehr auf seiner t-online Adresse bekommt. Keine Fehlermeldung, die Mails werden einfach verworfen.


    Nach Rücksprache mit der Telekom hat man mich darauf aufmerksam gemacht, dass der PTR nicht passt. Telekom lehnt Mails von generischen Hostnamen ab. Kein Ding - der Support bei Netcup (nur dieser kann PTR für managed setzen) hat mir sofort geholfen, Record gesetzt. Die DNS-Höflichkeits-48h gewartet (testen könnt ihr das zBsp hier: http://multirbl.valli.org/fcrdns-test/), Telekom lehnt Verbindungsaufbau immer noch ab, sieht dann so aus :


    -bash-4.4$ telnet 194.25.134.8 25

    Trying 194.25.134.8...

    Connected to 194.25.134.8.

    Escape character is '^]'.

    554 IP=x.x.x.x - A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.) (BL)

    Connection closed by foreign host.


    Nächste Beanstandung war ein fehlender MX für den sendenden Host. Heißt, wenn ihr von my.ptr.example.com Mails senden wollt, brauch example.com einen MX Eintrag auf den managed.

    Soweit konnte auch das geregelt werden. Das Telekom-Team hat den Server anschließend auch von der BL genommen, sieht dann so aus:


    -bash-4.4$ telnet 194.25.134.8 25

    Trying 194.25.134.8...

    Connected to 194.25.134.8.

    Escape character is '^]'.

    220-mailin87.aul.t-online.de T-Online ESMTP receiver fssmtpd2025 ready.

    220 T-Online ESMTP receiver ready.

    Connection closed by foreign host.


    Mich aber erst jetzt auf den Grund der Sperrung aufmerksam gemacht - Spam aus dem Kontaktformular. Und gleich die Handlungsempfehlung mitgegeben, keine Weiterleitung von E-Mail-Adressen, welche dem Empfang von Daten aus dem Kontaktformular dienen, sondern dafür eigenes Postfach nutzen. Macht irgendwie auch Sinn, verinnerlicht hatte ich es bis dato nicht.


    Zusammengefasst, damit man Freund mit T-Online wird, braucht man abseits der netcup Standardkonfiguration: PTR auf den managed, zsbp. mail.example.com und für example.com einen MX auf den managed.


    Abschließend kam noch die Frage auf, wenn ich auf dem managed unterschiedliche Domains hoste, setze ich bei diesen den MX auf mail.example.com oder besser MX für mail.anderedomain.de? Tendenziell würde ich Ersteres nehmen.

    Quote from michael123

    Abschließend kam noch die Frage auf, wenn ich auf dem managed unterschiedliche Domains hoste, setze ich bei diesen den MX auf mail.example.com oder besser MX für mail.anderedomain.de? Tendenziell würde ich Ersteres nehmen.

    Moin,

    der MX Record ist Pflicht - ohne den geht quasi garnichts. Er zeigt, welcher Mailserver zu einer Domain gehört.


    Der MX Record jeder Domain, welche auf deinem Server gehostet wird, muss auf den FQDN deines Servers zeigen. Für den FQDN sollte man selbstverständlich die DNS Einträge und die dazu passenden rDNS Einträge (PTR) gesetzt haben



    Nehmen wir mal an, dein Server trägt den Hostname "manserver" und deine domain ist "bli.de". Zusätzlich hostest du für deine Kunden die Domain "bla.de" und "blub.de" darauf. Deine IPv4 ist "1.2.3.4" und deine IPv6 ist "2001:affe:beef:1ce::1".


    Bei der Domain "bli.de" hast du:

    Code
    manserver IN A 1.2.3.4
manserver IN AAAA 2001:affe:beef:1ce::1
@ IN MX 10 manserver.bli.de


    Und bei "bla.de" und "blub.de":

    Code
    @ IN MX 10 manserver.bli.de



    So viel dazu - ich sag nur: kein Wunder, dass das nicht funktioniert hat. Ich rate dir noch, dich mit SPF und DMARC auseinanderzusetzen. Viele Mailserver lehnen auch Mails von Domains ab, die keinen SPF Record besitzen. Und das völlig zurecht.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from H6G

    Kauft man sich nicht eine Managed Dienstleistung, damit man sich damit nicht auseinandersetzten muss?

    Grenzwertige Sache...

    An sich ist die Domain, die extern davon läuft, nicht davon betroffen, weil die nicht als managed verkauft wird.



    Allerdings könnte man es von einem Provider, welcher selbst seine unmanaged Produkte besser als die mit SLA Gold plattformbetriebsgeführten Produkte von Enterprise IT Unternehmen einschätzt, durchaus erwarten. Aber Zeit für Kunden investieren passt halt nicht in Netcups Business Case. :P

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from whoami0501

    So viel dazu - ich sag nur: kein Wunder, dass das nicht funktioniert hat. Ich rate dir noch, dich mit SPF und DMARC auseinanderzusetzen. Viele Mailserver lehnen auch Mails von Domains ab, die keinen SPF Record besitzen. Und das völlig zurecht.

    Danke für deine Erläuterung und Kritik - ist auf der Agenda


    Quote from H6G

    Kauft man sich nicht eine Managed Dienstleistung, damit man sich damit nicht auseinandersetzten muss?

    Hmm, das DNS sehe ich jetzt nicht beim managed. Ich hätte mir einen Arbeitsgang sparen können, und dem Support auch, gäbe es wie bei den vServern die Möglichkeit den rdns selbst zu setzen.

    Quote from michael123

    Hmm, das DNS sehe ich jetzt nicht beim managed. Ich hätte mir einen Arbeitsgang sparen können, und dem Support auch, gäbe es wie bei den vServern die Möglichkeit den rdns selbst zu setzen.

    Du musst aber davon ausgehen, dass die Zielgruppe der managed Server nicht so pfiffig sind wie du und da dann in den meisten Fällen eher wer dran rumschraubt und die Mails dann nicht mehr gehen. Und damit hätte Netcup weitaus mehr Arbeit, dass alles grade zu biegen. ;)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Quote from michael123

    Hmm, das DNS sehe ich jetzt nicht beim managed.

    Naja, es kann dir ja vorgeschlagen werden: Lieber Kunde, setze folgende DNS Einträge - und das kann ebenso überprüft werden, ob die Einträge funktional sind.

    Ich gehe nicht davon aus, dass sich jmd. einen entsprechenden Server anschafft und großartig lust darauf hat, sich noch mit den Dingen zu beschäftigen.


    Da wird man bei Cloudron besser an die Hand genommen.