mailcow Toolkit — ghid

Înainte să începi

mailcow-dockerized pe Linux (testat cu 2026-09 și 2026-09a), instalat de exemplu în /opt/mailcow-dockerized.
Acces root pe server și aceste comenzi: docker cu docker compose, git, jq, flock, curl, tar, sha256sum, plus systemd.
Acces HTTPS spre medialab.works de pe server (verificarea licenței, perioada de probă, actualizările Toolkit-ului).
Cheia de licență din contul medialab.works sau o adresă de e-mail pentru perioada de probă gratuită de 30 de zile.
Un al doilea nume de gazdă pentru webmail (de exemplu webmail.example.com) în DNS și un reverse proxy care îl poate servi.
Un folder pentru copii de rezervă, de exemplu /srv/backup/mailcow.
Opțional, pentru DNS și Cloudflare: un cont Cloudflare care ține zonele domeniilor tale. Ca să afle adresele publice ale serverului, Toolkit-ul întreabă ip4.mailcow.email și ip6.mailcow.email (ca verificarea DNS a mailcow).

Instalare

Descarci mailcow-toolkit-<versiune>.tar.gz din contul medialab.works, îl dezarhivezi pe serverul mailcow și rulezi, ca root:

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

--mailcow-dir — unde e instalat mailcow-dockerized (implicit /opt/mailcow-dockerized).
--webmail-url — adresa webmail, https:// + numele de gazdă (portul e opțional). Fără ea, butonul SOGo se comportă ca în mailcow-ul standard.
--backup-dir — unde merg copiile de rezervă dinaintea actualizărilor. Fără el, Actualizează acum rulează fără copie de rezervă înainte (instalatorul te avertizează).
--name — doar dacă ai mai multe instalări mailcow pe același server: câte un nume pentru fiecare (litere, cifre și -).

Instalatorul pune fișierele web în data/web al mailcow (excluse din git-ul mailcow), folderul comun în data/hooks/phpfpm/.mlw-toolkit, agentul de pe server în /usr/local/sbin/mlw-mailcow-agent-<nume>, setările în /etc/mlw-mailcow-toolkit/<nume>.conf, o copie a versiunii instalate în /var/lib/mlw-mailcow-toolkit/<nume>/package și pornește cinci unități systemd: una care rulează cererile din interfața de admin, un temporizator care verifică licența și caută o versiune nouă de mailcow la pornirea serverului și o dată pe zi, mlw-mailcow-rdns-<nume>.timer, care verifică DNS-ul invers la fiecare 6 ore, și mlw-mailcow-domains-<nume>.timer, care caută domenii mailcow noi la fiecare 2 minute (nu face nimic cât timp configurarea automată în Cloudflare și asistentul pentru domenii noi sunt amândouă oprite) și, din 0.4.0, mlw-mailcow-accounts-<nume>.timer, care rulează sarcinile Sign-up for mailcow și Cashier for mailcow la fiecare 5 minute. Din 0.4.0 pachetul instalează și Sign-up și Cashier (cu tabelele lor mlw_su_* și mlw_ca_* în baza de date a mailcow); rămân oprite până când fiecare are licența lui. La final reîncarcă php-fpm și verifică licența; cât timp licența nu e activă, îți spune să deschizi secțiunea Licență.

Actualizarea Toolkit-ului: din secțiunea Licență (vezi mai jos) sau rulând din nou install.sh din versiunea nouă. Adresa de webmail și folderul pentru copii de rezervă de dinainte se păstrează dacă nu le mai dai. Actualizarea la 0.3.0 din secțiunea Licență pornește și cele două temporizatoare noi; pagina DNS și Cloudflare apare apoi în meniul System.

Licență și perioadă de probă

Deschizi System > Actualizări (Toolkit) (doar pentru admini). Secțiunea Licență de sus arată starea licenței și merge și fără licență:

Introduci cheia de licență și apeși Activează. Cheia e în contul medialab.works.
Sau pornești perioada de probă gratuită de 30 de zile: scrii adresa de e-mail, alegi lunar sau anual pentru după perioada de probă și apeși Pornește perioada de probă. Deschizi pagina de plată Stripe din linkul afișat: cardul se cere acolo și nu se debitează în cele 30 de zile. Dacă adresa are deja cont pe medialab.works, linkul pleacă pe e-mail la ea. Pagina activează apoi 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.
Din 0.4.0 pagina arată câte un card de licență pentru fiecare produs (Licență · mailcow Toolkit, Licență · Sign-up for mailcow, Licență · Cashier for mailcow), fiecare cu cheia și perioada de probă proprii. O cheie de pachet mailcow se introduce în fiecare card. Actualizările pachetului se pot porni din cardul oricărui produs cu licență validă. Vezi ghidul Sign-up și ghidul Cashier.
Cu licența activă, secțiunea arată cheia (parțial ascunsă), tipul, data de sfârșit, ultima verificare, până când merge Toolkit-ul fără conexiune și id-ul acestui server. Verifică acum verifică imediat (de cel mult două ori pe oră, împreună cu actualizările și revenirile).
Scoate de pe acest server (după ce bifezi confirmarea) eliberează licența ca s-o folosești pe alt server mailcow; aici Toolkit-ul se oprește.

Licența se verifică la pornirea serverului și o dată pe zi. Dacă medialab.works nu poate fi contactat, Toolkit-ul funcționează 7 zile de la ultima verificare reușită.

Fără licență validă (încă nu ai, a expirat, a fost scoasă, mutată pe alt server sau neverificată de mai mult de 7 zile) 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 pagina arată doar secțiunea Licență. Nu se șterge nimic.

Actualizarea sau revenirea Toolkit-ului

Cu licență validă, secțiunea Licență arată versiunea instalată și ultima versiune publicată:

Actualizează Toolkit-ul la x.y.z descarcă arhiva semnată de pe medialab.works, îi verifică mărimea și SHA-256 și o dă agentului de pe server, care o verifică din nou, rulează install.sh al acelei versiuni și păstrează versiunea anterioară: dacă instalarea eșuează, se reinstalează versiunea anterioară. Pagina arată progresul și se reîncarcă la final.
Revino la x.y.z face același lucru cu versiunea anterioară permisă de licență.

Dacă licența nu acoperă versiunea instalată (de exemplu o licență pe viață a cărei perioadă de actualizări s-a încheiat înaintea acelei versiuni), Toolkit-ul se oprește, iar secțiunea Licență oferă Revino la ultima versiune permisă de licență și linkul pentru reînnoirea abonamentului de actualizări.

Numele de gazdă pentru webmail

SOGo ca o cutie poștală merge doar pe alt nume de gazdă decât cel al interfeței mailcow, pentru că browserul păstrează câte un cookie de sesiune pe fiecare nume de gazdă.

Îndrepți numele de gazdă pentru webmail (de exemplu webmail.example.com) spre serverul tău, în DNS.
În reverse proxy îl servești exact ca interfața mailcow: același backend, aceleași antete. E același mailcow, doar sub alt nume.
Îi dai un certificat TLS, ca interfeței.

Activarea SOGo ca o cutie poștală

În mailcow.conf setezi ALLOW_ADMIN_EMAIL_LOGIN=y, apoi aplici schimbarea din folderul mailcow cu docker compose up -d.
Verifici că adminul are dreptul Login as mailbox user („Conectează-te ca utilizator al cutiei poștale”).

Apoi, în E-Mail > Configurație, fila Cutii poștale, butonul SOGo de lângă o cutie deschide o filă nouă pe gazda de webmail, conectată în SOGo ca acea cutie. Fila de admin rămâne conectată. Legătura din spatele butonului merge o singură dată și doar 60 de secunde; dacă o filă arată This link has expired, apeși din nou SOGo din lista de cutii.

Butonul e doar pentru administratorul platformei: adminii de domeniu păstrează butonul SOGo al mailcow. Cutiile inactive sunt refuzate.

Ce se jurnalizează: fiecare folosire apare în jurnalul de conectări mailcow al acelei cutii, ca o conectare SSO, și în jurnalul de audit al Toolkit-ului (cine a deschis ce cutie, când și de la ce adresă).

