mailcow Toolkit

mailcow-dockerized păstrează o singură sesiune pe nume de gazdă. Când un admin apasă SOGo lângă o cutie poștală, aceeași sesiune trece pe cutia poștală: SOGo se deschide, dar adminul nu mai e conectat în interfața de admin, iar cât timp sesiunea de admin e deschisă, SOGo te trimite înapoi la panoul de admin. Actualizarea mailcow înseamnă o sesiune SSH și update.sh. Fiecare domeniu de e-mail nou are nevoie de înregistrările MX, SPF, DKIM și DMARC, puse de mână la furnizorul DNS. mailcow Toolkit rezolvă toate trei, în mailcow-ul tău, și rămâne la locul lui după actualizările mailcow.

Ce face

SOGo ca orice cutie poștală, cu sesiunea de admin păstrată

  • Butonul SOGo din lista de cutii poștale (doar pentru administratorul platformei; adminii de domeniu păstrează butonul mailcow) deschide SOGo ca acea cutie poștală, într-o filă nouă. Fila de admin rămâne conectată.
  • SOGo rulează pe un nume de gazdă separat pentru webmail (de exemplu webmail.example.com), deci are propriul cookie de sesiune, separat de interfața de admin.
  • 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ă a cutiei poștale, care nu moștenește niciodată rolul de admin.
  • Folosește regulile mailcow: cere ALLOW_ADMIN_EMAIL_LOGIN=y și dreptul Login as mailbox user („Conectează-te ca utilizator al cutiei poștale”), iar cutiile inactive sunt refuzate.
  • Fiecare folosire e jurnalizată: în jurnalul de conectări mailcow al acelei cutii (ca o conectare SSO) și în jurnalul de audit al Toolkit-ului, cu cine a deschis-o și de la ce adresă.
  • Fără un nume de gazdă pentru webmail, butonul se comportă ca în mailcow-ul standard.

Actualizarea mailcow din interfața de admin

  • O pagină nouă, System > Actualizări (Toolkit), arată versiunea mailcow instalată, ultima verificare și modificările noi.
  • Serverul verifică zilnic dacă există o versiune nouă de mailcow și trimite un singur e-mail pe versiune nouă la adresa pe care o setezi în pagină.
  • Actualizează acum face întâi o copie de rezervă (crypt, redis, rspamd, postfix și mysql, păstrat 14 zile), apoi rulează update.sh-ul mailcow, apoi așteaptă până când toate containerele rulează și interfața răspunde. Jurnalul se vede live în pagină.
  • 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 îți spune și păstrează jurnalul.
  • Pagina urmează limba interfeței mailcow: română sau engleză.

Înregistrările DNS și Cloudflare

