Beiträge von marcweb

Hallo zusammen,

ich betreue unter anderem einige Mailcow-Groupware-Server für Kunden und stoße bei der Einrichtung unter Windows immer wieder auf dieselben Hürden - insbesondere mit den neueren Outlook-Versionen. Die automatische Einrichtung via ActiveSync funktioniert nicht mehr, da Microsoft alles nur noch über eigene Cloud-Dienste schleust. Auch Tools wie CalDav Synchronizer laufen zwar prinzipiell, sind aber auf Dauer umständlich in der Handhabung und Wartung.

Thunderbird macht es da deutlich besser: E-Mail-Adresse und Passwort eingeben - und in den meisten Fällen läuft alles. Leider schreckt die Oberfläche viele meiner Kunden ab, da sie eher an Outlook gewöhnt sind oder „etwas Moderneres“ erwarten.

Ich habe mir nun testweise den eM Client angeschaut - Einrichtung klappt dort sehr gut, CalDAV/CardDAV wird automatisch erkannt und eingebunden. Zudem gibt es ein Partnerprogramm, über das man Lizenzen an Kunden weitergeben kann - für mich als Dienstleister natürlich interessant.

Mich würde interessieren:

• Welche Clients nutzt ihr bei euch oder bei Kunden?

• Gibt es weitere empfehlenswerte Alternativen zu Outlook/eM Client unter Windows?

Bin gespannt auf eure Erfahrungen!

Viele Grüße

Marc

Zitat von Olivetti

Darf jeder einrichten, wie er mag… Deswegen habe ich ja den offiziellen »Tweak-Link« beigefügt.

Niemand hat deiner Aussage widersprochen – selbstverständlich kann jeder die Konfiguration so vornehmen, wie es für ihn am besten passt. Ich wollte lediglich den Fragesteller darauf hinweisen, dass es eben auch die Möglichkeit gibt über die GUI das externe Mailrelay umzusetzen. Das war ja auch die eigentliche Frage von ihm, er möchte seinen externen Verkehr über ein Relay leiten - der "Tweak" ist ja wieder ein Sonderfall wenn man nur E-Mails an bestimmte Adressaten (z.B. Outlook Adressen, etc.) über das Relay schicken will.

Zitat von Homwer

Meine MailCow dient zu 99% nur als Empfänger für digitale Post.

Wäre es möglich einen der großen Relay anbieter für ausgehende Mails zu nutzen und so deren Reputation zu nutzen um sicherzustellen, dass Mails ankommen?

Siehe einige Beiträge von mir weiter oben:

bzw.

Zitat von Olivetti

siehe #38 (2 posts über deinem) und https://docs.mailcow.email/de/manual-guid…stom_transport/

Die Lösung von aRaphael ist natürlich auch eine Lösung, wobei ich nicht der größte Fan solcher Tweaks in den Mailcow Containern bin, wie aRaphael ja auch selbst geschrieben hat in seinem Beitrag. Da bleibe ich persönlich dann bei der Transport Map in der GUI für den kompletten ausgehenden E-Mail Verkehr der jeweiligen E-Mail. Damit sozusagen alles über das große Relay läuft und nicht nur E-Mails an bestimmte Adressaten.

Zitat von VeePay

Die 3x 5* bringen dir leider auch nichts, wenn die IP Reputation grottig ist und die großen Provider deine Mails ablehnen.

Hatte ebenfalls eine Mailcow am laufen und 3x 5*. Dennoch stellte der magenta Verein keine einzige Mail zu. Als privater, der max 1-2 Mails/Monat verschickt und sonst nur Mails empfängt lohnt sich das somit nicht, da so nie eine gute Reputation zustande kommt. Auch das freischalten ist dann ohne eigene Page + Impressum nicht so leicht möglich.

Zitat von marcweb