Actualizarea mailcow

Cu licență validă, System > Actualizări (Toolkit) arată sub secțiunea Licență:

versiunea instalată și ultima verificare (La zi sau Actualizare disponibilă, cu modificările noi);
ultima operație (în curs, terminată sau eșuată) cu mesajul ei;
jurnalul ultimei actualizări.

Verifică acum caută imediat o versiune nouă; altfel serverul verifică o dată pe zi.

Actualizează acum e disponibil când ultima verificare a găsit o versiune nouă. După ce confirmi, rulează, în ordine:

o copie de rezervă pentru crypt, redis, rspamd, postfix și mysql în folderul pentru copii de rezervă, cu scriptul de copiere al mailcow; copiile mai vechi de 14 zile se șterg. Dacă copia de rezervă eșuează, actualizarea se oprește și nu se schimbă nimic;
update.sh-ul mailcow;
o așteptare de până la 5 minute, până când toate containerele rulează și interfața răspunde.

În timpul actualizării containerele repornesc, deci poșta și interfața sunt indisponibile câteva minute. Pagina continuă să arate jurnalul și se reîncarcă singură când serverul revine. Când actualizarea se termină, pleacă un e-mail la adresa pentru notificări.

Notificări

Pe aceeași pagină, la Notificări, scrii adresa care primește e-mailurile și salvezi. Serverul trimite apoi un singur e-mail pe versiune nouă de mailcow (nu unul pe zi) și unul când se termină o actualizare. O adresă goală oprește e-mailurile.

DNS și Cloudflare

Deschizi System > DNS și Cloudflare (doar pentru admini). Fără licență validă pagina arată doar un mesaj și nu rulează nimic în fundal.

Starea domeniilor

Sus, un rând de sumar (câte domenii sunt critice sau au avertismente) și un selector Domeniu cu fiecare domeniu și domeniu alias din mailcow, cele mai grave primele, fiecare cu starea lui. Pagina ține minte ultimul domeniu ales.

critic — e-mailurile nu pot fi livrate sau trimise ori ajung în spam: înregistrarea A (sau AAAA) a serverului de e-mail, MX, SPF, DKIM sau DMARC lipsesc, sunt greșite sau trec prin proxy; mailcow nu are cheie DKIM; DNS-ul invers al serverului e greșit; sau SOGo nu cunoaște încă domeniul (vezi SOGo și domeniile noi mai jos).
avertisment — lipsesc înregistrări opționale: autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT.
totul e bine — domeniul are tot ce îi trebuie.

Vederea domeniului arată Ce trebuie rezolvat, întâi problemele critice, cu motivul și cum se repară, apoi fișierul de zonă, acțiunile Cloudflare ale domeniului, asistentul și tabelul complet al înregistrărilor. Stările se reîmprospătează la fiecare 10 minute, în fundal; Verifică din nou verifică imediat domeniul ales. Setările pentru toate domeniile (DNS invers, datele de acces și automatizarea Cloudflare, porturile serviciilor, asistentul, SOGo) sunt în secțiuni pliabile mai jos.

Înregistrările fiecărui domeniu

Tabelul înregistrărilor domeniului ales arată ce îi trebuie în mailcow, după verificarea DNS a mailcow:

obligatorii: înregistrarea A a MAILCOW_HOSTNAME, la domeniul în a cărui zonă se află numele de gazdă (doar DNS în Cloudflare, pentru că SMTP și IMAP nu pot trece prin proxy-ul Cloudflare); MX 10 → MAILCOW_HOSTNAME; SPF; DKIM cu selectorul și cheia din mailcow; DMARC;
recomandate: CNAME-urile autodiscover și autoconfig → MAILCOW_HOSTNAME (doar DNS; e acceptată și o înregistrare A cu IP-ul serverului); înregistrările SRV _autodiscover, _imaps, _submissions, _submission, _pop3s (când POP3 e permis), _caldavs și _carddavs cu un TXT path=/SOGo/dav/ (când SOGo e pornit); cu MTA-STS activ pentru domeniu în mailcow, CNAME-ul mta-sts, TXT-ul _mta-sts și înregistrarea TLS-RPT _smtp._tls;
pentru un domeniu alias: MX, SPF, DKIM (rândul rămâne necunoscut până când mailcow are o cheie pentru el), DMARC și, cu MTA-STS, TXT-urile _mta-sts și _smtp._tls.

