Hallo, ich habe mir ein paar YT Videos zu MC angeschaut und mich ein wenig eingelesen. Hintergrund: ich nutze Cloudflare für meine Domain, dort werden Domain E-Mails weitergeleitet zu meiner GMX oder Google E-Mail. Um aus Outlook/Thunderbird Domain E-Mails zu schreiben nutze ich smtp2go. Desweiteren betreibe ich Zuhause einen Webserver (Ubuntu VM). Meine Idee: eine weitere Ubuntu VM Zuhause betreiben als E-Mail Posteingangsserver für Domain E-Mails. Da man von Zuhause aus keine E-Mails senden kann (ohne im Spam zu landen), würde ich bei smtp2go bleiben, das Volumen ist für mich völlig ausreichend. Dabei bin ich bei Mailcow gelandet. Nach ein wenig Einlesen bin ich bei Let´s Encrypt hängen geblieben. Problem: Port 80/443 ist schon vergeben. Vielleicht Lösung: ich betreibe einen Nginx Reverse Proxy im Docker (hoher Port nach außen hin), dieser holt sich sein Wildcard Zertifikat per DNS Challenge. Nun bin ich auf folgende Lösung eines Nutzers von 2018 gestoßen: > > The advantage in changing the links to the certificates in a docker-compose override file is you do not have to copy the certificate and key file to /opt/mailcow-dockerized/assets/ssl/ BUT you have to restart mailcow, if a certificate changes, gets renewed, etc from certbot to make it work in mailcow. > > If the certbot is running on the same server like mailcow maybe a post-hook in certbot to restart mailcow can be a solution. In my scenario the nginx proxy with certbot runs on another server and I simply mount the directory containing the certificate and key file into the mailcow server and use a shell script that regularly copys the certificate and key to the mailcow directory and restarts mailcow. Works without problems. > > If you want to try the shell script: > > #!/bin/bash > cd /opt/mailcow-dockerized > cp /etc/letsencrypt/live/<subdomain.domain.com>/fullchain.pem data/assets/ssl/cert.pem > cp /etc/letsencrypt/live/<subdomain.domain.com>/privkey.pem data/assets/ssl/key.pem > docker-compose down && docker-compose up -d > > I regularly start this script via cron: > > 0 4 * * 2 /root/scripts/restart_mailcow_acme.sh >/dev/null 2>&1 > > This starts the script every Tuesday at 4:00 am - copys the (new) files into mailcow and restarts it. Ich müsste also das Zertifikat vom Docker irgendwie periodisch rüber kopieren, das geht, aber richtig schön ist das nicht. Hat sich hier seit 2018 etwas getan? Kann sich MC inzwischen selber per DNS Challenge ein Wildcard Zertifikat holen ? Wenn mich nicht alles täusch, stören sich mehrere Wildcard Zertifikate nicht gegenseitig oder ? ----------- Frage zur Hardware: Was bräuchte ich für ein paar E-Mails im Monat an sinnvollen Resourcen für die VM ? Möchte nicht unnötig 8GB Ram zuteilen wenn auch 2 oder 4GB reichen würden. Plattenplatz 50GB ? ----------- Frage zu den ganzen MC-Diensten: Läuft das überhaupt als nur Posteingangsserver oder gibt es dann periodische Fehlermeldungen z.B.: Dkim nicht richtig hinterlegt (weil ich es ja nicht nutze)?

