Come installare Modoboa Webmail Server su Ubuntu

Modoboa su Ubuntu: cosa stai davvero mettendo in piedi

Modoboa non è solo una webmail: è una piattaforma completa per gestire dominio, caselle, alias, quota, antispam e accesso amministrativo al servizio mail. Su Ubuntu la scelta sensata è trattarla come un progetto di infrastruttura, non come un semplice pacchetto da installare e dimenticare. Se parti senza una base chiara su DNS, TLS, database e MTA, il risultato è quasi sempre un sistema che “sembra su” ma non consegna posta in modo affidabile.

La strada più pulita è questa: prepari il server, installi i prerequisiti, fai deploy dell’applicazione, colleghi il database, configuri il web server, poi chiudi il cerchio con Postfix e Dovecot. Solo alla fine passi a DNS e test operativi. Se inverti l’ordine, perdi tempo a inseguire sintomi che in realtà arrivano da un layer precedente.

Prerequisiti minimi prima di toccare il sistema

Assumo Ubuntu Server recente, IP statico, hostname FQDN già deciso e accesso root o sudo. Ti serve anche un dominio che controlli, perché senza record DNS corretti il server può funzionare localmente ma fallire appena entra in gioco la posta in uscita o la validazione TLS.

Prima di installare qualunque cosa, verifica che l’host risponda con nome coerente e che l’orologio sia corretto. Nella mail, una deriva temporale minima può far fallire certificati, login e controlli antispam.

Comandi base:

hostnamectl
timedatectl status
ip a
resolvectl status

Controlla che il nome macchina sia un FQDN, per esempio mail.example.com, e che il DNS risolva già quel nome verso l’IP pubblico corretto. Se il record non esiste ancora, crealo adesso: non è un dettaglio estetico, è un prerequisito funzionale.

Pacchetti necessari: base applicativa e componenti mail

La base tipica comprende Python, virtualenv, PostgreSQL o MariaDB, Nginx, Git, compilatori e librerie per moduli Python. Poi serve il mail stack: Postfix per SMTP e Dovecot per IMAP/LMTP. In un setup Modoboa la parte web e la parte mail devono parlarsi senza ambiguità; non basta che i servizi siano installati, devono essere allineati nei percorsi, nei socket e nei permessi.

Installazione di massima:

sudo apt update
sudo apt install -y git python3 python3-venv python3-pip python3-dev \
  build-essential libssl-dev libffi-dev libxml2-dev libxslt1-dev \
  libjpeg-dev zlib1g-dev libpq-dev postgresql postgresql-contrib \
  nginx postfix dovecot-core dovecot-imapd dovecot-lmtpd

Se scegli MariaDB al posto di PostgreSQL, la logica non cambia ma i pacchetti sì. PostgreSQL resta spesso la scelta più lineare per installazioni pulite e prevedibili, soprattutto quando vuoi tenere separati gli schemi applicativi e ridurre sorprese lato encoding e collation.

Database: utente, schema e permessi minimi

Modoboa appoggia la propria configurazione su database. Qui il punto non è solo “farlo partire”, ma evitare privilegi eccessivi. Crea un database dedicato e un utente dedicato, con password robusta gestita fuori dal testo dell’articolo e fuori dalla shell history.

Esempio con PostgreSQL:

sudo -u postgres psql

CREATE DATABASE modoboa;
CREATE USER modoboa WITH ENCRYPTED PASSWORD 'PASSWORD_FORTE_NON_IN_CHIARO';
GRANT ALL PRIVILEGES ON DATABASE modoboa TO modoboa;

Se vuoi fare le cose bene, non lasciare la password in chiaro nel comando: usa un file temporaneo con permessi stretti o un prompt interattivo. Dopo l’installazione, ruota comunque le credenziali se sono finite in cronologia o in ticket interni.

Verifica minima:

sudo -u postgres psql -c "\l" | grep modoboa

Se il database non compare, non andare avanti: il problema è qui, non nel web server.

Deploy dell’applicazione Modoboa

Per l’installazione applicativa conviene lavorare in una directory dedicata, con virtual environment Python separato. L’obiettivo è evitare collisioni con i pacchetti di sistema e rendere il rollback semplice: cancelli il venv, ripristini la config e hai un punto di ritorno chiaro.

Una sequenza tipica è questa:

sudo mkdir -p /srv/modoboa
sudo chown -R $USER:$USER /srv/modoboa
cd /srv/modoboa
python3 -m venv venv
. venv/bin/activate
pip install --upgrade pip setuptools wheel