Nou în 0.3.0: pagina System > DNS și Cloudflare (doar pentru admini) arată, pentru fiecare domeniu și domeniu alias din mailcow, înregistrările de care are nevoie mailcow, după verificarea DNS a mailcow:

  • Obligatorii: înregistrarea A a MAILCOW_HOSTNAME (doar DNS în Cloudflare; apare la domeniul în a cărui zonă se află numele de gazdă), MX 10 spre MAILCOW_HOSTNAME, SPF, DKIM (selectorul și cheia din mailcow) și DMARC.
  • Recomandate: CNAME-urile autodiscover și autoconfig (doar DNS), înregistrările SRV pentru autodiscover, IMAPS, submission și SMTPS, POP3S (când POP3 e permis), CalDAV și CardDAV cu TXT-ul lor path=/SOGo/dav/ (cu SOGo), plus MTA-STS și TLS-RPT când MTA-STS e activ pentru domeniu în mailcow.
  • Domeniile alias primesc MX, SPF, DKIM, DMARC și, cu MTA-STS, înregistrările TXT ale acestuia.
  • Fiecare înregistrare se compară cu DNS-ul public, cu un fișier de zonă pe care îl încarci (un export Cloudflare sau orice fișier BIND) și, cu date de acces Cloudflare, cu zona Cloudflare actuală. Starea este OK, lipsește, diferit, prin proxy (trebuie doar DNS), de reparat manual sau necunoscut.
  • Descarcă fișierul de zonă BIND îți dă un fișier pe care Cloudflare îl importă (DNS > Records > Import and Export), cu cf_tags=cf-proxied:false la înregistrările care trebuie să rămână doar DNS.
  • Implicit doar IPv4: fără înregistrare AAAA și cu SPF-ul v=spf1 ip4:<IPv4> -all. Setarea Folosește IPv6 adaugă AAAA, ip6: și verificarea DNS-ului invers IPv6. Un server care publică AAAA fără PTR IPv6 potrivit își vede e-mailurile trimise prin IPv6 respinse de Gmail și de alții.
  • DMARC: o politică validă existentă se păstrează; altfel v=DMARC1; p=quarantine;, cu rapoartele (rua) la dmarc@ sau postmaster@ al domeniului, doar dacă adresa există.
  • Porturile din SRV (IMAPS 993, Submission 587, SMTPS 465, POP3S 995, HTTPS 443) urmează mailcow.conf și pot fi setate de mână, pentru serverele din spatele unui proxy sau NAT.
  • O stare pentru fiecare domeniu: pagina începe cu un sumar și un selector cu fiecare domeniu și domeniu alias, cele mai grave primele: critic (e-mailurile nu pot fi livrate sau trimise ori ajung în spam: înregistrarea A a serverului de e-mail, MX, SPF, DKIM sau DMARC lipsesc, sunt greșite sau trec prin proxy, lipsește cheia DKIM, DNS-ul invers e greșit sau SOGo nu cunoaște încă domeniul), avertisment (lipsesc înregistrări opționale: autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT) sau totul e bine. Ultimul domeniu ales e ținut minte. Pentru fiecare domeniu pagina explică ce e greșit și cum se repară. Stările se reîmprospătează la fiecare 10 minute, în fundal; Verifică din nou verifică imediat un domeniu.
  • Acțiunile Cloudflare ale unui domeniu apar doar când datele de acces salvate funcționează și pot modifica DNS-ul în zona acelui domeniu (token API: Zone > Zone > Read și Zone > DNS > Edit); altfel pagina spune de ce.
  • Cloudflare: cu un token API limitat (recomandat) sau cu Global API Key, bifezi înregistrările, previzualizezi modificările și le aplici. Mai întâi se salvează o copie JSON a zonei, iar modificarea poate fi anulată; se creează sau se actualizează doar înregistrările selectate, nu se șterge nimic, iar fiecare modificare intră în jurnalul de audit. Datele de acces se verifică la Cloudflare, se păstrează criptat pe serverul tău și nu se mai afișează niciodată.

Domeniile noi, configurate singure

  • Configurarea automată în Cloudflare (oprită până salvezi datele de acces): în circa 2 minute după ce adaugi un domeniu sau un domeniu alias în mailcow (din interfață sau prin API), înregistrările lui se creează în zona Cloudflare existentă. Cele greșite se actualizează, înregistrările străine nu se șterg niciodată, iar o politică SPF, DMARC sau TLS-RPT existentă și diferită rămâne neschimbată. O zonă lipsă e raportată sau creată, dacă permiți asta. Eșecurile îți pot fi trimise pe e-mail.
  • Asistentul pentru domenii noi (oprit până setezi o destinație): adresele de rol (postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, fiecare opțională, plus ale tale) se creează ca aliasuri spre o adresă aleasă de tine, deci nu se socotesc în limita de cutii poștale. noreply@ aruncă e-mailurile fără răspuns. O cutie sau un alias existent nu e atins niciodată.
  • Domeniile care există deja când pornești o funcție nu sunt atinse; Configurează acum și Rulează asistentul le iau pe rând.

