Gestione
e-mail con Linux
Voci dal forum Linux
Unix non solo è il
padre di tutti i sistemi di smistamento della posta tanto che ancora
poco tempo fa si diceva che qualunque messaggio inviato su Internet
incontrava per strada, prima o poi un server basato su Unix, ma è anche
per lunga tradizione una solida piattaforma per la gestione della posta
dal lato client. Linux, poi, ha saputo stare al passo con i tempi e oggi
si trovano sistemi di gestione di e-Mail in grado di soddisfare
qualunque tipo di esigenza. Si parla di sistemi di gestione di e-Mail
non a caso: l'utente smaliziato è con un minimo di confidenza con il
sistema, difficilmente utilizzerà un client configurato semplicemente
per ricevere posta da una casella Pop e inviarla tramite un server Smtp.
Praticamente qualunque distribuzione appena installata prevede un vero e
proprio server di posta perfettamente funzionante sia per l'invio sia
per la ricezione di messaggi: nella stragrande maggioranza dei casi, se
la macchina è connessa direttamente a Internet, basta effettuare un
paio di operazioni sul Dns del proprio Isp e aggiungere utenti al
sistema per avere un vero e proprio server di posta elettronica che non
avrà nulla da invidiare a quelli presenti presso tanti piccoli Isp. Per
gli utenti con una connessione dial-up le cose si complicano
leggermente, ma bastano un paio di ritocchi alle configurazioni per
ottenere lo stesso risultato. Avere un server interno di posta e utile
in moltissime circostanze. Prima di tutto permette di lavorare in pieno
accordo con la filosofia Unix che prevede tanti piccoli programmi
estremamente specializzati invece di programmi monolitici e per questo
più difficili da controllare; in secondo luogo lavorare con gli
standard di posta dei sistemi Unix permette di usare non un unico client
ma tutti quelli che si desiderano, in quanto ciascuno di essi si
interfaccia in modo trasparente con il sistema di posta interno. Ultimo
ma non meno importante: esistono oggi alcuni freenet che non prevedono
la possibilità di usare un server Smtp: averne uno proprio significa
potere inviare e-Mail senza passare dalle spesso scomode interfacce Web.
Il sistema tipo dell'utente Ppp è formato da:
- un server Smtp,
detto anche Mta (Mail Transport Agent) che si occupa di smistare
tutta la posta, in arrivo e in ricezione (Sendmail, Postfix, Qmail);
- se si usano caselle
presso provider esterni: un'e-Mail checker che si occupa di
scaricare la posta presente presso le caselle Pop/Imap dei vari
provider (fetch-mail a oggi è il software di riferimento in questo
campo) e a inserirle nel sistema di posta interno;
- un programma per la
gestione della posta locale, detto anche Mda (Mail Delivery Agent),
che provvede a smistare la posta arrivata, possibilmente in base a
regole definite dall'utente, quali per esempio filtri che
inseriscono direttamente i messaggi in determinate cartelle, o che
prevedono meccanismi di risposta automatica (si può citare il
classico procmail in questa categoria);
- uno o piu client per
la lettura e scrittura di messaggi, detti anche Mua (Mail User Agent).
Il primo passo per la
configurazione di un sistema di posta è la scelta del server Smtp. Un
buon punto di partenza può essere lo storico Sendmail (http://www.sendmail.org/),
oggi arrivato alla versione 8.10: questo programma è parte integrante
della storia di Internet e tra i suoi vantaggi si può annoverare
l'imbattuta flessibilità e solidità di fronte alle situazioni più
critiche. Grazie alla sua estrema configurabilità di fatto può gestire
qualunque esigenza, dalla più semplice alla più complessa, e le
risorse su Internet relative a Sendmail costituiscono un mare
sconfinato, capace di fornire tutte le soluzioni necessarie. Per contro
Sendmail si porta dietro una serie di difetti che ancora oggi sono
difficili da risolvere: si tratta innanzitutto di un programma
monolitico, spesso e volentieri estremamente pesante da gestire e
relativamente lento rispetto alle alternative che si possono trovare su
Internet. Inoltre Sendmail è intrinsecamente poco sicuro: sono usciti
molti buchi di sicurezza relativi a questo sistema, e il tipo di
architettura che si porta dietro fa prevedere che altri potranno seguire
in futuro. Infine Sendmail è noto per la difficoltà nella
configurazione: si dice che nessuno può dirsi un vero sistemista Unix
se non ha dovuto avere a che fare con la scrittura di un file di
configurazione di Sendmail almeno una volta, e che parimenti non esiste
sistemista Unix che sia stato tanto pazzo da ripetere l'esperienza: la
definizione e configurazione del file Sendmail.cf rappresenta quindi un
enorme scoglio da superare per chi non ha una più che solida esperienza
di amministrazione di sistema. Scegliere Sendmail oggi significa
scegliere un prodotto estremamente stabile e potente, in grado di fare
fronte a qualunque tipo di esigenza. Ma significa anche farsi carico di
tutti i problemi che Sendmail porta con sé, per cui occorre prepararsi
a leggere quintali di documentazione, a seguire almeno un paio di
mailing list sulla sicurezza, e a curare giorno per giorno il sistema.
D'altro canto, se di quello che si vuole e farsi una cultura
sull'amministrazione di un sistema di posta, Sendmail rappresenta un
passo obbligato, ed è un riferimento assoluto che non può mancare nel
percorso formativo di un sistemista. Oggi esistono alternative
tecnicamente valide a Sendmail, che mirano a risolvere le sue più
grosse lacune relative alla pesantezza e alla sicurezza del sistema. Un
primo passo è stato Qmail (http://www.qmail.org/),
che però ha presentato alcuni gravi difetti: uno tra tutti il sistema
di sviluppo, estremamente accentrato sull'autore (Dan Bernstein),
persona sicuramente non facile e che non è stata in grado di costruire
intorno a sé una comunità come richiesto dai principi dell'Open Source.
Qmail inoltre presenta una scelta progettuale che ha un impatto notevole
sui sistemi, in quanto non è compatibile con nessuno dei programmi di
gestione della mail, dal momento che invece di usare il formato Mailbox
utilizza il formato Maildir nella home degli utenti. Per questo e per
altri motivi Qmail quindi sta cedendo gradualmente il passo a quello che
sembra essere il server Smtp del futuro: Postfix. Postfix presenta
innanzitutto un'enorme garanzia nella persona dell'autore. Wietse Venema
è parte integrante della storia di Unix ed è autore di alcuni tra i
software più usati su questa piattaforma (i Tcp wrapper, o tcpd). Le
performance di questo sistema, in termini di velocità e di sicurezza,
fanno impallidire tutti gli altri server, e la flessibilità offerta da
Postfix non richiede, come Sendmail, il pagamento di un grande prezzo in
termini di difficoltà di configurazione: è sufficiente nella
stragrande maggioranza dei casi cambiare un paio di parametri di
configurazione per avere un sistema funzionante. Postfix si può trovare
precompilato praticamente per tutte le distribuzioni, oppure in formato
sorgente direttamente da uno dei mirror di http://www.postfix.com/.
Una volta effettuata l'installazione è sufficiente definire nel file /etc/postfix/main.cf
quale deve essere l'indirizzo da usare nella posta in uscita e quale o
quali devono essere gli indirizzi per i quali si vuole ricevere mail. In
una contigurazione tipica per connessioni dialup, supponendo che
all'atto della configurazione di rete si sia scelto come dominio "esempio.it"
e che il proprio o i propri indirizzi di mail siano xxx@provider.it si
dovranno cambiare i parametri "myorigin" e "mydestination",
per esempio inserendo:
myorigin = provider.it
mydestination = provider.it localhost localhost.esempio.it esempio.it
In questo modo Postfix
saprà che la mail in uscita dovrà essere inviata come username@esempio.it,
e che dovranno essere accettate mail destinate a xxx@provider.it, xxx@localhost,
xxx@localhost.esempio.it e xxx@esempio.it. In aggiunta a questi
parametri un utente dialup tipico potrà volere aggiungere:
relayhost =
smtprelay.provider.it
se il provider fornisce
un servizio di Smtp server. In questo modo tutta la mail in uscita verrà
inviata al server del provider che provvederà a consegnarla a
destinazione. Inoltre è sicuramente il caso di definire:
defer_transports = smtp
Questo permette di non
cercare di inviare immediatamente la posta, ma di tenerla in coda fino a
quando non viene richiesto esplicitamente di effettuare l'invio. E'
sufficiente inserire il comando "sendmail - q" in un file come
/etc/ppp/ip-up per fare in modo che la coda venga svuotata non appena si
effettua il collegamento all'Isp. Parimenti è utile definire:
disable dns lookups =
yes
in modo da impedire a
Postfix di cercare tramite Dns i dati necessari all'invio della posta,
dati che non potrebbe trovare se non quando la connessione e attiva.
Attenzione: se si è definita la keyword relayhost insieme a disable dns
lookups occorre che in relayhost venga inserito un Ip, oppure un
hostname contenuto in /etc/hosts, in modo che Postfix sappia dove
indirizzare la posta. Postfix ovviamente presenta moltissime possibilità
di configurazione, ma queste quattro o cinque righe, unite a quelle che
sono le configurazioni standard, sono sufficienti per quasi tutti i
casi. Una volta terminata la configurazione se Postfix è in esecuzione
occorre ricordarsi di effettuare un reload della stessa, attraverso il
comando postfix reload. Se Postfix non è in esecuzione lo si può fare
partire con il comando postfix start e verificare attraverso i log che
la configurazione sia corretta. Per eventualmente fermare il servizio il
comando sarà ovviamente postfix stop.A questo punto si ha un sistema
Smtp perfettamente funzionante, in grado di ricevere e spedire mail: ma
chi possiede un collegamento dialup riceve mail su un server diverso,
tipicamente quello del provider, al quale si accede tramite protocolli
quali Pop o Imap: quello che manca quindi è un sistema in grado di
connettersi automaticamente ai server di posta sui quali risiedono le
caselle, prelevare le mail presenti e smistarle al sistema di posta
interno. La soluzione di riferimento in questo momento è sicuramente
Fetchmail, un programma divenuto ormai talmente famoso da essere incluso
in praticamente in tutte le distribuzioni. Fetchmail permette di
effettuare il collegamento a tutte le mailbox che si desiderano, di
scaricare le mail tramite protocollo Pop (versione 2 o 3) o Imap e di
spedirle attraverso il server Smtp locale agli utenti finali. La
configurazione di Fetchmail è semplice e può basarsi su un file comune
(tipicamente /etc/fetchmailrc) o su una serie di file presenti nelle
home degli utenti (con il nome .fetchmailrc). Il file comune presenta
alcuni vantaggi, soprattutto in quanto permette di automatizzare
l'intera procedura: le regole contenute nei vari file .fetchmailrc
vengono lette solo quando ciascun utente utilizza Fetchmail, mentre
quando Fetchmail viene lanciato dall'amministratore di sistema quello
che viene solitamente usato è il file di configurazione generico. Il
formato del file è semplice. Ciascuna casella viene prefissa dalla
parola chiave "poll" o "skip": una casella marcata
come "poll" viene controllata in automatico alla partenza di
Fetchmail, mentre una casella marcata come "skip" è solo
configurata, ma non viene controllata in automatico: occorre specificare
esplicitamente il nome della casella sulla linea di comando per fare in
modo che i messaggi vengano scaricati. Questo può essere utile per
esempio per effettuare i test, oppure quando si vuole che una
determinata casella venga controllata solo se esplicitamente richiesto.
Per ogni casella vanno poi specificati il server sul quale la casella
risiede, il tipo di protocollo, la coppia di username e password
necessaria per collegarsi al server e lo username locale al quale
inviare la posta. Assumendo quindi che la mail destinata a utente@provider.it
vada scaricata collegandosi mediante protocollo Pop3 al server
pop.provider.it con username "utente" e password
"test" e quindi consegnata all'utente localuser presente sul
proprio server Linux, la riga di configurazione in /etc/fetchmailrc sarà:
poll pop.provider.it
protocol POP3 user utente password test is localuser
Una volta terminata la
configurazione di tutte le caselle da controllare si potrà lanciare a
mano Fetchmail con le opzioni "-a" (controlla tutte le
caselle) "-keep" (lascia i messaggi sul server, da tenere per
la fase di test) e "-vv" (in modo da controllare se le
operazioni vengono effettuate nel modo giusto). Se tutto va bene il
passo successivo sarà quello della automatizzazione delle operazioni,
facendo in modo che la posta venga controllata durante ciascun
collegamento. Per fare questo sarà sufficiente inserire il comando
"fetchmail" direttamente nello script /etc/ppp/ip-up, che
viene eseguito non appena il collegamento all'Isp è effettivo e
funzionante. Se si fanno dei collegamenti lunghi se può essere il caso
di controllare la mail più volte durante gli stessi. Per fare questo si
possono immaginare più sistemi: per esempio si potrebbe creare uno
script che controlli la mail ogni cinque minuti; tale script andrebbe
fatto partire in corrispondenza del collegamento all'Isp e dovrebbe
rimanere in esecuzione per tutto il tempo in cui si è collegati e non
oltre. Occorre quindi pensare a un meccanismo che fermi il processo in
corrispondenza della sconnessione: per raggiungere questo risultato è
sufficiente registrare Pid (numero di processo) dello script che
effettua il controllo della mail ed effettuare un kill dello stesso
all'interno del file che viene lanciato una volta effettuata la
sconnessione. In pratica lo script di controllo della mail sarà
qualcosa del tipo:
#!/bin/sh
# Registra il PID del
processo
# (contenuto nella variabile $$)
# in un file
echo $$ > /var/run/chekmail.pid
# Esegui un ciclo
infinito
while true
do
# Ricevi la posta
fetchmail -a -vv >
/var/log/fetchmail.log
# Attendi 5 minuti (300 secondi)
sleep 300
done
A questo punto,
supponendo che lo script venga salvato come /usr/local/bin/checkmail
(ricordandosi di permettere l'esecuzione dello stesso con un opportuno
chmod 755), nel file il /etc/ppp/ip-up andrà inserita la riga:
/usr/local/bin/checkmail
&
Parimenti, nel file /etc/ppp/ip-down
andrà inserita una riga del tipo
kill -9 'cat /var/run/checkmail.pid'
che provvederà a fare
terminare il processo in esecuzione. Quello che si ha a questo punto è
un sistema di posta perfettamente funzionante, in grado di ricevere e
spedire mail in maniera trasparente ed efficiente. Un ulteriore
perfezionamento può essere l'aggiunta di meccanismi di delivery locale
intelligenti, in grado di effettuare operazioni di filtraggio delle
mail.
Fonte:
bladexperience.com |