Da stimme ich dir zu. Beim Magenta-Verein hatte ich persönlich allerdings keine größeren Schwierigkeiten. Die IP-Adressen meiner beiden MX-Server waren damals zwar aufgrund des Vorbesitzers zunächst auf einer Blacklist gelandet, aber nach einer freundlichen E-Mail an die in der EHLO-Nachricht angegebene Adresse wurde das Problem schnell und unkompliziert behoben. In dieser Hinsicht habe ich mit anderen Anbietern deutlich schlechtere Erfahrungen gemacht. Da die Mailserver aller meiner (Business)Kunden hinter meinen beiden MX-Servern laufen, ist das Thema IP-Reputation für mich vermutlich weniger kritisch, da dort doch ein paar mehr Mails laufen.

Eine mögliche Lösung für dieses Problem wäre die Nutzung eines SMTP-Anbieters, der SMTP-Relays bereitstellt. Diese sollten sich z.B. Mailcow als ausgehender Server einbinden lassen. Es gibt beispielsweise einen großen Anbieter, bei dem monatlich bis zu 3.000 E-Mails kostenlos versendet werden können – ein Kontingent, das für private Anwender in der Regel mehr als ausreichend sein sollte, selbst wenn z.B. mehrere Familienmitglieder den Dienst gemeinsam nutzen.

Das werde ich mir auf jeden auch mal Fall genauer ansehen, da diese Lösung insbesondere für den großflächigen Versand von Newslettern interessant sein könnte. Auf diese Weise ließe sich vermeiden, dass meine eigenen MX-Server durch hohe Versandvolumina negativ belastet oder in ihrer Reputation beeinträchtigt werden. Mailcow bietet ja erfreulicherweise die Möglichkeit, für einzelne E-Mail-Adressen eigene ausgehende SMTP-Server zu definieren, was in diesem Zusammenhang besonders hilfreich ist.

Ich habe das Ganze testweise umgesetzt und muss sagen, dass es eine durchaus praxistaugliche Lösung darstellt. Zur Vereinfachung habe ich Mailcow verwendet und eine Transport Map angelegt, die die SMTP-Zugangsdaten eines externen Anbieters verwendet. Bei diesem Anbieter ist es erforderlich, ein Konto zu erstellen und die eigene Domain mit allen notwendigen DNS-Einträgen zu hinterlegen.

In den Maileinstellungen von Mailcow habe ich bei den gewünschten Absenderadressen die entsprechende Transport Map hinterlegt. So werden ausgehende E-Mails über die Infrastruktur des großen Anbieters mit guter Reputation versendet, während eingehende Mails weiterhin über die eigene Infrastruktur empfangen werden. Dadurch nutzt man gezielt nur den Versand über eine etablierte Plattform, kann aber seinen eigenen Server betreiben, ohne sich um Themen wie IP-Reputation oder Blacklisting kümmern zu müssen.

Um die Qualität dieser Konfiguration zu überprüfen, habe ich zusätzlich einen MECSA-Check durchgeführt – mit voller Punktzahl als Ergebnis. Auch mit dieser Konstellation erfüllt das System alle gängigen Sicherheits- und Zustellbarkeitsanforderungen.

Gerade für Privatpersonen oder kleinere Unternehmen ist das eine interessante Option. Viele Anbieter bieten ein Freikontingent von etwa 100 bis 3.000 E-Mails pro Monat, was in vielen Fällen ausreichen dürfte. Selbst die kleineren kostenpflichtigen Tarife sind meist erschwinglich.

Zusätzlich bieten viele dieser Anbieter weitere Funktionen wie Tracking-Optionen (z. B. Öffnungsraten, Klickverhalten, Unsubscribe-Header). Diese Funktionen sind vor allem im Newsletter-Bereich relevant. Aus Datenschutzsicht ist hierbei jedoch zu beachten, dass Tracking-Elemente nur dann zulässig sind, wenn die Empfänger explizit eingewilligt haben (z. B. durch Anmeldung zu einem Newsletter). Für die private Nutzung lassen sich diese Funktionen jedoch meist deaktivieren oder ungenutzt lassen.

Zitat von VeePay

Die 3x 5* bringen dir leider auch nichts, wenn die IP Reputation grottig ist und die großen Provider deine Mails ablehnen.