A questo punto installi Modoboa e i moduli necessari seguendo la versione supportata dalla tua release. Il dettaglio delle versioni cambia nel tempo, quindi non ha senso fissare qui un pin assoluto senza verificare la compatibilità con Ubuntu e con le dipendenze del momento. Il modo corretto è controllare il repository ufficiale del progetto e allineare i pacchetti prima del deploy.

Se il tuo obiettivo è un articolo operativo e non una copia del README, il punto importante è questo: non mischiare installazione applicativa e configurazione di servizio. Prima fai arrivare il codice in locale, poi colleghi database, web server e mail stack. Tenere i passaggi separati rende molto più facile capire dove si rompe qualcosa.

Configurazione iniziale e file di settings

Modoboa usa un file di configurazione applicativa per definire database, host, media, static files e integrazione con i servizi esterni. Qui il rischio classico è fare copia-incolla di esempi presi da ambienti diversi e lasciare riferimenti incoerenti a percorsi o host locali.

Un approccio pulito è tenere il file di settings in una posizione nota e versionabile, per esempio sotto /srv/modoboa, con permessi stretti. Se la struttura del progetto lo consente, separa il file locale da quello di default così un aggiornamento non ti sovrascrive le personalizzazioni.

Elementi da verificare nel file di configurazione:

• host del database corretto
• nome database e utente dedicati
• impostazione del dominio principale
• path per static e media coerenti con Nginx
• URL esterni usati per login e callback

Se vuoi un controllo rapido, cerca i parametri effettivi e confrontali con il servizio in ascolto:

grep -R "DATABASE\|STATIC\|MEDIA\|DOMAIN" /srv/modoboa -n

Nginx come front-end: statici, proxy e TLS

Nginx è la scelta più lineare davanti a Modoboa perché gestisce bene static file, reverse proxy e certificati. L’obiettivo non è complicare il flusso, ma separare il traffico web dalla logica applicativa. Modoboa deve restare dietro un front-end che si occupa di terminare TLS e di esporre solo ciò che serve.

Un blocco server minimale deve almeno fare tre cose: servire i file statici, inoltrare le richieste dinamiche all’app e forzare HTTPS. I dettagli del socket o della porta dipendono dal modo in cui avvii l’applicazione, ma la logica resta invariata.

server {
    listen 80;
    server_name mail.example.com;
    return 301 https://$host$request_uri;
}

Per TLS, usa un certificato valido e rinnovabile automaticamente. Con Let’s Encrypt la verifica fondamentale non è solo “il lucchetto compare”, ma anche che il rinnovo automatico sia già in funzione. Un certificato scaduto su un server mail non è un fastidio grafico: blocca client e fiducia lato utenti.

Verifica rapida del front-end:

sudo nginx -t
sudo systemctl reload nginx
curl -I https://mail.example.com

Atteso: HTTP 200 o redirect coerente, nessun errore di certificato e nessun 502. Se vedi 502, il problema è quasi sempre il collegamento tra Nginx e il processo applicativo, non il certificato.

Postfix: invio e consegna della posta

Modoboa non sostituisce Postfix: lo governa. Postfix resta il motore SMTP che riceve, accetta, inoltra e consegna. Qui la parte delicata è integrare il controllo utenti e domini con il resto della piattaforma senza aprire relay indesiderati.

La configurazione deve garantire che il server non diventi un open relay. Il test minimo è semplice: connessione in SMTP, banner corretto, accettazione solo per domini autorizzati e autenticazione richiesta per l’invio dai client.

Controlli utili:

postconf -n
sudo systemctl status postfix

Se il servizio è attivo ma la posta non parte, guarda prima i log di Postfix e poi i record DNS di SPF, DKIM e MX. Il classico errore è dare per scontato che “la mail non esce” significhi un problema dell’applicazione, quando in realtà il server viene rifiutato dal destinatario per reputazione o allineamento DNS.

Dovecot: IMAP, autenticazione e accesso utenti

Dovecot gestisce l’accesso IMAP e spesso anche il canale di autenticazione per il resto dello stack. Qui devi essere molto preciso su mailbox path, permessi e meccanismo di login. Se il demone parte ma gli utenti non vedono le caselle, di solito il problema è un mismatch tra layout della mailbox e configurazione del servizio.

Controlla che Dovecot ascolti sulle porte previste e che l’autenticazione punti al backend corretto. In fase di test, la verifica minima è un login IMAP da client e la creazione di una mailbox visibile da webmail.

Comandi di controllo:

sudo systemctl status dovecot
sudo dovecot -n