SOGo și domeniile noi

  • SOGo citește domeniile mailcow la pornire, așa că nu cunoaște un domeniu adăugat mai târziu: cutiile lui poștale primesc „Unauthorized” în SOGo și la butonul SOGo.
  • Nou în 0.4.0: la fiecare 2 minute Toolkit-ul găsește astfel de domenii și repornește doar containerul SOGo (și golește memcached), în circa 3–10 minute de la adăugarea domeniului: o dată pentru mai multe domenii noi, cel mult o dată la 10 minute, doar cu licență validă. Fiecare repornire se scrie în jurnalul de audit.
  • Cât timp un domeniu așteaptă, pagina DNS arată un avertisment și butonul Repornește SOGo. Opțiunea mailcow Restart SOGo de la adăugarea domeniului evită așteptarea.

Verificarea DNS-ului invers (PTR)

  • La fiecare 6 ore (și la Verifică acum), serverul verifică dacă fiecare IPv4 public (și IPv6, cu Folosește IPv6) are un PTR egal cu MAILCOW_HOSTNAME și dacă MAILCOW_HOSTNAME se rezolvă înapoi la el.
  • Când verificarea eșuează, apare un ! roșu lângă meniul System pe fiecare pagină de admin și un rând DNS invers (PTR) în System > Informație. Pagina îți spune cum se repară: PTR-ul ține de cel care deține IP-ul (furnizorul de hosting sau VPS, ori ISP-ul), nu de zona ta DNS.

Licență, perioadă de probă și actualizările Toolkit-ului

  • Secțiunea Licență, sus în System > Actualizări (Toolkit), activează Toolkit-ul cu cheia de licență sau pornește perioada de probă gratuită de 30 de zile cu adresa ta de e-mail: cardul se cere pe pagina de plată Stripe și nu se debitează în cele 30 de zile, iar pagina activează singură Toolkit-ul imediat ce pornește perioada de probă. Perioada de probă se poate folosi o dată pe server și pe adresă de e-mail.
  • Licența se verifică la pornirea serverului și o dată pe zi. Fără internet, Toolkit-ul funcționează 7 zile de la ultima verificare reușită.
  • Fără licență validă funcțiile Toolkit-ului se opresc: butonul SOGo se comportă ca în mailcow-ul standard, verificarea, e-mailurile și actualizările mailcow nu mai rulează, verificările DNS, indicatorul DNS invers, Cloudflare și asistentul pentru domenii noi se opresc, iar paginile arată doar secțiunea Licență sau un mesaj. Nu se șterge nimic; o licență validă le repornește pe toate.
  • Cu licență validă, aceeași secțiune actualizează Toolkit-ul la ultima versiune sau îl readuce la cea anterioară: arhiva semnată se descarcă de pe medialab.works, i se verifică mărimea și SHA-256, agentul de pe server rulează instalatorul acelei versiuni, iar dacă instalarea eșuează se reinstalează versiunea curentă. Instalările existente primesc 0.4.0 tot așa.
  • Din 0.4.0 pachetul conține și Sign-up for mailcow (înregistrare) și Cashier for mailcow (planuri plătite prin propriul tău cont Stripe), fiecare cu licența lui și propria perioadă de probă de 30 de zile; pagina arată câte un card de licență pentru fiecare produs, iar pachetul mailcow le acoperă pe toate trei cu o singură cheie.

Rezistă la actualizările mailcow

Toolkit-ul își adaugă fișierele lângă cele ale mailcow și nu modifică niciun fișier urmărit de mailcow: fișierele web sunt excluse din git-ul mailcow, folderul comun stă unde git-ul mailcow nu se uită, iar agentul de pe server și temporizatoarele lui pornesc din systemd. O actualizare mailcow lasă Toolkit-ul la locul lui. Merge și cu mai multe instalări mailcow pe același server.