Hatte ebenfalls eine Mailcow am laufen und 3x 5*. Dennoch stellte der magenta Verein keine einzige Mail zu. Als privater, der max 1-2 Mails/Monat verschickt und sonst nur Mails empfängt lohnt sich das somit nicht, da so nie eine gute Reputation zustande kommt. Auch das freischalten ist dann ohne eigene Page + Impressum nicht so leicht möglich.

Da stimme ich dir zu. Beim Magenta-Verein hatte ich persönlich allerdings keine größeren Schwierigkeiten. Die IP-Adressen meiner beiden MX-Server waren damals zwar aufgrund des Vorbesitzers zunächst auf einer Blacklist gelandet, aber nach einer freundlichen E-Mail an die in der EHLO-Nachricht angegebene Adresse wurde das Problem schnell und unkompliziert behoben. In dieser Hinsicht habe ich mit anderen Anbietern deutlich schlechtere Erfahrungen gemacht. Da die Mailserver aller meiner (Business)Kunden hinter meinen beiden MX-Servern laufen, ist das Thema IP-Reputation für mich vermutlich weniger kritisch, da dort doch ein paar mehr Mails laufen.

Eine mögliche Lösung für dieses Problem wäre die Nutzung eines SMTP-Anbieters, der SMTP-Relays bereitstellt. Diese sollten sich z.B. Mailcow als ausgehender Server einbinden lassen. Es gibt beispielsweise einen großen Anbieter, bei dem monatlich bis zu 3.000 E-Mails kostenlos versendet werden können – ein Kontingent, das für private Anwender in der Regel mehr als ausreichend sein sollte, selbst wenn z.B. mehrere Familienmitglieder den Dienst gemeinsam nutzen.

Das werde ich mir auf jeden auch mal Fall genauer ansehen, da diese Lösung insbesondere für den großflächigen Versand von Newslettern interessant sein könnte. Auf diese Weise ließe sich vermeiden, dass meine eigenen MX-Server durch hohe Versandvolumina negativ belastet oder in ihrer Reputation beeinträchtigt werden. Mailcow bietet ja erfreulicherweise die Möglichkeit, für einzelne E-Mail-Adressen eigene ausgehende SMTP-Server zu definieren, was in diesem Zusammenhang besonders hilfreich ist.

Hallo,

zwei Anmerkungen auch meinerseits.

Zitat von finnvweiss

Wenn der Server ausfällt, wie kommst du dann in deinen Account rein wenn du einen 2FA Code zugeschickt bekommen hast?

Also ich bekomme bei Netcup keine Mail für den Login sondern habe das in meiner 2FA App auf dem Handy? Oder habe ich da etwas falsch Verstanden?

Zitat von finnvweiss

pasted-from-clipboard.png

Eigentlich garnicht mehr. Deshalb will ich wechseln.

Nicht sehr übersichtlich und sehr viel Werbung (mache meistens aber eh mit Mail Programm).

Ein weiterer Vorteil von einem eigenen Server mit eigener Domain ist das man bei diesen Tests, wenn man sich ein wenig Mühe gibt und damit beschäftigt dann eben auch solche Werte bekommen kann:

pasted-from-clipboard.png

Und bezüglich der Bedenken, was man tut wenn das Konto gesperrt werden sollte oder etc. Der einfachste und sicherste Weg wird es wohl sein zumindest die Domains mit DNS bei einem anderen Anbieter als den Mailserver liegen zu haben. So könnte man im schlechtesten Fall die DNS Einträge auf einen neuen Mailserver umändern, welchen man sich dann evtl. kurzfristig woanders anmietet oder eben installiert. Anbieter für Domain/DNS gibt es ja einige zur Auswahl manche so spezialisiert, dass Sie sie ja nichts anderes außer das machen.

Bei Fragen gerne melden

LG

Marc

Also ich habe vor ca. 10 Minuten ein Kontaktformular abgesendet und dann nach 2-3 Minuten eine Bestätigung bekommen, dass es angekommen ist.

Mein Mail läuft nicht bei Netcup.

VG

Marc

p0se

Hallo zusammen,