SPF-ul propus este v=spf1 ip4:<IPv4> -all. Când există deja un SPF care nu acoperă serverul, propunerea îi adaugă adresa serverului și păstrează restul; când se bazează pe include sau redirect, pagina îți spune să-l verifici.

DMARC: o înregistrare DMARC validă pe care o ai deja rămâne cum e. Altfel propunerea este v=DMARC1; p=quarantine;, cu rua=mailto:dmarc@<domeniu> (sau postmaster@<domeniu>) doar dacă adresa există în mailcow. Rapoartele TLS-RPT merg la tls-rpt@ sau postmaster@ al domeniului.

Fiecare rând se compară cu trei surse: DNS-ul public, o zonă importată (dacă ai încărcat una) și zona Cloudflare (cu date de acces). Starea este OK, lipsește, diferit, prin proxy — trebuie doar DNS, de reparat manual (de exemplu înregistrări A unde ar trebui CNAME-ul sau mai multe înregistrări SPF) sau necunoscut (mailcow nu are încă o cheie DKIM sau IPv4-ul public nu e încă cunoscut).

Fișierul de zonă: export și import

Descarcă fișierul de zonă BIND salvează înregistrările domeniului ca fișier de zonă. În Cloudflare îl imporți din DNS > Records > Import and Export > Import DNS records: înregistrările care trebuie să rămână doar DNS au cf_tags=cf-proxied:false. Rândurile încă necunoscute nu intră în fișier.
Compară cu un fișier de zonă citește un export Cloudflare (DNS > Records > Import and Export > Export) sau orice fișier de zonă BIND, de până la 1 MB, și adaugă în comparație coloana Zonă importată. Uită fișierul importat îl scoate.

IPv4 și IPv6

Implicit Toolkit-ul lucrează doar cu IPv4: fără înregistrare AAAA, doar ip4: în SPF, iar DNS-ul invers IPv6 nu se verifică. Un server care publică AAAA fără PTR IPv6 potrivit își vede e-mailurile trimise prin IPv6 respinse de Gmail și de alții. După ce PTR-ul IPv6 al serverului e setat, pornești Folosește IPv6 (publică AAAA, SPF ip6, verifică DNS-ul invers IPv6) și salvezi.

Porturile serviciilor

Cardul Porturile serviciilor (înregistrări SRV) setează porturile pe care le anunță înregistrările SRV: IMAPS (993), Submission (STARTTLS, 587), SMTPS (465), POP3S (995) și HTTPS (443, pentru autodiscover, CalDAV și CardDAV). Fiecare câmp e opțional (1–65535). Gol, portul vine din mailcow.conf când acolo e un număr simplu, sau este portul standard când mailcow.conf leagă o adresă precum 127.0.0.1:12587 (în față e un proxy sau NAT); HTTPS gol folosește portul paginii de administrare. Sub fiecare câmp pagina arată portul folosit și de unde vine. Exportul, comparația și Cloudflare (manual și automat) folosesc toate aceste porturi.

Datele de acces Cloudflare

Acțiunile Cloudflare ale unui domeniu (coloana live, previzualizarea și aplicarea, Configurează acum) apar doar când datele de acces salvate funcționează acum și pot modifica DNS-ul în zona acelui domeniu; altfel pagina spune de ce (fără date de acces, conexiune refuzată, zona nu e în cont sau în resursele de zonă ale tokenului ori lipsește Zone > DNS > Edit). Rulează asistentul merge și fără Cloudflare.

În cardul Cloudflare alegi una dintre:

Token API (recomandat): în Cloudflare, My Profile > API Tokens > Create Token, cu Zone > DNS > Edit și Zone > Zone > Read pe toate zonele. Adaugi Zone > Zone > Edit doar dacă Toolkit-ul poate crea zonele lipsă. Dacă un astfel de token ajunge la altcineva, poate modifica doar înregistrări DNS și poate fi revocat separat.
Global API Key cu e-mailul contului: merge și așa, dar cheia poate face orice în tot contul Cloudflare (facturare, membri, toate produsele). O folosești doar dacă accepți acest risc.

