mailcow: deschizi SOGo ca orice cutie poștală, actualizezi din interfață și configurezi DNS-ul

Problema: trei treburi care îți mănâncă săptămâna

Dacă rulezi mailcow-dockerized pentru tine sau pentru câțiva clienți, știi rutina. Cineva te roagă să verifici o cutie poștală, așa că apeși SOGo lângă ea în interfața de admin și sesiunea de admin s-a dus: mailcow ține o singură sesiune per nume de gazdă, așa că aceeași sesiune trece pe cutia poștală. Și cât timp sesiunea de admin e deschisă, SOGo te trimite oricum înapoi la dashboard.

Apoi e actualizarea. mailcow lansează versiuni des, iar actualizarea înseamnă o sesiune SSH, update.sh și speranța că ți-ai amintit de o copie de rezervă. Și fiecare domeniu de mail nou are nevoie de înregistrările MX, SPF, DKIM și DMARC puse de mână la furnizorul de DNS, plus o verificare DNS inversă de care nu-și amintește nimeni până când Gmail nu începe să respingă mailul.

mailcow Toolkit este un plugin care rezolvă toate trei din interiorul propriului tău mailcow și care continuă să funcționeze după actualizările mailcow, pentru că nu modifică niciun fișier urmărit de mailcow. Acest tutorial parcurge configurarea o singură dată, ca treburile zilnice să devină click-uri.

Cerințe preliminare

mailcow-dockerized pe Linux (Toolkit este testat cu 2026-09 și 2026-09a), instalat de exemplu în /opt/mailcow-dockerized, cu docker compose și systemd.
Acces root pe gazdă, cu git, jq, flock, curl, tar și sha256sum instalate.
HTTPS ieșire către medialab.works de pe server (verificarea licenței, trial, actualizările Toolkit).
O cheie de licență din contul tău medialab.works sau o adresă de e-mail pentru trialul gratuit de 30 de zile.
Un al doilea nume de gazdă pentru webmail (de exemplu webmail.example.com) în DNS, servit de același reverse proxy ca interfața mailcow.
Un folder de copii de rezervă, de exemplu /srv/backup/mailcow.
Pentru SOGo ca orice cutie poștală: ALLOW_ADMIN_EMAIL_LOGIN=y în mailcow.conf și permisiunea Login as mailbox user.
Opțional, pentru scrierea înregistrărilor DNS: un cont Cloudflare și un token API cu Zone > Zone > Read și Zone > DNS > Edit.

Pasul 1 — Instalează Toolkit

Descarcă mailcow-toolkit-<version>.tar.gz din contul tău, dezarhivează-l pe gazda mailcow și rulează, ca root:

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized \
  --webmail-url https://webmail.example.com --backup-dir /srv/backup/mailcow

--mailcow-dir este locul unde stă mailcow (implicit /opt/mailcow-dockerized).
--webmail-url este adresa de webmail, https:// plus numele de gazdă (un port opțional este permis). Dacă îl lași deoparte, butonul SOGo păstrează comportamentul standard din mailcow.
--backup-dir este locul unde merg copiile de rezervă înainte de actualizări. Dacă îl lași deoparte, Update now rulează fără copie de rezervă mai întâi, iar installerul te avertizează.
--name este necesar doar dacă rulezi mai multe instalări mailcow pe o singură gazdă.

Installerul activează cinci unități systemd, printre care un timer zilnic pentru verificarea versiunii și a licenței, unul care verifică DNS-ul invers la fiecare 6 ore și unul care caută domenii mailcow noi la fiecare 2 minute. La final reîncarcă php-fpm și îți cere să deschizi secțiunea License.

Pasul 2 — Activează licența

Deschide System > Updates (Toolkit) ca admin. Secțiunea License din partea de sus funcționează și fără licență: introdu cheia și apasă Activate, sau începe trialul gratuit de 30 de zile cu adresa ta de e-mail și deschide linkul de checkout Stripe afișat (cardul este cerut acolo și nu este debitat în timpul trialului). Pagina activează Toolkit de la sine odată ce trialul începe. Fără o licență validă, funcțiile Toolkit se opresc și nu se șterge nimic.

Pasul 3 — Un nume de gazdă separat pentru webmail

Acesta este tot trucul din spatele păstrării sesiunii de admin. Browserul ține un cookie de sesiune per nume de gazdă, așa că SOGo are nevoie de propriul nume.

Îndreaptă webmail.example.com către serverul tău în DNS.
În reverse proxy, servește-l exact ca interfața mailcow: același backend, aceleași antete. Este același mailcow, doar sub alt nume.
Dă-i un certificat TLS, ca interfeței.

Dacă ai instalat deja cu --webmail-url, acest pas e gata. Dacă nu, rulează din nou install.sh din versiunea nouă; adresa de webmail și folderul de copii de rezervă de dinainte se păstrează când le lași deoparte.