hier meine abschließende Rückmeldung für alle. Zeitgleich zu meinem Test habe ich auch eine Rückmeldung vom Netcup-Support erhalten. Der Support hat sich nach meinem Hinweis auch hier die Diskussion mit angesehen gehabt und darauf Bezug genommen - vielen Dank dafür!

Folgende Erkenntnisse konnte ich heute gewinnen:

Bei Netcup wird beim Versand einer E-Mail tatsächlich der SPF-Eintrag der betreffenden Domain überprüft. Auf Basis dieser Überprüfung wird entschieden, über welches Gateway die E-Mail versendet wird. Wenn der SPF-Eintrag include:_spf.webhosting.systems enthält, erfolgt der Versand über das uns bekannte Gateway relay.yourmailgateway.de.

Der Support wies mich jedoch auch darauf hin, dass derzeit ein Bug existiert. Daher ist es essenziell, dass include:_spf.webhosting.systems nicht an erster Stelle im SPF-Record steht. Ich zitiere dazu aus dem Support-Ticket als Beispiel:

Tatsächlich war mir die Abfrage des SPF-Records in dieser Form bisher nicht bekannt. Mir war bislang nur der direkte Weg geläufig, bei dem das Ziel-Gateway explizit vorgegeben wird - höchstens mit einem Load Balancer dazwischen. Die dynamische Steuerung des Mailversands auf Basis des SPF-Records hatte ich bisher nicht auf dem Schirm, wobei diese Funktionalität natürlich für größere Infrastrukturen wie die von Netcup Sinn macht.

Sobald abschließend die beiden CNAME-Einträge korrekt gesetzt sind, funktioniert auch die DKIM-Signatur vollständig.

Wie bereits gestern berichtet, hatte ich den SPF-Record gemäß der empfohlenen Konfiguration gesetzt. Gestern funktionierte der Versand zwar noch nicht über das richtige Gateway, allerdings lag dies lediglich am Caching der DNS-Einträge, weshalb es bis zu 48 Stunden dauern kann bis der Versand dann richtig läuft.

Nun, nachdem der Eintrag ausreichend lange aktiv war, erfolgt der Versand über das richtige Gateway - und damit funktioniert nun auch die DKIM-Signatur.

Vielen Dank an alle Beteiligten! Nicht nur ist das "Problem" nun erfolgreich behoben, sondern ich denke, wir alle konnten dabei auch etwas Neues dazulernen.

Viele Grüße

Marc

PS.: Tatsächlich wird im Wiki ebenfalls empfohlen, den SPF-Record genau wie oben beschrieben zu setzen. Warum ich ursprünglich meine direkte Reseller-Webhosting-IP eingetragen habe, kann ich gar nicht genau sagen - vermutlich habe ich mich dabei von Empfehlungen aus verschiedenen Mail-Test-Tools leiten lassen. Da ich den SPF-Record bisher nie direkt mit dem Versandweg der E-Mail in Verbindung gebracht habe, habe ich der Vorgabe aus dem Wiki natürlich nicht allzu viel Beachtung geschenkt, zumindest nicht auf dieses Problem bezogen. Definitiv mein Fehler! - Sorry

Zitat von hamilrat