Ich würde dir raten als Neuling möglichst nah an der Mailcow Dokumentation zu bleiben und nicht schon beim ersten Versuch irgendwelche möglicherweise veraltete Skripte zu verwenden. Wildcard Zertifikate werden von mailcow nicht unterstützt. Dass dein Port 80/443 schon "vergeben" ist (vermutlich für www.domain.de), kannst du wie du selbst schon geschrieben hast umgehen, indem du einen Reverse Proxy verwendest, der kann den Traffic dann aufteilen zwischen den Systemen. Damit funktioniert dann auch das eingebaute Lets Encrypt von Mailcow, wenn du dich an die Templates der Reverse Proxy Doku von Mailcow hältst. > @"[unknown]"#p21025 8GB Ram zuteilen wenn auch 2 oder 4GB reichen würden Kommt drauf an... 6GB ist eigentlich das Minimum gemäß Dokumentation. 4GB sollte auch laufen, wenn du Sachen wie ClamAV oder Volltextsuche (Solr) abschaltest. Ob das sinnvoll ist sei dahingestellt... > @"[unknown]"#p21025 Dkim nicht richtig hinterlegt Was meinst du damit? Dkim läuft nicht ab, entweder hast du es richtig hinterlegt oder nicht ;) Es stellt sich auch die Frage ob du Mailcow (ist ja eine volle Groupware) überhaupt brauchst, und ob nicht etwas einfacheres, ressourcenschonenderes wie [mailu](https://mailu.io) oder [docker-mailserver](https://github.com/docker-mailserver/docker-mailserver) besser geeignet ist. Die laufen auch mit 4 GB RAM oder weniger

> @"Becker884"#p21025 Ich müsste also das Zertifikat vom Docker irgendwie periodisch rüber kopieren, das geht, aber richtig schön ist das nicht. Nein, das ist nach wie vor so. Entweder du holst die Zertifikate mit dem Reverse Proxy ab (Lets Encrypt in Mailcow deaktivieren, und kopierst es [dann zur Mailcow](https://docs.mailcow.email/post_installation/firststeps-ssl/#how-to-use-your-own-certificate), oder umgekehrt. Ich habe eine Sophos Firewall vor meinem Mailcow die Reverse Proxy macht, die holt die Zertifikate und ich kopiere dann mit Ansible/Scripten regelmäßig die Zertifikate vom Reverse proxy zur Mailcow.

Vielen Dank für die Infos! Also Wildcard wird nicht akzeptiert und > indem du einen Reverse Proxy verwendest, der kann den Traffic dann aufteilen zwischen den Systemen. da hört es dann bei mir auf, wüsste nicht wie ich Port 80/443 splitten sollte. Wie soll sowas technisch gehen? Angenommen meine Homepage wird besucht und gleichzeitig will Certbot die Zertifikate von Mailcow erneuern, somit wird zum selben Zeitpunkt Port 80/443 von zwei Servern gebraucht. bei mailu und docker-mailserver wird es vermutlich das gleiche Problem sein mit den Zertifikaten. > @"esackbauer"#p21029 Was meinst du damit? Dkim läuft nicht ab, entweder hast du es richtig hinterlegt oder nicht Ich habe die Einträge von smtp2go in meiner domain hinterlegt, da ich damit sende. Somit ist es aus Sicht von Mailcow falsch hinterlegt. Das meinte ich damit, ob es dann periodische Fehlermeldungen gibt. Schätze nicht, dass so ein Anwendungsfall in MC gedacht ist (Fremder SMTP).

> @"Becker884"#p21033 da hört es dann bei mir auf, wüsste nicht wie ich Port 80/443 splitten sollte. Dann solltest du dich einlesen wie Reverse Proxies funktionieren. Die können z.b. am Host header value sehen für welche Website der Traffic ist und das entsprechend an den eigentlichen Webserver weiterleiten. Alternativ könntest du mailcow an einer eigenen externen ("public") IP adresse betreiben. Wenn du aber das auf einem Homerouter zuhause machst wirst du um einen Reverse Proxy nicht herumkommen. Und darauf hoffen, dass dein Internet Provider nicht Port 25 eingehend blockt. Sonst kannst du das gleich alles knicken. Du brauchst auch eine public IPv4 Adresse am Router, eine IPv6 Adresse (oder CG-NAT) genügt nicht, sonst kannst du keine Mails empfangen. > @"Becker884"#p21033 Somit ist es aus Sicht von Mailcow falsch hinterlegt. Nein, ist es nicht. Du verstehst anscheinend nicht wie DKIM funktioniert. Eventuell meinst du SPF, aber das ist ja kein problem in den SPF record kommen dann die Einträge von smtp2go. > @"Becker884"#p21033 Schätze nicht, dass so ein Anwendungsfall in MC gedacht ist (Fremder SMTP). Doch das ist ein alltäglicher Anwendungsfall. Smtp2go ist dein Relay host, und der wird in Mailcow (aber auch in den anderen Lösungen) entsprechend eingetragen, bei Mailcow als "Senderabhängiger Transport".