Se sudo dovecot -n mostra configurazioni inattese, fermati e correggi prima di andare oltre. In un servizio mail, un errore silenzioso sui permessi si traduce in caselle vuote o accessi intermittenti, cioè il tipo di guasto più costoso da diagnosticare dopo il go-live.

DNS che devi pubblicare davvero

Per una installazione mail credibile non basta il record A. Devi pubblicare almeno MX, SPF, DKIM e idealmente DMARC. Senza questi record, l’invio può funzionare in laboratorio ma fallire nella pratica o finire in spam con una frequenza fastidiosa.

Schema minimo da controllare:

• A per mail.example.com
• MX del dominio verso mail.example.com
• SPF che autorizzi l’IP di uscita
• DKIM con chiave pubblica nel DNS
• DMARC con policy iniziale prudente

Verifica con strumenti base:

dig +short MX example.com
dig +short A mail.example.com
dig TXT example.com

Se il DNS non è allineato, ogni altro test ha valore limitato. Un server mail senza DNS corretto è come un ufficio con citofono sbagliato: può anche essere aperto, ma nessuno lo trova o si fida a bussare.

Primo avvio: cosa controllare prima di dichiararlo operativo

Il primo avvio non si giudica dal fatto che una pagina si apra. Si giudica da una catena di verifiche: database raggiungibile, app in ascolto, Nginx davanti, login funzionante, invio e ricezione test, certificato valido, DNS pubblicato. Se uno di questi punti manca, l’installazione è incompleta anche se la dashboard appare.

Test pratici da fare subito:

1. Apri l’interfaccia web via HTTPS e verifica che non ci siano warning del browser.
2. Accedi con l’utente amministratore creato durante il setup.
3. Crea un dominio di test e una casella di test.
4. Invia una mail verso un indirizzo esterno e controlla l’esito nei log.
5. Ricevi una mail dall’esterno e verifica l’arrivo in IMAP e in webmail.

Log da tenere sotto mano:

journalctl -u nginx -u postfix -u dovecot -f

Se un passaggio fallisce, non saltare al successivo. Correggi il layer che ha generato l’errore, poi ripeti il test. È il modo più rapido per evitare un’installazione “mezzo viva” che poi si rompe alla prima modifica.

Hardening minimo e manutenzione

Una volta online, pensa subito a hardening e manutenzione. Aggiorna il sistema con cadenza regolare, limita l’esposizione di porte, tieni i backup separati dal server e controlla che i certificati si rinnovino automaticamente. Sul lato applicativo, conserva una copia versionata dei file di configurazione e documenta ogni modifica ai parametri sensibili.

Misure pratiche:

• abilita solo HTTP/HTTPS, SMTP submission, IMAPS e le porte strettamente necessarie
• non esporre pannelli amministrativi non usati
• usa password robuste e ruotale dopo test o migrazioni
• controlla i log di autenticazione per tentativi anomali
• pianifica backup di database, configurazione e mailbox

Per i backup, non limitarti al dump del database. In un servizio mail contano anche configurazioni, chiavi DKIM, file TLS, directory delle mailbox e parametri del web server. Un restore che recupera solo il database ma non le chiavi o i contenuti non è un restore completo.

Problemi tipici e lettura rapida dei sintomi

Se la pagina web dà 502, il problema è quasi sempre il backend applicativo o il socket che Nginx si aspetta di trovare. Se il login funziona ma la posta non arriva, guarda Dovecot e il mapping delle mailbox. Se l’invio fallisce verso l’esterno, controlla Postfix, DNS e reputazione del dominio. Se tutto sembra funzionare ma i client non si autenticano, il punto debole è spesso il TLS o la configurazione IMAP/SMTP submission.

La regola pratica è non confondere il sintomo con il layer. La mail è un sistema a catena: quando qualcosa si rompe, quasi mai è “Modoboa in generale”. È più spesso un singolo anello che non sta facendo il suo lavoro.

Quando fermarsi e chiudere il gap

Ci sono due punti in cui conviene fermarsi e verificare invece di andare avanti per inerzia: la compatibilità esatta della versione Modoboa con la release Ubuntu che stai usando, e la configurazione specifica dei moduli mail legati al tuo layout di dominio. Questi dettagli cambiano nel tempo e non vanno indovinati. Il modo corretto per chiudere il gap è consultare il repository del progetto, la documentazione della release e i log del servizio dopo il primo avvio.

Se vuoi evitare una migrazione a metà, conserva sempre tre elementi: un backup del database, una copia dei file di configurazione e uno snapshot o almeno un punto di restore della macchina. È la differenza tra un cambio controllato e una giornata passata a ricostruire un server da memoria.