zdeneksvarc
Mailcow je dnes dost slusne receno prasarna 
ale obdivuju lidi kteri se do něčeho takoveho pusti ...samotna dokumentace postfixu a dovecotu je naprosto priserna.... Skladat tyto veci dohromady je nekdy doslova pokus/omyl
Stalwart Mail Server, open source self-hosted mail server v roce 2024 🎉
Já jsem teda mailcow začal používat už třeba 5 roků zpátky, šlape to bez problémů. Je na tom nahozených pár domén a pár relay pro domény, které běží přímo u zákazníka ve firmě. Až na těch 18 kontejnerů v dockeru jsem na problém asi nenarazil. Máte někdo nějaké specifické důvody, proč přejít na nějakou jinou službu? Možná mi tam chybí možnost sdíleného mailboxu (třeba se to tam nastavit dá) jako např. info nebo support, ke kterému bude mít přístup více uživatelů.
Mailcow neni zly, ale je to tak trochu smerovane k groupware. Sam som nejake PR prihodil aj pre roundcube skrz password api driver. Ma to svoje pro a proti. Hlavne Andre pribral dalsieho cloveka aby to vobec stihal, nakolko ma inu pracu. Stabilita je fajn a zatial som nemal problem. Je pravda ze compose mam upraveny + svoje rspamd pravidla. Ten stalwart pozriem ... dik za tip
o 2 měsíce později
Zkouším Stalwart, ale nevím, jak nastavit jednu věc - rád bych, aby ho ostatní servery v síti mohly používat jako relay. Tzn. aby fungoval jako SMTP server bez nutnosti autentizace pro ostatní servery, jejichž IP adresy budou z konkrétního rozsahu. Mělo by se to patrně dát nastavit v Settings -> SMTP -> Inbound -> RCPT stage -> Allow Relaying. Asi bych věděl, jak napsat pravidlo pro jednu IP adresu, ale jak zadat celý C rozsah, to nevím. Dokázal by někdo poradit, jak to správně udělat?
darklogic Naštěstí se vždycky podařilo podobné případy vyřešit jinak (lokální postfix + libsasl2-modules nebo smtp sajdkára v jiném kontejneru), ale určitě dej vědět, jak jsi dopadl.
(jsem z http://poste.io) Je vždycky fajn vědět, že někdo respektuje licence obzvlášť v našem historicky lehce zasmrádlém rybníčku. Prodáváme spíše mimo CZ, nicméně tady jsou našimi zákazníky ISPíci, obce, soukromé firmy (v cz držím i nadstandardní servis). Nicméně nalicencovat produkt tak aby byl životaschopný není jednoduché a v ideálním světě by za mě žádné licence neexistovaly. Každopádně jsem jeden z členů vývoje Haraky takže dáváme i zpět (co se týče svědomí k OS).
Jinak Stalwart vypadá supr, ale příliš beta...
analogic Testuju i poste.io. Tam mě trápí, že dokumentace je hodně skromná (i oproti Stalwart) a méně přehledná. Třeba tady:
https://poste.io/doc/network-schemes
Rád bych použil variantu č. 2, ale je tu zmínka:
"Let's encrypt certificates requires "/.well-known" folder properly redirected to poste container"
Moc nevím, co se tím chce říct (co je to za složku) a jak ji teda nastavit. A obecně pak v dokumentaci toho o Let's encrypt není moc zmíněno.
- Upraveno
darklogic Většina lidí používá nginx/caddy/traefik(my) jako reverzní proxy, která sama obstará certifikát od LE. Problém ale je, že pokud chcete používat LE i v mailserveru tak je nutné certifikát nějak obstarat. Tzn. reverzní proxy musí umět requesty na .well-known, které nejsou pro ni posílat dále na kontejner poste. Další podmínka je, že ověřování s LE musí probíhat pouze na HTTP bez SSL. Ve výsledku máte tedy dva certifikáty na jednu doménu:
- mail.poste.io(1) - reverse proxy https
- mail.poste.io(2) - smtp, submission, pop3, imap
Jednoduše se to zprovozní člověku co ví co dělá, ale jinak je to taková vyšší dívčí a tak trochu "out of scope" dokumentace mailserveru jelikož to silně závisí na konfiguraci reverzní proxyny. Ale rozumím a vím, že v dokumentaci jsou velké mezery...
analogic Na druhou stranu je dobré si připomenout, že protokol ACME (Letsencrypt, ZeroSSL a další) umí vyzvat žadatele čtyřmi způsoby, takže nepotřebuje nutně :80 port (DNS-01, TLS-ALPN-01).
Jinak u Stalwartu se certifikáty získané z reverzní proxy natahují přes:
certificate.default.cert = "%{file:///certs/example.com/example.com.crt}%"
certificate.default.private-key = "%{file:///certs/example.com/example.com.key}%"Musíme pak zajistit pravidelný reload certifikátu. Nejsnadnější způsob je pravidelný restart na prasáka.
restarter:
image: docker # https://hub.docker.com/_/docker
volumes: ["/var/run/docker.sock:/var/run/docker.sock"]
command: ["/bin/sh", "-c", "while true; do sleep 864000; docker restart <container_name>; done"]
restart: unless-stoppedFunguje to. Každopádně kdo si dá práci přemigrovat do Kubernetes (cert-manager), tak má život snažší.
No vidíte, poste si certifikát a reload zajistí sám (pokud to tedy nemáte potřebu komplikovat reverzní proxy).
Poste je postaveno kolem jednoho use-casu - menší firma, průměrně líný admin, který nechce nic moc řešit, standardní použití, pokud možno bezbolestné upgrady, rozumné výchozí nastavení a přes web. Všechny tyhle termity DKIM, DMARC, ARC, SRS, SPF, LE v základu a přes web. Flexibilita není taková jako když si to postavíte sám. Ale dle dockeru 10M+ stažení free verze a velké množství platících zákazníků mi asi dává za pravdu, že to asi tak blbé nebude. Není to vlákno o poste, tak s klidem srovnávejte, ale osobně už to tu zaplevelovat nebudu...
- Upraveno
analogic No vidíte, poste si certifikát a reload zajistí sám (pokud to tedy nemáte potřebu komplikovat reverzní proxy).
Ehm, https://stalw.art/docs/server/tls/acme/challenges
Nerozumím "komplikacím" s reverzní proxy. Pokud jsou potřeba ACME (X.509) certifikáty, zvolím ACME klienta (certbot, caddy, stalwart, poste, cokoliv) uložím certifikáty na sdílené místo a ostatní aplikace si tyto certifikáty vezmou. Kde má být komplikace nad rámec běžné praxe?