Verifică și salvează verifică întâi datele de acces la Cloudflare. Se păstrează criptat (AES-256-GCM) în folderul Toolkit-ului de pe serverul tău; cheia stă în redis-ul mailcow, nu lângă fișier, deci o copie a folderului sau a copiilor de rezervă mailcow nu le dezvăluie. Nu se mai afișează niciodată: pagina arată doar tipul și ultimele 4 caractere. Șterge datele de acces le șterge și oprește configurarea automată. Datele de acces rămân pe serverul tău și se trimit doar către API-ul Cloudflare.

Aplicarea înregistrărilor în Cloudflare

Alegi domeniul. Înregistrările obligatorii și cele afișate ca fiind prin proxy sunt bifate; le bifezi sau debifezi pe celelalte.
Previzualizează modificările în Cloudflare arată ce s-ar crea sau actualiza, cu valoarea de acum și cea de după.
Aplică în Cloudflare salvează întâi o copie JSON a întregii zone, apoi creează sau actualizează doar acele înregistrări. Nu se șterge nimic. Dacă zona s-a schimbat de la previzualizare, nu se aplică nimic și previzualizezi din nou; o previzualizare expiră după 15 minute.

Fiecare copie apare la Copii Cloudflare: Descarcă salvează JSON-ul, Anulează aceste modificări întoarce acea modificare (înregistrările actualizate primesc valorile vechi; cele create se șterg, doar dacă nu s-au schimbat între timp). Fiecare aplicare și anulare se scrie în jurnalul de audit al Toolkit-ului.

Configurarea automată a domeniilor noi

Cu datele de acces salvate, pornești Configurează singur în Cloudflare domeniile noi din mailcow. Apoi, în circa 2 minute după ce adaugi un domeniu sau un domeniu alias în mailcow (din interfață sau prin API), Toolkit-ul îi pune înregistrările în zona Cloudflare existentă:

așteaptă până la 10 minute cheia DKIM a mailcow; fără ea pune celelalte înregistrări și adaugă DKIM mai târziu (reîncearcă în fiecare oră);
înregistrările lipsă se creează, cele greșite se actualizează; înregistrarea A a serverului de e-mail și CNAME-urile se pun doar DNS;
înregistrările pe care nu le gestionează nu se șterg niciodată; o politică SPF, DMARC sau TLS-RPT existentă și diferită e lăsată neschimbată (politică existentă) și raportată (previzualizarea manuală o poate actualiza);
înainte de fiecare modificare se salvează o copie a zonei, ca la aplicarea manuală;
dacă zona nu există în Cloudflare, domeniul arată lipsește zona. Cu Creează zona în Cloudflare dacă nu există (necesită Zone > Zone > Edit sau Global API Key), Toolkit-ul o creează și afișează serverele de nume Cloudflare de setat la registrar. Când datele de acces văd mai multe conturi Cloudflare, Contul Cloudflare pentru zonele noi alege contul (implicit primul);
cu Trimite e-mail la adresa de notificări când configurarea eșuează, un eșec pleacă pe e-mail la adresa de la Notificări din pagina Actualizări (Toolkit); Toolkit-ul reîncearcă după 15 minute.

Domeniile care există deja când pornești opțiunea nu sunt atinse: folosești Configurează acum lângă un domeniu ca să-l configurezi la fel.

Asistentul pentru domenii noi

Cardul Asistent pentru domenii noi: adrese de rol creează, pentru fiecare domeniu nou din mailcow, adresele de rol ca aliasuri mailcow, deci nu se socotesc în limita de cutii poștale a domeniului:

adresele: postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, fiecare opțională, plus părțile locale proprii (separate prin virgulă);
Destinație (toate adresele de rol): unde ajung; fiecare domeniu poate avea propria destinație în vederea lui (gol = cea globală);
dmarc@ și tls-rpt@ pot merge la o adresă separată pentru rapoarte;
noreply@ folosește „aruncă fără răspuns” din mailcow (null@localhost): e-mailurile către ea sunt acceptate și aruncate.

