Posta aziendale alternativa a Google Workspace e Microsoft 365?

01Lo stack tecnico, per davvero

La posta aziendale che gestiamo è fatta di componenti noti e boring — nel senso migliore del termine. Niente magia, niente SaaS di cui non si vedono le viscere. Lo stack produzione, identico per tutti i clienti salvo dimensionamento:

• Postfix come MTA (SMTP in/out). Configurato con TLS obbligatorio in ingresso da client autenticati, opportunistic TLS verso il resto del mondo, header rewriting per la pulizia delle informazioni interne, submission su 587 con SASL auth.
• Dovecot come server IMAP/POP3. Maildir su filesystem ZFS, indicizzazione con fts-xapian per la ricerca full-text rapida anche su caselle da decine di GB, sieve per filtri lato server.
• Rspamd come filtro anti-spam content-based integrato in Postfix via milter. Bayes per-utente addestrato continuamente, DKIM signing in uscita, DMARC enforcement in ingresso.
• Proxmox Mail Gateway (PMG) come gateway dedicato davanti ai mail server — la descrizione completa è al punto 02.
• ZFS per lo storage mail: snapshot giornalieri automatici, compressione LZ4 (tipicamente 2,2× sul traffico email reale), replicazione asincrona verso datacenter secondario italiano per disaster recovery.
• Webmail opzionale: Roundcube per l'uso base, SOGo se serve groupware completo (calendari, rubrica condivisa, ActiveSync per mobile).

Backup: ogni casella è parte di un job Proxmox Backup Server con retention granulare (daily 14, weekly 8, monthly 12). Ripristino a granularità di singolo messaggio, non solo di casella intera.

02Proxmox Mail Gateway come filtro

PMG è un gateway mail dedicato, posto come primo hop MX pubblico davanti ai server Postfix veri. Il vantaggio architetturale è che tutto il traffico spazzatura viene fermato prima di toccare lo storage principale — protegge risorse e isola i mail server da attacchi volumetrici.

Cosa fa concretamente PMG:

• Anti-spam multi-livello: RBL/DNSBL, SPF/DKIM/DMARC validation, greylisting selettivo, SpamAssassin + regole custom, analisi bayesiana condivisa.
• Anti-virus: ClamAV con signature aggiornate ogni 30 minuti, quarantena automatica, scansione archivi compressi.
• Anti-phishing: URL reputation check, analisi header per spoofing, quarantena su match DMARC failure con policy reject.
• Statistiche settimanali: report automatico per admin del cliente con volumi, top sender, top recipient, spam block rate, falsi positivi segnalati. Utile per dimostrare al CDA che la cosa funziona e per capacity planning.
• Cluster HA: due nodi PMG in alta disponibilità con sincronizzazione delle regole e della quarantena. Se uno muore, l'altro prende il traffico senza perdita di email.

Un effetto collaterale positivo: PMG gestisce la quarantena con un portale per gli utenti finali (stile whitelist/blacklist self-service), togliendo lavoro all'IT interno del cliente.

03SMTP relay per applicativi

Quasi tutte le aziende hanno applicativi che devono spedire email: gestionali, ERP, CRM, sistemi di ticketing, monitoraggi, notifiche automatiche. Esponiamo un servizio SMTP relay autenticato dedicato con caratteristiche pensate per questo uso:

• Autenticazione SASL con credenziali per-applicativo (no utenti umani sullo stesso canale).
• TLS forced in submission (587 con STARTTLS, o 465 implicit TLS). Niente plaintext.
• Rate limiting per credenziale (es. 100/min, 5000/ora) per limitare il danno in caso di credenziali compromesse.
• DKIM signing automatico con il dominio del mittente — l'applicativo non deve sapere nulla di crittografia.
• Webhook per bounce handling: i bounce vengono parserizzati e inviati via HTTPS a un endpoint del cliente. L'applicativo sa subito quali indirizzi sono morti, senza dover aprire mailbox di return-path.
• Log strutturati accessibili via API read-only per i 90 giorni, utili per debugging e audit.

04IMAP, retention, quota

Su Google Workspace e Microsoft 365 la retention delle email è governata da policy che costano (Vault, Purview) e che sono comunque limitate dalle regole del vendor. Qui decidete voi, perché il filesystem è vostro. Esempio di configurazione tipica:

Cartella	Retention	Note operative
INBOX	Indefinita	Nessuna cancellazione automatica, quota soft a 25 GB alert, hard 50 GB
Cestino	90 giorni	Purge automatico dopo 90gg, prima notifica utente
Archivio	1 anno (o più)	Sieve sposta automaticamente messaggi > 90gg da INBOX
Spam	30 giorni	Purge automatico, esempi pescati tramite report PMG
Legal hold	Configurabile (anni)	Immutabile via ACL, solo admin può rimuovere, log audit

Le quote sono configurabili per singola casella o per dominio. La compressione ZFS lavora a livello blocco — nella pratica una quota "25 GB logici" occupa 11-12 GB reali su disco.

05GDPR e sovranità dei dati

Questa è la parte che negli ultimi due anni motiva di più le migrazioni che vediamo. Il punto non è ideologico, è legale ed economico:

• Infrastruttura fisica in Italia: tutti i mail server e i backup risiedono in datacenter italiani. Niente US-hosted, niente Ireland, niente "EU region" di un provider statunitense.
• Nessun trasferimento extra-UE: non ci sono Standard Contractual Clauses da firmare, non ci sono impatti Schrems II da gestire, non dovete spiegare al DPO cosa fa un'azienda statunitense con i metadati.
• DPA su richiesta: forniamo Data Processing Agreement ai sensi dell'art. 28 GDPR su carta intestata, firmato, con i sub-responsabili elencati puntualmente (pochi, italiani).
• Log conservati solo per security: i log SMTP e IMAP servono a tracciare abusi e incident response, retention 90 giorni, poi purge automatico. Non esiste alcuna profilazione dei contenuti.
• Cifratura at-rest: ZFS dataset cifrati con chiavi gestite in HSM. Il provider infrastruttura non ha accesso ai contenuti.

06Migrazione da Google/MS

Il timore ricorrente è "perdiamo email" o "gli utenti staranno fermi un giorno". Entrambi i problemi sono risolti, se la migrazione è fatta bene:

• IMAP-to-IMAP sync: usiamo imapsync per copiare lo storico delle caselle dal provider sorgente al nostro Dovecot prima del cutover. Il sync gira anche per giorni in background, senza impatto sull'operatività.
• MX swap atomico: al momento del cutover cambiamo il record MX su Cloudflare (TTL abbassato a 300s 24h prima). La nuova posta arriva sui nostri server istantaneamente.
• Delta sync post-cutover: un'ultima passata di imapsync copia eventuali messaggi arrivati sulla sorgente durante la finestra di swap.
• Downtime utente: zero. Il client del giorno dopo punta ai nuovi IMAP/SMTP, ma legge lo stesso storico e gli stessi filtri.
• Formazione utenti: 2h in videoconferenza con screen share, tipicamente sufficienti per Roundcube/SOGo e per la riconfigurazione Outlook/Thunderbird/Apple Mail.

07Quando Google o Microsoft restano la scelta giusta

Per onestà — non è sempre la scelta giusta migrare. Casi in cui consigliamo di restare:

• Usate Teams o Meet come spina dorsale della collaborazione (videochiamate, canali, file condivisi integrati). La posta è il 20% del valore, il resto vale il canone.
• Avete Microsoft 365 E5 con compliance tools attivi (Purview, Defender for Office, eDiscovery avanzato) su cui il legale interno ha costruito processi specifici. Ricreare quelle funzionalità fuori da E5 è costoso.
• Usate pesantemente Google Workspace come piattaforma (Apps Script, Sheets come mini-database aziendali, integrazioni con Google Identity). La posta è un cittadino di quella piattaforma.
• Organizzazione molto distribuita geograficamente con policy di device management avanzata — le feature di gestione endpoint di Intune o di Google Admin sono strumenti veri, non chiacchiere.

In questi casi la cosa più utile che facciamo è aiutare a negoziare correttamente il contratto e ottimizzare le licenze (quasi sempre si scopre di pagare troppe E3/E5 per utenti che basterebbero con Business Standard). Non proviamo a spostare a tutti i costi.