Mail per HackInPovo 2.0

In questa repo è contenuto il playbook di Ansible Core che consente l'installazione e la configurazione del mail server usato nell'hacker space

Ho deciso di chiamarlo "melissa", un nome che ricorda la parola "mail" ma che trovo un po' più simpatico di, boh, tipo "mail2". È anche ispirato al fatto che il software che gestisce le mail è chiamato maddy, che è anche un nome di persona.

Ansible Core?

Sì. Praticamente il progetto Ansible si divide in "Ansible Core", che è il software vero e proprio, e "Ansible" o "Ansible Collections", che è Ansible Core più tutta una serie di moduli sviluppati dalla community che estendono le funzionalità built-in del core.

Essendo che uno dei punti chiave di questo servizietto duepuntozero è la semplicità, ho deciso di limitarmi a questo sottoinsieme più controllato di Ansible così da renderne più facile la comprensione, e per avere un ostacolo in più allo sviluppo di un playbook over-engineered.

Il problema

Essendo che le email sono estremamente flessibili e super utilizzate in mille ambienti diversi, tradizionalmente diversi aspetti di un sistema di email sono state implementate da diverse componenti: un Mail Submission/Transfer/Delivery Agent come Postfix, un Message Store come Dovecot, qualcosina per firmare le mail con DKIM, e se proprio proprio vogliamo un componente che filtri lo spam.

Nel setup di infrastrutture email più comuni, tutte queste componenti concettuali sono rappresentate da software diversi. Come pro esiste, almeno teoricamente, una bella separazione di concetti in software diversi, e questo consente di avere una configurazione separata di aspetti separati. In pratica, però, questi diversi componenti sono tradizionalmente molto flessibili e quindi complessi, e ciò rende configurarli uno ad uno particolarmente tedioso.

La soluzione originale adottata dall'hacker space è stato adottare mailcow, una suite che, con l'ausilio dei container, permette di installare tutto in una botta sola. Nonostante questo possa sembrare comodo ed elegante a una prima occhiata, quello che comporta è che l'enorme livello di complessità dei singoli componenti è nascosto, ma non eliminato, ed è pronta ad esplodere nel momento in cui qualcosa non funzioni come dovrebbe. Inoltre, mailcow non ha tra i suoi obiettivi quello di essere una suite minimale, ma include invece un enorme quantitativo di software diversi per poter fornire ogni singola possibile funzionalità immaginabile, anche quando a noi di HackInPovo ciò non si renda necessario. In particolare, queste componenti sono:

• ACME.sh: alternativa a Certbot, idealmente non la vogliamo
• ClamAV: credo sia già disattivato according to Cawa
• Dovecot: ci sta, è il server IMAP più diffuso
• MariaDB: boh ok. Ma idealmente vogliamo unificare la gestione degli account
• Memcached: ???
• Netfilter: ???, andrebbe fatto in un layer superiore
• nginx: perché un server/proxy HTTP?
• Olefy: ClamAV ma diverso
• PHP: ?!?
• Postfix: the goat.
• Redis: perché?
• Rspamd: credo sia ancora attivo, ma realisticamente non ci serve
• SOGo: webmailer, che non ci serve, e CalDAV/CardDav, già fornito da Nextcloud
• Unbound: ci sta, è usato da Postfix
• Watchdog: yet another monitoring system (abbiamo già CheckMK)

Per sistemare 'sto bordello, insomma, si potrebbe decidere di installare singolarmente i singoli componenti che ci servono, ma ciò ci richiederebbe un quantitativo di tempo enorme (e lo dico perché lo faccio per il mio server mail personale). Oppure, si può usare maddy.

Maddy

Maddy è un softwerino scritto in Go che implementa un server mail. Al posto di prendere grossi software già esistenti e cercare di metterli in un unico pacchetto, re-implementa un sottoinsieme delle funzionalità più comuni in un unico software, così che il risultato sia semplice, coeso e coerente.

Viene tutto configurato in un unico file, in maniera abbastanza semplice, e non richiede molta manutenzione. Inoltre, è tutto contenuto in un unico programma, quindi non ci toccherà più di andare a capire quale dei capire 15 servizi di mailcow stia facendo i capricci. Infine, abbandonando il requisito di Docker, possiamo migrare da una macchina virtuale a un più semplice container gestito direttamente da Proxmox.

Maddy permette anche di delegare la gestione degli utenti a un server NetAuth o LDAP, permettendoci, nel lungo periodo, di centralizzare la gestione degli utenti e semplificare la gestione di password e accesso ai servizietti.