Pornești Creează singur adresele de rol pentru domeniile noi (cere o destinație). Asistentul rulează înaintea configurării Cloudflare, deci înregistrările DMARC și TLS-RPT ale unui domeniu nou își trimit rapoartele la dmarc@ și tls-rpt@ ale lui. O adresă care există deja ca cutie poștală sau alias nu e atinsă niciodată: e sărită și raportată. Domeniile alias sunt sărite, pentru că mailcow le leagă deja de adresele domeniului țintă. Aliasurile se creează prin funcțiile mailcow, deci apar în jurnalul mailcow. Domeniile care existau când ai pornit asistentul nu sunt atinse: folosești Rulează asistentul lângă un domeniu.

SOGo și domeniile noi

SOGo citește domeniile mailcow la pornire. Un domeniu adăugat mai târziu nu e cunoscut de SOGo, așa că cutiile lui poștale primesc „Unauthorized” în SOGo și la butonul SOGo al Toolkit-ului până când SOGo repornește (căutarea eșuată rămâne și în memcached).

Cu licență validă, Toolkit-ul verifică la fiecare 2 minute dacă SOGo cunoaște toate domeniile mailcow. Când lipsește unul, repornește doar containerul SOGo și golește memcached, la circa 3 minute după primul domeniu lipsă (așa că mai multe domenii noi împart o singură repornire) și cel mult o dată la 10 minute: în practică în circa 3–10 minute de la adăugarea domeniului. Sesiunile de webmail se întrerup câteva secunde. Fiecare repornire se scrie în jurnalul de audit.

Cât timp un domeniu așteaptă, pagina DNS arată un avertisment cu butonul Repornește SOGo (același buton e și în secțiunea SOGo, cu ultima repornire). Dacă bifezi opțiunea mailcow Restart SOGo când adaugi domeniul, SOGo îl cunoaște imediat și nu mai urmează a doua repornire.

DNS invers (PTR)

Celelalte servere de e-mail verifică dacă fiecare IP public al serverului tău are o înregistrare PTR egală cu MAILCOW_HOSTNAME și dacă MAILCOW_HOSTNAME se rezolvă înapoi la același IP (DNS invers confirmat). Toolkit-ul verifică asta la fiecare 6 ore pentru fiecare IPv4 public (și IPv6, cu Folosește IPv6); Verifică acum din pagina DNS o rulează imediat.

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. Fără Folosește IPv6, o adresă IPv6 nu îl declanșează niciodată.

Cum se repară: înregistrarea PTR a unui IP ține de cel care deține IP-ul, nu de zona ta DNS. O setezi în panoul furnizorului de hosting sau VPS (de obicei „Reverse DNS” sau „PTR” lângă IP) sau o ceri ISP-ului, exact la MAILCOW_HOSTNAME. Apoi verifici dacă MAILCOW_HOSTNAME are o înregistrare A cu același IP (doar DNS în Cloudflare).

Serverul își află adresele publice prin ip4.mailcow.email / ip6.mailcow.email, altfel din interfețele de rețea. În spatele unui NAT sau cu mai multe adrese, le treci în RDNS_IPS (vezi Setări).

Setări

/etc/mlw-mailcow-toolkit/<nume>.conf (numele implicit e default) conține:

BACKUP_DIR — folderul pentru copii de rezervă (gol = fără copie de rezervă înainte de actualizare, nerecomandat);
BACKUP_COMPONENTS — ce intră în copia de rezervă, implicit crypt redis rspamd postfix mysql;
BACKUP_KEEP_DAYS — câte zile se păstrează copiile de rezervă, implicit 14;
RDNS_IPS — IP-urile publice verificate pentru DNS-ul invers, separate prin spațiu, de exemplu RDNS_IPS="203.0.113.10" (gol = adresele găsite automat);
SOGO_DELAY și SOGO_MIN_GAP — așteptarea înainte de repornirea SOGo pentru un domeniu nou și timpul minim între două reporniri, în secunde (implicit 180 și 600).