War das mit der Trennung nicht nur bei Privatkunden?` Ich ging beim Webhosting (Reseller) davon aus, das es kein separates Gateway gab.

* Dies kann natürlich eine totale Falschinformation sein.

Da p0se in seinem letzten Beitrag geschrieben hat, dass er sich ein Reseller Webhosting 2000 geholt hat und seine Tests offensichtlich über das Gateway gelaufen sind, würde ich fast behaupten, dass es nicht nur für Privatkunden bzw. normale Webhosting Pakete genutzt wird. Auch bei Lukas läuft alles über das separate Gateway. Nur bei mir irgendwie nicht.

Es wäre ja auch durchaus sinnvoll, dass es über ein zentrales Gateway läuft, denn dann machen diese CNAME DKIM Einträge auch Sinn. Wenn es über jeden Server direkt laufen würde, so wie es bei mir aktuell ist, hätte ja jeder auch eigene/andere Keys, die er verwenden/eintragen müsste.

Tatsächlich habe ich aber mein Reseller Tarif schon mehrere Jahre evtl. hat sich da ja mal etwas geändert und ich wurde vergessen oder so Habe zwischenzeitlich mal ein Support Ticket aufgemacht.

Ich halte euch auf dem laufenden!

Viele Grüße

Marc

Hallo p0se ,

entschuldige, dass ich erst jetzt auf dein erneutes Posting reagiere. Die letzten Tage waren etwas turbulent, und ich bin erst heute dazu gekommen, weiter zu testen und verschiedene Szenarien durchzuspielen.

Dank eines Hinweises von lukbae habe ich meinen SPF-Eintrag überprüft und nicht mehr ausschließlich auf meinen Reseller-Tarif beschränkt, sondern stattdessen auf _spf.webhosting.systems gesetzt.

Zusätzlich ist mir - durch die Hinweise von Lukas und die von dir geteilten Screenshots mit den Outbound-Einträgen - aufgefallen, dass meine E-Mails nicht über relay.yourmailgateway.de versendet werden, sondern direkt über mein Reseller-Webhosting.

Bislang hat sich an diesem Verhalten nichts geändert. Möglicherweise müssen die DNS-Änderungen erst vollständig greifen, allerdings wäre es mir neu, dass der SPF-Eintrag selbst die Versandroute der E-Mails beeinflusst, sondern lediglich bei der Authentifizierung eine Rolle spielt. Falls ich hier falsch liege, klärt mich bitte auf.

Sollte meine Annahme korrekt sein, dass der SPF-Eintrag nicht über das Versand-Gateway entscheidet, dann dürfte es sich um einen Supportfall für netcup handeln, da meine E-Mails offenbar über den falschen Weg versendet werden.

Ich bin gespannt, wie es weitergeht. Mein innerer Monk hat jedoch bereits gesiegt - da ich saubere Authentifizierungsergebnisse und möglichst viele grüne Haken bevorzuge, habe ich mir bereits eine alternative Lösung gebaut. Diese ersetzt zumindest für Kunden mit geschäftskritischem E-Mail-Verkehr teilweise den E-Mail Versand/Empfang über das netcup Reseller-Hosting. Mein Ziel ist es, bei diesen Kunden ausschließlich solche Werte zu sehen, wie ich sie aktuell in meinem Testsystem erhalte:

pasted-from-clipboard.png

pasted-from-clipboard.png

Viele Grüße

Marc

Zitat von p0se

Das ist richtig, sollte für DKIM nicht relevant sein.

Schreib mir doch mal ne PM mit deiner Domain wenn du magst, vielleicht fällt mir ja etwas auf.

Da ich heute nochmal ein wenig Zeit hatte, die DKIM bei den normalen Webhosting Tarifen wird ja identisch eingebunden und funktioniert auch ohne Probleme. Nur bei den Reseller Tarifen funktioniert es, zumindest bei mir, nicht.

p0se

Tatsächlich sind meine Einträge fast identisch.

Mein _dmarc sieht ein wenig anders aus und der spf Eintrag ist auf meine Reseller IP beschränkt. Das sollte allerdings nichts an dem DKIM Problem ändern.

Viele Grüße

Marc

Vielen Dank für die ausführliche und detaillierte Antwort!

Tatsächlich macht es bei checktls keinen Unterschied, ob ich mail.domain.tld oder nur domain.tld verwende.

Sobald ich Send SNI aktiviere, verläuft der Test in beiden Fällen erfolgreich. (Ist ja nicht so, dass in meinem eigenen Screenshot das als Tipp hinterlegt ist.. Habe ich wohl übersehen....)

Warum E-Mails dennoch mit der Begründung "Zertifikat stimmt nicht überein" abgelehnt wurden, bleibt mir weiterhin ein Rätsel.

Dennoch war deine Erklärung äußerst aufschlussreich und hat mir bereits erheblich weitergeholfen.

Nochmals vielen Dank!

Nachtrag:

Das gleiche Problem tritt auch beim regulären Netcup-Webhosting auf. Zu Testzwecken habe ich diesmal eine Webserver-Inklusiv-Domain genutzt, die auch DNS-seitig vollständig von Netcup verwaltet wird.

Dort sind standardmäßig zwei MX-Einträge vorhanden: einer verweist auf mail.meine-domain.tld, der andere direkt auf den MX-Server von Netcup. Auch hier: Eine Prüfung wird als erfolgreich gewertet, während die andere fehlschlägt.

uebersicht_cert.png

Wie sich das Verhalten gestaltet, wenn ein MX-Eintrag mit dem Zertifikat valide ist und der andere nicht, kann ich noch nicht abschließend sagen. Da jedoch mail.meine-domain.tld eine niedrigere Priorität hat, vermute ich, dass die E-Mails auch hier nicht versendet werden. Ich werde dies später testen und entsprechend berichten.

Hallo zusammen,

ich möchte mich an diejenigen wenden, die ebenfalls einen Webhosting Reseller-Tarif von Netcup nutzen, um herauszufinden, ob Ihr das folgende Problem ebenfalls beobachten konntet oder ob ich möglicherweise eine Fehlkonfiguration vorgenommen habe.

Problemstellung:

Nach meiner Erfahrung tritt dieses Problem auf, wenn man sich exakt an die Netcup-Wiki-Anleitung zum Reseller-Tarif hält.

Ich habe die DNS-Einträge entsprechend den Vorgaben aus dem Netcup-Wiki und dem Support eingerichtet, insbesondere den MX-Eintrag auf mail.meine-domain.tld. Bei einer Überprüfung mittels checktls.com wird jedoch ein Fehler angezeigt: Das Zertifikat des MX-Servers stimmt nicht mit dem angegebenen Hostnamen überein.

(Wer auch mal prüfen möchte: https://www.checktls.com/TestReceiver)

Mir ist zudem aufgefallen, dass dieses Problem nicht nur bei Netcup, sondern auch bei vielen anderen Plesk-basierten (Reseller-)Webhosting-Angeboten auftritt.

cert_error.png

Relevanz des Problems:

Dieses Verhalten besteht offenbar schon seit längerer Zeit, gewinnt aber nach meiner Ansicht zunehmend an Bedeutung. Immer mehr E-Mail-Server bzw. SMTP-Server prüfen nicht nur, ob eine TLS-Verbindung zur Gegenstelle besteht, sondern validieren auch die Gültigkeit des Zertifikats.
Ist das Zertifikat ungültig oder entspricht es nicht dem angegebenen Hostnamen, etc., wird der Versand der E-Mail verweigert.

Mir ist das Problem heute beispielsweise erst bewusst geworden, weil E-Mails nicht an uns zugestellt werden konnten. Der Mailserver des Absenders ist durch Sophos Email Protection geschützt, und in dessen Richtlinien gibt es eine Option, die aktiviert ist. Diese verweigert den Mailversand, wenn die TLS-Zertifikatsprüfung beim Empfänger fehlschlägt.

Meine aktuelle Lösung:

Um das Problem zu umgehen, habe ich den MX-Eintrag im DNS von mail.meine-domain.tld auf den korrekten MX-Server (welcher über das Wildcard Zertifikat abgedeckt ist) umgestellt - in meinem Fall rw0b89.webhosting.systems. Seitdem gibt es keinen Zertifikatsfehler mehr.

no_chert_error.png

Hat jemand ähnliche Erfahrungen gemacht oder eine andere Lösung gefunden? Oder habe ich irgendwas komplett übersehen? Sollte an dieser Stelle evtl. das Wiki angepasst werden?

Ich freue mich auf eure Rückmeldungen!

Viele Grüße

Marc

Ich kann mich diesem Thema anschließen. Ich versuche mittlerweile seit mehreren Wochen DKIM zum laufen zu bringen mit meinem Reseller Tarif und es funktioniert einfach nicht.

Auch alles in diesem Interessanten Thread besprochene bin ich mittlerweile durch:

Viele Grüße

Marc