Pasul 4 — Activează SOGo ca orice cutie poștală

În mailcow.conf setează ALLOW_ADMIN_EMAIL_LOGIN=y, apoi aplică din interfața mailcow.
Asigură-te că adminul are permisiunea Login as mailbox user.

De atunci, butonul SOGo din lista de cutii (pentru adminul platformei; adminii de domeniu păstrează butonul propriu al mailcow) deschide SOGo ca acea cutie poștală, într-o filă nouă, în timp ce fila ta de admin rămâne conectată. Predarea folosește un token de unică folosință, valabil 60 de secunde și folosit o singură dată; pe gazda de webmail pornește o sesiune nouă de cutie poștală, care nu moștenește niciodată rolul de admin. Cutiile poștale inactive sunt refuzate, după regulile proprii ale mailcow.

Fiecare folosire e jurnalizată de două ori: în jurnalul de login al mailcow pentru acea cutie poștală, ca login SSO, și în jurnalul de audit al Toolkit, cu cine a deschis-o și de la ce adresă. Asta e partea care le place auditorilor și clienților.

Pasul 5 — Actualizări din interfață, cu copie de rezervă mai întâi

Deschide System > Updates (Toolkit). Pagina arată versiunea mailcow instalată, ultima verificare și noile modificări. Serverul verifică zilnic o versiune nouă de mailcow și trimite un singur e-mail pe versiune nouă, la adresa pe care o setezi pe pagină.

Când ești gata, apasă Update now. Toolkit face mai întâi o copie de rezervă (crypt, redis, rspamd, postfix și mysql, păstrată 14 zile), apoi rulează update.sh-ul propriu al mailcow, apoi așteaptă până când fiecare container rulează și interfața răspunde. Jurnalul se vede în timp real pe pagină.

Două garanții contează: dacă copia de rezervă eșuează, actualizarea se oprește și nu se schimbă nimic; dacă update.sh eșuează sau un container nu pornește, pagina spune asta și păstrează jurnalul. Pagina urmează limba interfeței mailcow, engleză sau română.

Pasul 6 — Înregistrări DNS pentru fiecare domeniu

Deschide System > DNS & Cloudflare (doar admini). Pentru fiecare domeniu mailcow și domeniu alias, pagina listează înregistrările de care are nevoie mailcow, după verificarea DNS proprie a mailcow:

Obligatorii: înregistrarea A a MAILCOW_HOSTNAME (DNS-only în Cloudflare), MX 10 către MAILCOW_HOSTNAME, SPF, DKIM (selectorul și cheia mailcow) și DMARC.
Recomandate: CNAME-urile autodiscover și autoconfig (DNS-only), înregistrările SRV pentru autodiscover, IMAPS, submission, SMTPS, POP3S (când POP3 este permis), CalDAV și CardDAV cu TXT-ul lor path=/SOGo/dav/ (cu SOGo), și MTA-STS și TLS-RPT când MTA-STS este activ pentru domeniu.
Domeniile alias primesc MX, SPF, DKIM, DMARC și, cu MTA-STS, înregistrările TXT ale acestuia.

Fiecare înregistrare este comparată cu DNS-ul public, cu un fișier de zonă pe care îl încarci (un export Cloudflare sau orice fișier BIND) și, cu credențiale Cloudflare, cu zona Cloudflare live. Stările sunt OK, lipsă, diferită, proxied (trebuie DNS-only), de corectat manual sau necunoscută.

Două valori implicite te țin departe de probleme. Implicit doar IPv4: nicio înregistrare AAAA și un SPF de v=spf1 ip4:<IPv4> -all; setarea Use IPv6 adaugă AAAA, ip6: și verificarea DNS-ului invers IPv6, pentru că un server care publică AAAA fără un PTR IPv6 potrivit își vede mailul pe IPv6 respins de Gmail și de alții. Și DMARC: o politică validă existentă este păstrată; altfel primești v=DMARC1; p=quarantine;, cu rapoarte către dmarc@ sau postmaster@ doar când acea adresă există. Porturile SRV urmează mailcow.conf și pot fi setate manual pentru serverele din spatele unui proxy sau NAT.

Download BIND zone file îți dă un fișier pe care Cloudflare îl importă din DNS > Records > Import and Export, cu cf_tags=cf-proxied:false pe înregistrările care trebuie să rămână DNS-only.

Pasul 7 — Aplică în Cloudflare, în siguranță

Cu un token API cu permisiuni limitate (recomandat) sau cu Global API Key, bifează înregistrări, previzualizează modificările și aplică-le. Se salvează mai întâi o copie de rezervă JSON a zonei, iar modificarea poate fi anulată; doar înregistrările selectate sunt create sau actualizate, nimic nu este șters, iar fiecare modificare ajunge în jurnalul de audit. Credențialele sunt verificate cu Cloudflare, stocate criptat pe serverul tău și nu mai sunt afișate niciodată. Acțiunile Cloudflare pentru un domeniu apar doar când credențialele salvate pot edita DNS în acea zonă; altfel pagina spune de ce.

