Workaround für Mails an Adressen bei Microsoft (@hotmail.com, @live.com, @outlook.com etc.)

    Das leidige Thema dürfte bekannt sein: wenn man einen eigenen Mailserver betreibt, ist die Chance hoch, dass Mails an Adressen bei Microsoft entweder direkt abgelehnt werden (mit der bekannten "S3150" Fehlernummer) oder sie kommen einfach nie an ("Blackholing").


    Was privat schon höchst lästig ist, ist für Betreiber von Online-Shops, Foren etc. absolut untragbar. Faktisch müsste man Kunden darauf hinweisen, dass sie bitte keine Adresse von Microsoft benutzen sollen, weil nicht sichergestellt werden kann, dass E-Mails an @hotmail.com, @live.com, @outlook.com etc. überhaupt ankommen. Das ist aber auch ein erheblicher Wettbewerbsnachteil - denn welcher Kunde wird sich nur für eine Bestellung eine andere E-Mail-Adresse anlegen? Und das Verständnis, dass das Problem bei Microsoft liegt, dürfte auch nur schwer vermittelbar sein.


    Es gibt aber einen Workaround - man nutzt einen externen SMTP-Anbieter. Das geht bei Postfix auch völlig transparent und individuell nur für einzelne Domains. Ich betreibe das aktuell erfolgreich mit einem Anbieter aus Frankreich, bei dem man dauerhaft kostenlos 300 Mails pro Tag senden kann und wo die Zustellung bislang völlig problemlos war. Da der Anbieter eine Freischaltung per Mobilfunknummer und zugesendetem Code via SMS verlangt, kann er im Gegenzug auch zusichern, auch an Hotmail & Co. zuverlässig zuzustellen, da er bei Firmen wie Microsoft auch eine hohe Reputation als Absender hat. Bei dem fraglichen Anbieter gibt es ab ca. 20 EUR auch deutlich größere Volumen von 40000 Mails pro Monat ohne tägliches Limit. Für Online-Shops sicher eine bezahlbare Lösung, wenn nötig.


    Die Vorgehensweise:


    1) Man erstellt eine Transport Map für Postfix in /etc/postfix/transport mit folgendem Inhalt:


    live.com smtp:smtp-relay.xxxx.com:587

    hotmail.com smtp:smtp-relay.xxxx.com:587

    outlook.com smtp:smtp-relay.xxxx.com:587


    Statt smtp-relay.xxxx.com gibt man den Namen des Mailservers des Anbieters an. Port 587 ist Standard für SMTP-Einlieferung, aber ggf. sollte man beim Anbieter nachsehen, was er dort haben will.


    Wenn man weitere Empfängerdomains so behandeln will, fügt man diese entsprechend zusätzlich ein.


    Aus Datei wird nun wie folgt in das benötigte Binärformat erzeugt:


    postmap /etc/postfix/transport


    2) Postfix muss sich beim externen SMTP-Sever auch anmelden mit Benutzername/Passwort. Dafür legt man eine Datei /etc/postfix/sasl/sasl_passwd mit folgendem Inhalt an:


    smtp-relay.xxxx.com:587 USERNAME:PASSWORT


    Statt smtp-relay.xxxx.com wird wieder der Servername wie in Schritt 1 angegeben und USERNAME und PASSWORT entsprechend den Kontodaten beim Anbieter.


    Auch von dieser Datei wieder in das Binärformat erzeugen:


    postmap /etc/postfix/sasl/sasl_passwd


    3) Nun muss Postfix noch passend konfiguriert werden. Dazu in /etc/postfix/main.cf folgende Einträge ergänzen:


    smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd

    smtp_sasl_tls_security_options = noanonymous

    smtp_sasl_auth_enable = yes

    transport_maps = hash:/etc/postfix/transport


    Falls transport_maps bereits Angaben enthält, einfach hash:/etc/postfix/transport am Anfang ergänzen (z.B. transport_maps = hash:/etc/postfix/transport, hash:/var/lib/mailman/data/transport-mailman, proxy:mysql:/etc/postfix/mysql-virtual_transports.cf).


    4) Postfix neu starten


    Nun sollten alle E-Mails, die an @hotmail.com, @live.com und @outlook.com gehen, über den externen SMTP-Server geschickt werden, der Rest geht weiterhin direkt an den zuständigen MX. Für die Nutzer des Mailservers ändert sich nichts und auch bei den Empfängern kommen die Mails genauso an, als wären sie direkt zugestellt worden. Nur an den Headern kann man erkennen, dass ein anderer Server als Relay verwendet wurde.

    Sehr schön .:)

    (Ich lasse ja meine Postfixe alle generell über einen externen SMTP-Mailer verschicken)


    Eine Ergänzung noch und eine Frage (an alle)


    Ergänzung:

    Falls der SMTP-Anbieter Wrappermode verwendet. (Meist dann über Port 465), dann braucht es noch zwei zusätzliche Einträge in der main.cf:

    smtp_tls_wrappermode = yes

    smtp_tls_security_level = encrypt

    Ansonsten klappt der Versand nicht und das logfile enthält dann den entsprechenden Hinweis.


    Frage (wollte ich hier im Forum schon lange mal fragen, habs mich aber nie getraut ;):(

    Welche eMail-Anbieter haben denn eine entsprechend gute Reputation und eignen sich dafür gut?

    Quote from aRaphael

    (...)

    Frage (wollte ich hier im Forum schon lange mal fragen, habs mich aber nie getraut ;):(

    Welche eMail-Anbieter haben denn eine entsprechend gute Reputation und eignen sich dafür gut?


    Die Nennung von eMail-Anbietern würde gegen die Forenregeln verstoßen. Siehe auch https://forum.netcup.de/system/disclaimer/:


    Bitte haben Sie dafür Verständnis, dass Namen von Mitbewerbern der netcup GmbH nicht in diesem Forum genannt werden dürfen. Dieses Forum dient alleine den Dienstleistungen der netcup GmbH.

    Auf Wunsch gebe ich dazu aber gerne privat Auskunft. Meine Adresse finde sich im Impressum meiner Website: https://arnowelzel.de/ueber-mich

    Moin,


    ich mutmaße mal das dein Anbieter Mailjet (Ich nehme mir raus den Anbieter zu nennen da dieser Geschäftsfelder bedient welche netcup nicht beinhaltet, somit sollte das kein Problem darstellen) ist.


    Wie handhaben die das bei den kostenlosen Plänen mit den AD Verträgen?

    Hast du mit denen einen abgeschlossen?

    Informierst du deine Kunden darüber das der Mailverkehr über einen weiteren zusätzlichen Service gehandhabt wird?


    Kannst du inhaltliche Veränderungen deiner Emails feststellen?

    Ich beziehe mich mit der Frage auf meinen Testlauf mit Sendgrid (Ich nehme mir raus den Anbieter zu nennen da dieser Geschäftsfelder bedient welche netcup nicht beinhaltet, somit sollte das kein Problem darstellen).

    Dabei stelle sich heraus das, trotz deaktivierter Funktionen, jegliche Links umgebaut wurden zu Trackinglinks.

    Genauso wurde auch ein übermittelter PGP Schlüssel verändert.


    Kostenlos gibt es ja nicht wirklich, dann bezahlt man eben mit den Daten die man denen zur Verfügung stellt.

    Genau da hätte ich dann zweifel bzgl. der DSGVO ob das alles noch so konform ist.


    Danke :)


    Ja, die Vermutung bzgl. des Anbieters ist korrekt. Ich muss mich auch korrigieren: kostenlos sind es nur 200 Mails pro Tag und 6000 im Monat und der kleinste kostenpflichtige Tarif geht bei ca. 7 EUR los.


    Momentan genügt der kostenlose Plan, weil ich das ausschliesslich für E-Mail-Adressen @hotmail.com, @live.com, @outlook.com nutze und da kommen nur ca. 100 pro Woche zusmmen.


    Reine Text-E-Mails via SMTP werden auch inhaltlich nicht verändert, einzig die Header werden natürlich angepasst, speziell kommt ein Sender-Header dazu und eine eigene DKIM-Signatur von deren Server. Bei HTML-Mails kommt aber auch hier ein Tracking-Pixel dazu und die Links werden auch umgeschrieben auf einen eigenen Server, der dann auf den eigentlichen Link weiterleitet.


    Und ja, meine Nutzer habe ich selbstverständlich darüber informiert. Denen ist das so lieber, als wenn Mails an Microsoft-Adressen gar nicht ankommen.





    Ergänzung:


    Man kann Tracking komplett ausschalten, wenn man folgende Header in der Mail einfügt, bevor sie an den Server von MJ geschickt wird:

    Code
    X-Mailjet-TrackOpen: 0
X-Mailjet-TrackClick: 0

    Das geht bei Postfix etwa mit folgenden Angaben in den header_checks:

    Code
    /^From:/i PREPEND X-Mailjet-TrackOpen: 0
/^To:/i PREPEND X-Mailjet-TrackClick: 0

    Die Header werden von MJ dann entfernt und die Mail ansonsten unverändert weitergeleitet - also ohne Tracking-Pixel und ohne veränderte Links.


    Ich muss aber noch einen Weg finden, wie ich das etwas eleganter lösen kann, dass das nur für die Domains passiert, für die MJ für den Versand benutzt wird.

    Quote from Askaaron

    [...] weil ich das ausschliesslich für E-Mail-Adressen @hotmail.com, @live.com, @outlook.com nutze [...]

    Damit hast du aber nur einen Bruchteil der Domains abgedeckt. Spontan fallen mir da noch hotmail.de, live.de, msn.com, usw. ein. Nicht zu vergessen die ganzen aufgeschalteten Domains.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Quote from Virinum

    Damit hast du aber nur einen Bruchteil der Domains abgedeckt. Spontan fallen mir da noch hotmail.de, live.de, msn.com, usw. ein. Nicht zu vergessen die ganzen aufgeschalteten Domains.

    Die kann man ja leicht ergänzen, wenn nötig. Bisher war das bei mir nicht erforderlich. Aufgeschaltete Domains haben Mails akzeptiert, auch wenn sie bei hotmail.com oder live.com gesperrt waren.

    Quote from Askaaron

    Ich muss aber noch einen Weg finden, wie ich das etwas eleganter lösen kann, dass das nur für die Domains passiert, für die MJ für den Versand benutzt wird.


    Ergänzung:


    Man kann Tracking komplett ausschalten, wenn man folgende Header in der Mail einfügt, bevor sie an den Server von MJ geschickt wird:

    Code
    X-Mailjet-TrackOpen: 0
X-Mailjet-TrackClick: 0


    Manchmal muss man sich auch das Brett vor den Augen wegnehmen... zusätzliche Header sind nicht nötig!


    Das kann man auch einfach bei Mailjet in den Konto-Einstellungen ändern, dann werden in HTML-Mails auch keine Tracking-Pixel eingefügt und Links bleiben auch unverändert:

    pasted-from-clipboard.png

    Quote from Caspar

    Kostenlos gibt es ja nicht wirklich, dann bezahlt man eben mit den Daten die man denen zur Verfügung stellt.

    Genau da hätte ich dann zweifel bzgl. der DSGVO ob das alles noch so konform ist.


    Kostenlos ist es ja nur für eine begrenzte Menge an E-Mails. Darüber hinaus verlangen die durchaus Geld.


    Bezgl. "Daten die man denen zur Verfügung stellt" - das tut man bei jedem anderen Mailserver-Anbieter ebenso, auch bei einem gemieteten Webspace mit E-Mail-Postfächern dabei. Auch da bekommt der Anbieter genau mit, wem man E-Mails schickt.

    Wenn mans nicht schafft, E-Mails an Microsoft Postfächer zuzustellen, dann sollte man einfach keinen eigenen Mailserver für den Versand verwenden. Weder für private Mails, noch für Business, noch für e-Commerce oder sonst irgendwas. Das Problem mit der Zustellrate ist ein weithin bekanntes, wer das auf die leichte Schulter nimmt, und einfach mal nur annimmt, dass nur Microsoft so heikel ist, der sieht nur einen Bruchteil des Gesamtbilds, und verliert im e-Commerce laufend Geld - sofern das Geschäftsmodell den Empfang von E-Mails benötigt.


    E-Mails aus Webshops und anderen Tools fallen üblicherweise unter "transaktionale E-Mails". Mailjet ist einer der Anbieter für transaktionale E-Mails. Ich selbst hab bessere Erfahrung mit Postmark. Und da würd ich keinesfalls nach Empfänger trennen, sondern die Vorteile eines solchen auf hohe Zustellrate spezialisierte Dienstes für ALLE Empfänger nutzen. Dazu kommt dann auch noch, den Inhalt der E-Mails zu analysieren, zum Beispiel mit Tools wie https://www.mail-tester.com/. Geht man bei E-Mails nicht den ganzen Weg, dann machts leider überhaupt keinen Sinn, auch nur damit anzufangen.

    Quote from sensorback

    Wenn mans nicht schafft, E-Mails an Microsoft Postfächer zuzustellen, dann sollte man einfach keinen eigenen Mailserver für den Versand verwenden. Weder für private Mails, noch für Business, noch für e-Commerce oder sonst irgendwas. Das Problem mit der Zustellrate ist ein weithin bekanntes, wer das auf die leichte Schulter nimmt, und einfach mal nur annimmt, dass nur Microsoft so heikel ist, der sieht nur einen Bruchteil des Gesamtbilds, und verliert im e-Commerce laufend Geld - sofern das Geschäftsmodell den Empfang von E-Mails benötigt.


    E-Mails aus Webshops und anderen Tools fallen üblicherweise unter "transaktionale E-Mails". Mailjet ist einer der Anbieter für transaktionale E-Mails. Ich selbst hab bessere Erfahrung mit Postmark. Und da würd ich keinesfalls nach Empfänger trennen, sondern die Vorteile eines solchen auf hohe Zustellrate spezialisierte Dienstes für ALLE Empfänger nutzen. Dazu kommt dann auch noch, den Inhalt der E-Mails zu analysieren, zum Beispiel mit Tools wie https://www.mail-tester.com/. Geht man bei E-Mails nicht den ganzen Weg, dann machts leider überhaupt keinen Sinn, auch nur damit anzufangen.


    In meinem Fall ist der Server schon mehrere Jahre völlig problemlos im Einsatz und seit Inbetriebnahme nie auf Blacklists gelandet.


    mail-tester.com zeigt 10/10, ich habe SPF, DKIM, DMARC und ich habe mit keinem einzigen Provider Probeme bis auf Microsoft - auch bei GMail kommt alles an, was direkt von meinem Server kommt.


    Nur Microsoft sperrt halt regelmäßig ganze Blöcke, so dass man auch dann Probleme bekommt, wenn irgend ein anderer Server im selben Netzblock Probleme hat.


    Postmark sitzt in den USA, Mailjet nicht. Ich würde ohne Not sicher nicht meinen kompletten ausgehenden E-Mail-Verkehr über einen Anbieter in den USA routen.

    Ist schon klar, dass das Problem in den USA sitzt. Aber es hilft dir im kommerziellen Bereich halt nicht. Die Mails kommen nicht an, die Kunden sind sauer oder weg. Im Privatbereich sehe ich das durchaus anders.

    Quote from sensorback

    Wenn mans nicht schafft, E-Mails an Microsoft Postfächer zuzustellen, dann sollte man einfach keinen eigenen Mailserver für den Versand verwenden. Weder für private Mails, noch für Business, noch für e-Commerce oder sonst irgendwas.

    Mit E-Mail lässt sich nur leider kein Geld verdienen und die Kunden haben auch keine Ahnung von der Materie.

    Vor 5 Jahren führen hier die Handwerker-Autos herum mit "Web: handwerker-example.net E-Mail: handwerker-example@magentix-online.de".

    Die Großen machen es halt gratis, weil Daten = Geld.


    E-Mail und Internet sind speziell dezentral aufgebaut und wenn sich alle an die Regeln halten, funktioniert das auch.

    Das Internet hat ja gerade so einen Erfolg, weil es dezentral aufgebaut.


    Nur versuchen einige Konzerne die Anzahl der Anbieter zu reduzieren, damit E-Mail ein quasi zentrales System wird.

    Genau soetwas erreicht man nämlich, wenn man Marktteilnehmer diskriminiert. Und dem sollte man sich nicht beugen.


    Blackholing ist Diskriminierung. Und warum Monopole und Quasi-Monopole nicht so geil sind, muss ich hoffentlich nicht erklären.


    Früher gab es mal einen netten Grundsatz, der hoch gelobt wurde: Netzneutralität.

    Packete sollen nicht anhand ihrer Metadaten diskriminiert werden. SRC-IP ist ein Metadatum.


    Wer solche Grundsätze über Bord wirft und diese Einschränkung seiner Freiheit hinnimmt, der nimmt die Folgen auf die leichte Schulter und sieht das Gesamtbild nicht. eCommerce hin oder her. Für kein Geld der Welt sollten wir unsere offene und freie Welt verkaufen.

    Die Mitbegründer des Internets würden sich an den Kopf fassen.

    Quote from Virinum

    Damit hast du aber nur einen Bruchteil der Domains abgedeckt. Spontan fallen mir da noch hotmail.de, live.de, msn.com, usw. ein. Nicht zu vergessen die ganzen aufgeschalteten Domains.

    outlook.com, outlook.org, outlook.co, outlook.eu, outlook.de, live.com, live.co.uk, live.net, live.org, live.eu, live.de, hotmail.com, hotmail.co.uk, hotmail.eu, hotmail.co, hotmail.net, hotmail.org

    (sind schonmal die, die ich kenne)

    Quote from H6G

    Früher gab es mal einen netten Grundsatz, der hoch gelobt wurde: Netzneutralität.

    Packete sollen nicht anhand ihrer Metadaten diskriminiert werden. SRC-IP ist ein Metadatum.

    RBLs und Dailin Ranges fallen hier aber ebenso drunter und hier hat es sich schon ein wenig bewährt, in einem größeren Ganzen generell zu blocken - ich möchte damit nur sagen, dass es generell nicht verwerflich ist, Mails anhand ihrer SRC-IP direkt zu verwerfen, wenn ich bei der Verbindung des gegnerischen MTAs bereits weiß, dass es Mist ist.

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

    Alles klar, nieder mit allen Paketfiltern, haut weg alle Firewalls. Ich geh dann mal schaukeln.

    Quote from douzer

    dass es generell nicht verwerflich ist, Mails anhand ihrer SRC-IP direkt zu verwerfen, wenn ich bei der Verbindung des gegnerischen MTAs bereits weiß, dass es Mist ist.

    Quote from sensorback

    Alles klar, nieder mit allen Paketfiltern, haut weg alle Firewalls. Ich geh dann mal schaukeln.

    Wenn ich weiß, dass da Müll kommt und keine TCP Verbindung bestätige, weiß der sendende Server das - ich schicke ihm kein 250 OK.

    Microsoft schickt mir ein 250 OK und packt die Mail trotzdem direkt in den Müll.


    Das ist ein Unterschied.

    Quote from H6G

    Wenn ich weiß, dass da Müll kommt und keine TCP Verbindung bestätige, weiß der sendende Server das - ich schicke ihm kein 250 OK.

    Microsoft schickt mir ein 250 OK und packt die Mail trotzdem direkt in den Müll.


    Das ist ein Unterschied.

    Naja, bitte nicht nur halbe Sätze zitieren, die dann irgendwie in die Argumentation passen .... ;)

    Die Aussage zur Netzneutralität ziehe ich sehr wohl in Zweifel, da dieser Kontext nichts und auch gar nichts, mit Netzneutralität, geschweige denn mit der Verletzung selbiger zu tun hat.

    Quote from von H6G

    Früher gab es mal einen netten Grundsatz, der hoch gelobt wurde: Netzneutralität.

    Packete sollen nicht anhand ihrer Metadaten diskriminiert werden. SRC-IP ist ein Metadatum.

    Und ich bleibe dabei, dass das nicht annehmen von Mails von klar bekannten Spammern nichts mit einer Verletzung der Netzneutralität zu tun hat .... ;)

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020