Cerințe

  • mailcow-dockerized, testat cu 2026-09 și 2026-09a, pe Linux, cu docker compose și systemd.
  • Acces root pe server, cu git, jq, flock, curl, tar și sha256sum instalate.
  • Serverul trebuie să ajungă la medialab.works prin HTTPS (verificarea licenței, perioada de probă, actualizările Toolkit-ului).
  • Pentru SOGo ca o cutie poștală: ALLOW_ADMIN_EMAIL_LOGIN=y în mailcow.conf și dreptul Login as mailbox user pentru admin.
  • Un al doilea nume de gazdă pentru webmail, îndreptat spre mailcow prin același reverse proxy ca interfața mailcow.
  • Pentru copia de rezervă dinaintea actualizărilor: un folder pentru copii de rezervă pe server (--backup-dir).
  • Opțional, ca înregistrările să fie scrise în Cloudflare: un cont Cloudflare care ține zonele domeniilor și un token API.

Întrebări frecvente

De ce mă trimite SOGo înapoi la panoul de admin? Pentru că mailcow păstrează o singură sesiune pe nume de gazdă: cu sesiunea de admin deschisă, sesiunea cutiei poștale nu poate exista lângă ea pe aceeași gazdă. Toolkit-ul deschide SOGo pe un nume de gazdă separat pentru webmail, unde cutia poștală primește propria sesiune. Vezi ghidul.

Modifică fișiere mailcow? Niciun fișier urmărit de mailcow nu e modificat. sudo ./uninstall.sh scoate tot ce a adăugat Toolkit-ul; copiile de rezervă mailcow rămân.

Ce se întâmplă când se termină licența? Funcțiile Toolkit-ului se opresc și mailcow merge ca înainte de Toolkit: butonul SOGo schimbă din nou sesiunea de admin, actualizările se fac prin SSH, iar înregistrările DNS nu mai sunt verificate sau scrise. Nu se șterge nimic, nici în mailcow, nici în Cloudflare. Reînnoiești licența sau introduci o cheie nouă în secțiunea Licență.

Pot actualiza fără copie de rezervă? Dacă instalezi fără --backup-dir, Actualizează acum rulează fără copie de rezervă înainte. Îți recomandăm să setezi un folder pentru copii de rezervă.

Am nevoie de Cloudflare? Nu. Fără date de acces Cloudflare, pagina DNS tot arată înregistrările, le compară cu DNS-ul public și cu un fișier de zonă încărcat de tine și îți dă un fișier de zonă BIND de importat. Cloudflare e necesar doar ca înregistrările să fie scrise singure.

Îmi poate șterge sau strica înregistrările DNS? Doar creează sau actualizează înregistrările pe care le arată și nu șterge nicio înregistrare. Înainte de fiecare modificare se salvează o copie JSON a zonei, iar Anulează aceste modificări o readuce (scoate doar înregistrările create de acea modificare, dacă nu au fost editate între timp). Configurarea automată păstrează politica SPF, DMARC sau TLS-RPT pe care o ai deja.

De ce nu există înregistrare AAAA și nici ip6: în SPF? Pentru că IPv6 e oprit implicit: dacă un server publică AAAA fără PTR IPv6 potrivit, Gmail și alții îi resping e-mailurile trimise prin IPv6. Pornești Folosește IPv6 după ce PTR-ul IPv6 e setat.

Licență

Toolkit-ul este cu sursă deschisă (GPL-3.0), ca mailcow. Ce cumperi este abonamentul pentru versiuni noi, actualizări și suport pentru un server mailcow: Toolkit-ul cu verificarea licenței, fiecare versiune nouă cât timp abonamentul e activ și ajutor când ceva nu merge. Toolkit-ul este format din scripturi shell, PHP și JavaScript, deci ce primești este codul sursă complet. Vezi secțiunea 11 din EULA.

mailcow Toolkit este cod propriu, scris de MediaLab Works; nu conține cod de la terți. Rulează în mailcow-dockerized și folosește funcțiile mailcow (sesiuni, drepturi, update.sh, scriptul de copii de rezervă, crearea aliasurilor); mailcow este un proiect separat cu sursă deschisă (GPL-3.0) al The Infrastructure Company GmbH, vezi Drepturi de autor. Cloudflare este un serviciu separat, folosit doar cu contul și datele tale de acces.