Danke, ich denke dann lasse ich das Hobby-Projekt sein. > @"esackbauer"#p21035 am Host header value sehen für welche Website der Traffic ist und das entsprechend an den eigentlichen Webserver weiterleiten. das ist mir eine Nummer zu hoch! > @"esackbauer"#p21035 dass dein Internet Provider nicht Port 25 eingehend blockt Provider ist Telekom, das wäre natürlich der Hammer, wenn das so ist. Ich weiß es ehrlich gesagt nicht. Gelesen habe ich davon schon, bei den Beschwerden hieß es immer nur dass 25 ausgehend geblockt wurde, wenn der Anschluss als Spamschleuder erkannt wurde. Von Eingehend war nie die Rede. IP4 habe ich, daran würde es nicht scheitern. > @"esackbauer"#p21035 Nein, ist es nicht. Du verstehst anscheinend nicht wie DKIM funktioniert. Eventuell meinst du SPF, aber das ist ja kein problem in den SPF record kommen dann die Einträge von smtp2go. da muss ich korrigieren, SMTP2Go nutzt keinen SPF Record sondern einen CNAME Record `s123456._domainkey - dkim.smtp2go.net`. Das wäre angeblich die Zukunft und das andere veraltet laut deren Doku) **Noch mal zu den Zertifikaten**: Beim docker-mailserver las ich, dass der mit Wildcard Zertifikaten arbeiten kann. Wo liegt der Unterschied? Der externe Mailserver (GMX,MS,Google usw.) klopft doch bei mir Zuhause an, möchte mir eine E-Mail zustellen und akzeptiert das Zertifikat oder eben nicht. Warum bei Mailcow nicht und beim docker-mailserver ja ?

> @"Becker884"#p21038 TP2Go nutzt keinen SPF Record sondern einen CNAME Record Oh, das heisst die machen schon DKIM. Ich würde das dort deaktivieren wenn das geht, besser ist dass mailcow das macht, somit ist schon ab deinem Server jedes Mail signiert, andernfalls könnte es theoretisch auf dem Wege zu oder durch smtp2go modifiziert werden. Alternativ könntest du auch schon die voreingestellte DKIM Lösung von smtp2go verwenden, und DKIM im mailcow ausschalten (die keys löschen) > @"Becker884"#p21038 Noch mal zu den Zertifikaten: Wildcard wird jedenfalls nicht vom Mailcow internen Lets Encrypt unterstützt. Kann sein dass es mit mailcow funktioniert, wenn du es vom Reverse Proxy nach Mailcow kopierst. Müsstest du im Forum suchen ob das schon wer erfolgreich verwendet.

> @"esackbauer"#p21035 Doch das ist ein alltäglicher Anwendungsfall. Smtp2go ist dein Relay host, und der wird in Mailcow (aber auch in den anderen Lösungen) entsprechend eingetragen, bei Mailcow als “Senderabhängiger Transport”. Was hat es eigentlich mit dem Autodiscover auf sich? Wenn ich mit meiner Clientsoftware (Outlook oder Thunderbird) meinen eigenen Mailserver einrichten will (pop3 oder imap), dann sagt Mailcow dem Client alle Einstellungen. In dem Zusammenhang wird dann auch per Autodiscover der abweichende smtp2go mitgeteilt ? > @"esackbauer"#p21040 Wildcard wird jedenfalls nicht vom Mailcow internen Lets Encrypt unterstützt. das weiß ich ja, es ging mir ja in #1 um das kopieren des Wildcard Zertifkats vom NPM Docker, wenn das klappt wäre es einen Versuch wert. Was hat es eigentlich mit dem Hostnamen der VM auf sich: warum muss der Hostname mail.meinedomain.de heißen ? Das habe ich nicht verstanden. Wenn ich Port 80/443 nach außen hin nicht nutze, kann ich das WebUI eh per mail.domain.de nicht aufrufen.

