Un pinguino per postino

Introduzione

La posta elettronica è diventata, per le ditte come per il navigatore occasionale, un servizio imprescindibile. Questo articolo vuole essere il primo di una serie dedicata ai mail server, a partire della configurazione dei servizi basilari smtp e pop3, fino ad arrivare a qualcosa di un po' più avanzato, ad esempio web-mail e mailing list.

Sendmail, Postfix, qmail...

In passato, parlare di mail server linux era equivalente a parlare di Sendmail, il più noto e diffuso software SMTP per *nix. Nonostante questa sua diffusione, non si può dire che Sendmail godesse di buona fama in quanto a sicurezza...anche se le ultimissime versoni hanno subìto un pesante lavoro di riprogettazione, ed ora sono molto affidabili! Ma fu questa fama di "mail server bacato" che, in passato, spinse alcuni virtuosi a scrivere da zero un nuovo software SMTP interamente pensato in funzione della sicurezza. E fu così che nacquero Postfix e Qmail: l'idea che sta alla base è avere un programma di facile configurazione e amministrazione, con potenti funzionalità di sicurezza e filtri anti-spamming, stabile e veloce.
Nell'articolo tratteremo di Postfix, scaricabile direttamente dal sito www.postfix.org o da uno dei numerosi mirror. Anche se ormai molte distribuzioni lo includono già nei CD in forma di binario precompilato, per motivi "didattici" lo installeremo partendo direttamente dai sorgenti.
Una piccola nota per gli utenti RedHat: per poter compilare i sorgenti, sarà necessario installare prima il pacchetto db3-devel (che potrete poi rimuovere al termine dell'installazione).

Anatomia

Postfix è stato interamente progettato, sin dall'inizio, per essere sicuro e veloce: esso è costituito da numerosi demoni, ognuno dei quali si occupa di un processo ben definito. Solo uno si essi, master, è eseguito con privilegi "elevati", tutti gli altri possono essere facilmente eseguiti con bassissimi privilegi (creando un utente ad hoc), e soprattutto possono essere tutti confinati in una gabbia "chroot" (vedi appendice A).

Fig.1: Anatomia di Postfix: in giallo sono rappresentati i processi, in azzurro i file di configurazione

Lo scopo di Postfix è quello di sostituire interamente Sendmail, mantenedone però, in tutto e per tutto, la compatibilità: ciò significa che migrare un server da Sendmail a Postfix risulterà completamente trasparente ad ogni altra applicazione!

Installazione

Per prima cosa, occorre innanzi tutto creare almeno un utente di sistema operativo: in questa fase però ne aggiungeremo 2, in modo tale da avere la possibilità di creare una gabbia chroot per i vari demoni.Verifichiamo innanzi tutto di non avere precedentemente installato Sendmail: per una distribuzione RedHat, ad esempio, il pachetto viene installato automaticamente, e va pertanto rimosso; da esso dipendono altri programmi, per cui sarà neccesario il flag --nodeps.
rpm -e sendmail --nodeps
Verifichiamo anche di non avere già un utente "mail" (grep mail /etc/passwd), quindi procediamo alla creazione dei 2 nuovi account, ad esempio "postfix" e "mail":

adduser postfix -s /bin/false -d /dev/null
passwd -l postfix
adduser mail -s /bin/false -d /dev/null
passwd -l mail

A questo punto, siamo pronti per compilare i sorgenti: dopo esserci posizionati nella directory in cui abbiamo scompattato l'archivio, procediamo col comando
./make
Se abbiamo installato il compilatore C, e se il nostro sistema è uno di quelli supportati (mi meraviglierei del contrario!!!), tutto dovrebbe procedere senza particolari intoppi; a questo punto, dobbiamo installare quanto compilato:
./make install
Ci verranno ora richieste alcune informazioni sul nostro sistema, ad esempio dove posizionare i file di configurazione, gli eseguibili e le pagine di help. Non c'è molto da dire su questo, dipende dalla distribuzione in esame e dai gusti personali...Facciamo invece attenzione agli ultimi 2 parametri, mail_owner e setgid: il primo è l'utente proprietario dei vari demoni, mentre il secondo è il proprietario della directory maildrop, e serve principalmente per motivi di sicurezza. Chi vuole approfondire il motivo della sua esistenza (non temete, nessuna disquisizione filosofica sull'Essere!) troverà qualcosa in appendice A. Lo script di installazione creerà le directory di configurazione (/etc/postfix) e quelle relative alle code dei messaggi (/var/spool/postfix); al termine avviserà di andare immediatamente a modificare il file di configurazione principale main.cf.
L'installazione è terminata, e siamo pronti per configurarci il nostro mail server! Io pero' consiglio un paio di operazioni ulteriori; lo script di installazione crea nella directory /etc/postfix tutti i file di configurazione, e una serie di file di esempio: a mio avviso, sarebbe più "pulito" mantenere in questa directory lo stretto necessario, e spostare gli esempi altrove... Ad esempio:

mkdir /usr/share/doc/postfix
mv /etc/postfix/sample* /usr/share/doc/postfix/
mv /etc/postfix/LIC* /usr/share/doc/postfix/
mv /etc/postfix/*.default /usr/share/doc/postfix/
mv /etc/aliases /etc/postfix

Configurazione di base

La configurazione di Postfix è veramente intuitiva: nessun parametro dal nome astruso, ed una abbondanza di commenti incredibile. Per una configurazione tipica, i file che ci interessano sono aliases e main.cf: il primo definisce gli alias per gli utenti di sistema operativo, mentre il secondo contiene la configurazione vera e propria.

/etc/postfix/aliases
Contiene la "mappatura" di un un utente di posta elettronica con un utente di s.o. Questo è molto importante per 2 motivi: in primis, è fondamentale che esistano gli alias per l'utente postfix (per il corretto funzionamento del programma) e per root (che sarebbe preferibile non ricevesse mail direttamente). Questo è vero in ogni caso, sia che il nostro Postfix funga mail server interno, sia che si tratti del mail server di un ISP.
Il secondo motivo per cui è importante la creazione di alias è l'esistenza di alcuni account "di ruolo" che vanno creati nel rispetto della cosidetta netiquette , ad esempio postmaster, info, abuse, ecc; dal momento che nella pratica spesso è un solo utente a svolgere tutte le sovracitate funzioni, è possibile fare in modo che le relative e-mail vengano automaticamente "girate" nella casella dell'utente. Vediamo un esempio: sul mio sistema, io svolgo le funzioni di sistemista e postmaster; avrò quindi un account, ad esempio tom. Il mio file /etc/postfix/aliases conterrà quindi le voci:

postmaster:	tom
abuse:	tom
info:	tom
postfix:	root
root:	tom

Come vedete, è possibile utilizzare anche degli alias "ricorsivi" (Postfix->root->tom). A questo punto, occorrerà utilizzare il comando /usr/bin/newaliases per rendere effetttive le modifiche (vedrete che verrà creato un file aliases.db, sul cui significato torneremo nel prossimo articolo).

/etc/postfix/main.cf
Veniamo ora alla configurazione vera e propria di Postfix; vedremo che i parametri da modificare per ottenere un sistema immediatamente funzionante sono davvero pochissimi! Per prima cosa, visto che abbiamo posizionato il file degli alias in /etc/postfix/, dovremo rendere partecipe Postfix della nostra decisione: aggiungeremo (o modificheremo, qui va verificato che i parametri non siano già impostati) le righe
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
A questo punto, passiamo ai settaggi fondamentali: il nome del server, e il dominio che verrà considerato "locale"; ipotizzando di voler configurare il mail server primario del dominio plutojournal.it, scriveremo:

myhostname = mail.plutojournal.it	<----questo è il nome del server, come apparirà negli header del messaggio
mydestination = $myhostname, $mydomain	<----specifica che solo user@plutojournal.it e user@mail.plutojournal.it sono considerati "locali"

Per "locale" si intende il dominio che ha le relative mailbox proprio sul nostro server.
A questo punto, il nostro server è pronto? Si! Cioè, no... Abbiamo già un server funzionante, ma che tutti quanti, là fuori, possono usare come server di invio...e noi non vogliamo lo spamming!! Bisogna allora decidere quali client saranno autorizzati ad inviare mail tramite il nostro Postfix: la cosa più comoda è utilizzare il parametro mynetworks, specificando un range di indirizzi IP. Ad esempio, ipotizzando di voler concedere il servizio SMTP alla nostra LAN (la cui subnet potrebbe essere 192.168.1.x) e ad un client esterno (con IP 1.2.3.4), scriveremo:
mynetworks = 192.168.1.0/24, 1.2.3.4
Perfetto, siamo pronti! Controlliamo di non aver fatto macro-errori di configurazione
postfix check
e se tutto è andato bene, siamo pronti ad avviarlo
postfix start
Congratulazioni!

Conclusioni

Questo articolo vuole essere il primo di una serie, dedicata alla configurazione di Postfix come server di posta elettronica. In questa prima "puntata" si è trattato della configurazione di base, ma le possibilità offerte da questo software sono decisamente più ampie, e certamente scalabili fino alla cosiddetta fascia "enterprise": vedremo più avanti come sarà possibile progettare architetture molto complesse, con un livello di scalabilità praticamente illimitato.

Appendice A
Un po' di sicurezza

Chroot jail
In estrema sintesi, una chroot jail è una sottodirectory entro cui viene eseguito un applicativo, che l'applicativo stesso vede come la root del file system. Questo implica che, in caso di un baco del programma, ogni eventuale comando che potrà essere lanciato non avrà modo di interagire con quanto sta al di fuori della gabbia (da qui il termine). Confinare quindi gli applicativi in una chroot jail risulta un ottimo metodo per aumentare la sicurezza del sistema (Bind 8.x docet).
Com'è stato già detto nell'articolo, il programma Postfix non è un applicativo "monolitico", ma è composto da numerosi processi semi- indipendenti: ad esempio, una volta che postfix è in esecuzione, nella lista dei processi appariranno i programmi master, pickup e qmgr (ed altri, a seconda che vi siano o meno messaggi da processare).
In pratica, i "sottoprocessi" sono eseguiti con privilegi minimi, e di seguito vedremo anche come sia possibile confinarli in un ambiente chroot'ed; io consiglio vivamente di optare per questo settaggio: sappiamo che la cossiddetta "chroot jail" non è la panacea per tutti i problemi di sicurezza, ma vista la facilità con cui in questo caso è possibile realizzarla, il gioco vale sicuramente la candela!
Per prima cosa, sarà necessario editare il file di configurazione /etc/postfix/master.cf: esso contiene le impostazioni dei singoli processi che conpongono Postfix; è necessario nodificare in "y" la quinta colonna (quella denominata "chroot", apputo) di ogni servizio, ad eccezione di local e pipe. A questo punto, basterà andare nella cartella sorgenti-postfix/examples/chroot-setup, e lanciare lo script corrispondente alla vostra piattaforma, ad esempio "LINUX2" (dovete prima renderlo eseguibile, di default non lo è). In pratica, lo script non fa altro che creare in /var/spool/postfix le directory etc, lib e usr; all'interno di esse, copia i file indispensabili all'esecuzione dei processi e quelli relativi alle impostazioni di sistema (localtime, resolve.conf, ecc). Fatto questo, lo script fa ricaricare a Postfix il file di configurazione, e il gioco è fatto! Va solo ricordato che d'ora in poi, ogni modifica a uno dei file copiati dallo script genererà un warning: ecco ad esempio il messaggio che trovo il /var/log/maillog, se avvio postfix dopo aver aggiunto un utente:
postfix-script: warning: /var/spool/postfix/etc/passwd and /etc/passwd differ
Quindi, nel caso si trovino messaggi come questo, bisognerà ricordarsi di copiare i file aggiornati nella directory corrispondente.

Setgid e Maildrop
Abbiamo visto che, all'atto dell'installazione, abbiamo optato per assegnare un gid (Grup ID) alla directory Maildrop. Praticamente, questo significa che la directory non è world-writeable; vediamo cosa implica questa scelta: avere una directory Maildrop w-w significa che ogni utente locale può tranquillamente inviare un messaggio aggiungendolo alla coda delle mail da inviare, anche se il demone Postfix non è attivo. Ma solo gli utenti locali, perchè la directory in esame non è utilizzata per le mail ricevute dalla rete. Il problema di questo tipo di configurazione è che un utente potrebbe creare in Maildrop un link alla posta di qualcun'altro, o creare un falso messaggio contenente un link a file di sistema. L'eventualità è remota (anche grazie a scrupolosi controlli della coda dei messaggi), ma possibile.
Utilizzando invece una Maildrop non world-writeable, i problemi di sicurezza sono completamente superati; e senza nessun inconveniente, a patto di spedire sempre la posta con Postfix attivo (il che non mi sembra una limitazione troppo forte!).

L'autore
Tommaso Di Donato è sistemista Linux e Microsoft dal 1998; è stato dba Oracle presso la PA, nell'ambito del progetto di informatizzazione dei Centri Protesi INAIL in Italia.
Attualmente lavora presso un portale Internet, in qualità di sistemista e dba; si occupa inoltre di sicurezza informatica e TLC per un importante gruppo industriale italiano.