Modificările tale din acest fișier se păstrează când reinstalezi sau actualizezi Toolkit-ul din secțiunea Licență; doar BACKUP_DIR se schimbă, și doar dacă dai --backup-dir. Alegerile din DNS și Cloudflare se salvează din pagină, nu în acest fișier, și se păstrează.

Dezinstalare

sudo ./uninstall.sh --mailcow-dir /opt/mailcow-dockerized

Oprește și scoate unitățile systemd (inclusiv temporizatoarele), setările, agentul, copia păstrată a Toolkit-ului și fișierele web și curăță lista de excluderi din git-ul mailcow. Se scoate și folderul comun, cu datele de acces Cloudflare criptate și copiile zonelor Cloudflare: descarci înainte copiile pe care vrei să le păstrezi. Înregistrările DNS din Cloudflare rămân cum sunt. Backup-urile mailcow rămân. Tabelele Sign-up și Cashier rămân în baza de date a mailcow, iar cutiile poștale, domeniile și administratorii de domeniu creați prin ele rămân în mailcow. Adaugi --name dacă ai instalat cu un nume. Apeși întâi Scoate de pe acest server în secțiunea Licență dacă vrei să folosești licența pe alt server.

Probleme frecvente

Butonul SOGo îmi schimbă tot sesiunea de admin. La instalare nu s-a dat adresa de webmail, adresa de webmail are același nume de gazdă ca interfața sau conectarea ca o cutie poștală nu e permisă (ALLOW_ADMIN_EMAIL_LOGIN=y și dreptul Login as mailbox user). Rulezi din nou install.sh cu --webmail-url și verifici cele două setări.

Pagina de actualizări spune că agentul de pe server nu e instalat sau nu rulează. Rulezi din nou install.sh; verifici systemctl status mlw-mailcow-agent-default.path.

Pagina arată doar secțiunea Licență. Licența nu e validă: mesajul de sus spune de ce (încă nu ai cheie, a expirat, a fost scoasă sau mutată, ori nu a fost verificată de mai mult de 7 zile). Pentru ultimul caz verifici că serverul ajunge la https://medialab.works, apoi apeși Verifică acum.

Actualizarea a eșuat. Pagina arată la ce pas (copia de rezervă, update.sh sau verificarea containerelor) și păstrează jurnalul. După o copie de rezervă eșuat nu s-a schimbat nimic. După un update.sh sau o verificare a containerelor eșuate, citești jurnalul și rezolvi cauza cum ai face după un update.sh rulat de mână.

Lângă meniul System e un ! roșu. Verificarea DNS-ului invers a eșuat: deschizi System > DNS și Cloudflare, secțiunea DNS invers (PTR) al serverului, ca să vezi ce IP și de ce. Setezi PTR-ul la furnizorul de hosting / VPS sau la ISP, apoi apeși Verifică acum.

Cloudflare a refuzat datele de acces. Verifici drepturile tokenului (Zone > DNS > Edit și Zone > Zone > Read pe toate zonele) sau, pentru Global API Key, e-mailul contului. Mesajul primit de la Cloudflare apare în pagină.

Un domeniu arată „lipsește zona”. Domeniul nu e o zonă în contul Cloudflare pe care îl văd datele de acces. Îl adaugi în Cloudflare sau pornești Creează zona în Cloudflare dacă nu există; Toolkit-ul reîncearcă în fiecare oră, sau apeși Configurează acum.

Înregistrarea SPF sau DMARC a fost „lăsată neschimbată (politică existentă)”. Configurarea automată nu înlocuiește niciodată o politică pe care o ai deja. Alegi domeniul, bifezi înregistrarea și folosești Previzualizează modificările în Cloudflare dacă vrei valoarea Toolkit-ului.

Cutiile poștale ale unui domeniu nou primesc „Unauthorized” în SOGo. SOGo nu cunoaște încă domeniul: pagina DNS arată un avertisment; aștepți câteva minute repornirea automată sau apeși Repornește SOGo.

N-am primit niciun e-mail. Verifici că ai salvat o adresă la Notificări; pleacă un e-mail pe versiune nouă, nu în fiecare zi.