> @"Becker884"#p21042 Zusammenhang wird dann auch per Autodiscover der abweichende smtp2go mitgeteilt ? Nein, Relay server sind nicht für Clients gedacht! Die Clients senden an Mailcow (oder welche Mailserver du verwendest) und dieser sendet an den relay server. > @"Becker884"#p21042 warum muss der Hostname mail.meinedomain.de heißen Er muss nicht so heissen, aber dann gibts eben keine Kollision mit www.meinedomain.de etc. > @"Becker884"#p21042 Wenn ich Port 80/443 nach außen hin nicht nutze, kann ich das WebUI eh per mail.domain.de nicht aufrufen. Wenn du 80/443 nicht nach aussen verfügbar machst, geht kein ActiveSync und kein CalDAV/CardDAV. Auch hat ein User keine Chance SOGo (Webmail) aufzurufen, seine Quarantäne anzusehen, kannst keine App Passwörter anlegen etc.

Der Empfang Zuhause klappt einwandfrei, die Zertifikate habe ich erst mal per Hand rüber kopiert. Was nicht klappt ist Autodiscover in Outlook. Ich habe den Postein-/ausgangs Server manuell eingegeben und das läuft auch. Wenn ich im SOGo was versende, dann klappt es nicht weil er dann MC als Ausgangsserver nimmt und ich natürlich bei Spamhaus geblockt bin. ~~Frage: Kann ich den smtp2go in MC als Postausgang einrichten, so dass SOGo ihn verwendet und am besten die Clienten auch (Outlook / Thunderbird) Das soll unter "Senderabhängige Transport Maps" eingetragen werden, ich habe nur keinen Plan was ich da wo eintragen soll. Gibt es ein Beispiel ?~~ Habe es gefunden.

> @"Becker884"#p21090 Was nicht klappt ist Autodiscover in Outlook Du brauchst die entsprechenden DNS einträge: https://docs.mailcow.email/de/getstarted/prerequisite-dns/#die-minimale-dns-konfiguration Siehe auch die erweiterte DNS Konfiguration mit dem SRV record für autodiscover. Deine Zertifikate müssen diese SAN (subject alternative name) auch entsprechend beinhalten. Und dein Reverse Proxy muss die autodiscover Website auch richtig an mailcow weitergeben.

Mailcow nur als Posteingangsserver nutzen, paar Anfängerfragen.

esackbauer

In einer neuen Postfix installation ist alles unbekannt.
Oder glaubst du die senden in Postfix (einem open source MTA) alle IP adressen (die sich ändern können) von Microsoft mit? oder vertrauen Absenderadressen von Microsoft blind?

DocFraggle

Becker884 Die Gegenseite war Outlook / O365, wenn die unbekannt ist oh ha.

Lest doch bitte einfach mal die Dokus bevor Ihr schreibt… das nimmt echt überhand langsam

Becker884

Hab ich versucht, finde nix zur Greylist außer dass man die nicht abschalten soll.
Vielleicht kannst du mir einen passenden Link rein stellen, wo ich mich selber schlau lesen kann?
Das würde mir sehr helfen. Vielen Dank.

DocFraggle

LMGTFY

https://www.google.com/search?q=greylisting

Becker884

danke, wieder was gelernt, wobei das nicht unter der Doku zu finden war ;-)

(allgemein Wikipedia hab ich nicht gesucht, dachte die Greyliste wäre was spezielles von rspamd, sorry)

« Previous Page