Pasul 8 — Lasă domeniile noi să se configureze singure

Două funcții sunt oprite până nu le configurezi:

Automatic Cloudflare setup: în circa 2 minute de la adăugarea unui domeniu sau domeniu alias în mailcow (interfață sau API), înregistrările lui sunt create în zona Cloudflare existentă. Înregistrările greșite sunt actualizate, înregistrările fără legătură nu sunt șterse niciodată, iar o politică SPF, DMARC sau TLS-RPT existentă și diferită este lăsată așa cum este. O zonă lipsă este raportată sau creată dacă permiți asta; eșecurile pot fi trimise pe e-mail.
Asistent pentru domenii noi: adresele de rol (postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, fiecare opțională, plus ale tale) sunt create ca aliasuri către o adresă pe care o alegi, așa că nu se pun la socoteala limitei de cutii poștale. noreply@ aruncă mailul în liniște. O cutie poștală sau un alias existent nu este atins niciodată.

Domeniile care există deja când activezi o funcție sunt lăsate în pace; Provision now și Run wizard le procesează unul câte unul.

Pasul 9 — Urmărește PTR-ul și starea fiecărui domeniu

Toolkit verifică DNS-ul invers la fiecare 6 ore și afișează un „!” roșu în meniul de admin când eșuează. Pagina DNS se deschide cu un rezumat și un selector pentru fiecare domeniu și domeniu alias, cele mai grave primele: critic (mailul nu poate fi livrat sau trimis, sau va ajunge în spam), avertisment (lipsesc înregistrări opționale) sau în regulă, cu o explicație a ce e greșit și cum se remediază pentru fiecare domeniu. Stările se reîmprospătează la fiecare 10 minute în fundal; Re-check now verifică un domeniu imediat. Ultimul domeniu selectat este reținut.

Sfaturi și depanare

SOGo spune „Unauthorized” pentru un domeniu nou. SOGo citește domeniile mailcow când pornește, așa că un domeniu adăugat mai târziu îi este necunoscut. Din 0.4.0, Toolkit găsește astfel de domenii la fiecare 2 minute și repornește doar containerul SOGo (și golește memcached), în circa 3 până la 10 minute de la adăugarea domeniului: o dată pentru mai multe domenii noi, cel mult la fiecare 10 minute, doar cu licență validă. Fiecare repornire ajunge în jurnalul de audit.
Butonul SOGo se comportă ca în mailcow-ul standard. Verifică faptul că --webmail-url a fost transmis, că ALLOW_ADMIN_EMAIL_LOGIN=y este aplicat și că adminul are permisiunea Login as mailbox user.
Update now este gri sau rulează fără copie de rezervă. Folderul de copii de rezervă vine din --backup-dir; rulează din nou install.sh ca să îl setezi.
O înregistrare apare ca proxied. Acea înregistrare trebuie să fie DNS-only în Cloudflare; exportul de zonă le marchează pe acestea cu cf_tags=cf-proxied:false.
Server în spatele unui proxy sau NAT. Setează porturile SRV manual pe pagina DNS; altfel urmează mailcow.conf.
Nicio conexiune către medialab.works. După ultima verificare reușită, Toolkit continuă să funcționeze 7 zile.
Actualizarea Toolkit-ului însuși. Folosește secțiunea License: descarcă arhiva semnată, verifică dimensiunea și SHA-256 și păstrează versiunea anterioară, așa că o instalare eșuată face rollback. Merge și install.sh dintr-o versiune mai nouă.

Concluzie

Niciuna dintre aceste trei treburi nu e grea; doar că e ușor să le uiți. Un nume de gazdă separat pentru webmail transformă SOGo într-o vedere sigură, auditată, cu un singur click, a oricărei cutii poștale, în timp ce sesiunea ta de admin rămâne deschisă. Un buton de actualizare cu copie de rezervă mai întâi elimină pasul SSH și ghicitul. Iar o pagină DNS care compară fiecare domeniu cu DNS-ul public și cu Cloudflare, plus o verificare PTR la fiecare 6 ore, prinde problemele înainte de destinatar. Pentru că Toolkit nu modifică niciun fișier urmărit de mailcow, rezistă la actualizările mailcow, așa că îl configurezi o singură dată.

Ghidul de utilizare acoperă fiecare setare în detaliu, changelog-ul listează ce a adăugat fiecare versiune, iar baza noastră de cunoștințe are mai multe pentru cei care își găzduiesc singuri serviciile. Întrebări? Ia legătura cu noi.

Postarea a fost scrisă cu ajutorul AI pe baza documentației produselor noastre sau a surselor indicate și verificată automat înainte de publicare.