|
|
<- SL: Apache - Copertina - SL: Backup -> |
|
Sistemi Liberi
L'articolo...Nel numero scorso abbiamo visto come installare Postfix e configurarlo come smtp server. Oggi tratteremo dettagliatamente la creazione e la gestione delle mailbox e la configurazione del servizio POP3. |
Nell'articolo precedente abbiamo visto che, una volta installato Postfix come mail server per il dominio miodominio.it, per creare una mailbox è sufficiente aggiungere un utente di sistema operativo. Oggi vedremo che esistono molti altri metodi per creare caselle di posta; conoscerli tutti significa ottenere un sistema molto più flessibile, e in ultima analisi anche più sicuro!
Nei sistemi *nix, in genere le mailbox sono
fisicamente rappresentate da un file (solitamente in
/var/spool/mail), il cui nome corrisponde a quello dell'utente di
sistema operativo a cui è riferita la casella stessa. Quindi, se sul
server di posta sono presenti gli utenti "pippo" e "topolino", allora
esisteranno automaticamente gli indirizzi e-mail pippo@miodominio.it
e topolino@miodominio.it, e troveremo due file,
rispettivamente /var/spool/mail/pippo e
/var/spool/mail/topolino (vengono automaticamente creati
all'arrivo del primo messaggio).
Fin qui tutto è abbastanza
lineare... ma decisamente "monolitico" e poco duttile; vediamo quindi
quali sono gli "strumenti" a disposizione per il cosiddetto address
rewriting.
Avevamo già visto che, tramite il file /etc/postfix/aliases, è possibile fare in modo che un solo utente di s.o. corrisponda a più caselle di posta; vediamo ora come utilizzare gli alias per aumentare la sicurezza e la manutenibilità del sistema. Supponiamo ad esempio di configurare un server di posta per una ditta con 20 dipendenti; una possibile scelta per la creazione delle mailbox è quella di creare un utente di sistema con lo stesso nome che si vuole per la casella (mario.rossi, laura.bianchi, ecc). Questa scelta ha due grossi inconvenienti: primo, se lo username è troppo lungo (di norma oltre gli 8 caratteri) alcune visualizzazioni potrebbero essere scomode (ad esempio le ownership delle mailbox). Secondo, in caso di frequente turn over dei dipendenti (ad esempio, in caso di stagisti o lavoratori interinali) ci troveremmo di fronte ad un aumento considerevole nel numero degli account di sistema operativo... A questo si potrebbe ovviare eliminando i vecchi utenti, ma potrebbero esserci alcuni settaggi personalizzati dell'account (ad esempio, tra poco vedremo la risposta automatica) che varrebbe la pena di non perdere. Non ultimo, ricordiamo che in questo modo noi stiamo implicitamente fornendo all'esterno una serie di utenti di sistema operativo (il nome della mailbox corrisponde allo username!): un eventuale cracker potrebbe giovarsi di questa nostra leggerezza, utilizzando attacchi a forza bruta...
Una possibile scelta per evitare questi inconvenienti si basa proprio sul file /etc/postfix/aliases, che permette di "mappare" un indirizzo e-mail virtuale a un account di sistema operativo. Ricapitolando quanto avevamo già visto, la nostra ditta ACME di cinque dipendenti (per fornire tutto il materiale a quel pazzo coyote, la posta elettronica è diventata fondamentale...) potrebbe avere un file di alias così fatto:
#Alias per la ditta ACME nonna.papera: acme00 gatto.silvestro: acme01 zio.paperone: acme02 wilie.coyote: acme03 daffy.duck: acme04 |
Questa strana configurazione
indica che tutta la posta per nonna.papera@acme.com va
recapitata alla mailbox fisica /val/spool/mail/acme00.
L'intestazione del messaggio non viene in alcun modo modificata, per
cui l'operazione è trasparente per l'utente. Per recuperare la
posta tramite POP3 basterà configurare il nostro programma di
posta utilizzando lo username "acme00" (e non "nonna.papera"): in
questo modo, solo gli utenti interni conosceranno uno username reale,
tutto il resto del mondo vede solo un alias che non può essere
utilizzato per accedere al sistema. Un altro vantaggio di questa
configurazione è che, se Nonna Papera si licenzia, non
dovrò aggiungere un ulteriore utente di sistema per il nuovo
assunto, ma sarà sufficiente modificare il file di alias
(ricordandosi poi di validarlo tramite il comando
newaliases).
A volte può capitare di dover far sì che tutti i messaggi indirizzati ad una particolare casella di posta vengano automaticamente rediretti a un altro indirizzo: ad esempio, un dipendente fuori sede potrebbe voler "girare" tutta la posta interna a un account accedibile via internet (webmail); o ancora, a un utente che cambia indirizzo mail farebbe certamente comodo poter recuperare la corrispondenza inviata al vecchio recapito... In questi casi, tutto quello che ci occorre fare è creare, nella home directory dell'utente, un file chiamato .forward (importante: ricordarsi il "."!). La struttura di questo file è semplicissima: un file di testo, in cui inseriamo l'indirizzo e-mail a cui intendiamo inoltrare la posta in arrivo. Solo un piccolo accorgimento: ovviamente, il file .forward deve essere almeno leggibile dall'utente proprietario della home directory. Vediamo comunque come creare un rudimentale file di forwarding: ipotizziamo che il nostro utente "pippo" voglia ridirigere verso il suo account privato "pippo@privato.it" tutta la posta che gli arriva sul nostro mail server. Allora, noi creiamo un file contenente il suddetto indirizzo:
echo pippo@privato.it > /home/pippo/.forward chmod o+r/home/pippo/.forward |
Nella pratica, molto spesso avviene che sia lo stesso utente a crearsi il proprio file: viene dato il permesso di accedere via ftp alla propria home directory, e quindi l'utente può fare l'upload di un file da lui creato. Questo, ovviamente, implica avere a che fare con utenti un minimo "smaliziati" (e non tutti i sistemisti sono così fortunati!).
Vi è anche un altro caso in cui il file di forward risulta estremamente comodo: la gestione dei cosiddetti "account di ruolo". Avevamo visto nel precedente articolo come si possa usare il file /etc/postfix/aliases per gestire account quali "abuse@..." o "postmaster@...". Esistono però casi in cui sarebbe preferibile che la posta indirizzata a un account fosse automaticamente girata a più persone. Questo si può ottenere in maniera molto semplice creando un account sul sistema, e inserendo nel relativo file di forward tutti gli e-mail (uno per riga) a cui va mandata la posta.
Una delle prime cose che si impara quando si
compra il primo PC è che lo spazio disco non è mai
(mai!) abbastanza; la posta elettronica non fa eccezione! Per
conservare una dignitosa sanità mentale è quasi
indispensabile poter fissare alcuni limiti alla dimensione delle
mailbox e dei messaggi inviati. Fortunatamente, bastano pochi
parametri nel file di configurazione (2) per evitare di dover
immediatamente pianificare un upgrade del server:
mailbox_size_limit e message_size_limit.
Come si può intuire facilmente dai nomi, il primo limita la
capacità totale della mailbox, mentre il secondo definisce la
dimensione massima di un messaggio, sia per l'invio che per la
ricezione (è utile per limitare le dimensioni degli
attachment!). I valori sono espressi in byte, e consiglio vivamente di
modificarli subito, visti i valori di default un po' troppo permissivi
(50 Mb di mailbox, e 10 Mb per messaggio):
mailbox_size_limit = 10240000 #10 Mb message_size_limit = 2048000 #2 Mb |
(Ovviamente, la dimensione della mailbox deve essere ragionevolmente maggiore della massima dimensione di un messaggio...)
A mio avviso, molto spesso sono i particolari a rendere una soluzione davvero "professionale": in questa ottica, vediamo come si può implementare la cosiddetta "risposta automatica" sul nostro server, utilizzando la funzione di forwarding della posta e il programma vacation (scaricabile da http://vacation.sourceforge.net ). Installare questo software (la versione corrente è la 1.2.6.1) è davvero facilissimo: dopo aver scaricato i sorgenti, si decomprimono e si utilizza il makefile
tar xzvf vacation-1.2.6.1.tar.gz cd vacation make install |
Io per la verità ho dovuto
"ritoccare" il Makefile, modificando la posizione dei file di help
(nella RedHat sono in /usr/share/man), ma a parte questo nessun
problema.
A questo punto, occorre creare, nella home directory
dell'utente-mailbox in questione (ad esempio "info"), un file
.vacation.msg in cui deve comparire il subject , e il testo
del messaggio automatico separati da una righa vuota. Infine va
inizializzato il programma con il comando vacation -I
user. Ricapitolando:
echo Subject: Messaggio generato automaticamente >/home/info/.vacation.msg echo >> /home/info/.vacation.msg echo Il messaggio è stato recapitato >> /home/info/.vacation.msg chmod o+r /home/info/.vacation.msg vacation -I info |
Non resta altro che informare Postfix delle nostre
intenzioni, utilizzando il file di forwarding. La struttura è
la seguente:
\username, "|/usr/bin/vacation -r
username"
L'opzione "-r" non è necessaria, ma
permette di verificare se nel messaggio in arrivo l'header "Reply-To"
è diverso dal mittente, e nel caso utilizzare questo. Quindi,
continuando con l'esempio di prima,
echo '\info, "|/usr/bin/vacation -r info"' > /home/info/.forward chmod o+r /home/info/.forward |
Un ultima nota: abbiamo parlato di alias di posta... Esiste quindi la possibilità che la nostra casella "info" sia in realtà un alias corrispondente ad un utente differente (ad esempio "pippo"). Dovremo quindi informare "vacation" che deve rispondere anche a tutti i messaggi indirizzati all'alias "info", tramite il parametro "-a". Quindi, nella home directory dell'utente "pippo" il file di forward sarà del tipo:
\pippo,"|/usr/bin/vacation -a info -r pippo" |
Ricordiamoci comunque sempre di inizializzare il db di "vacation" ogni volta che apportiamo qualche modifica.
Nel numero scorso abbiamo visto come utilizzare Postfix come server di invio per le e-mail, e come configurarlo per ricevere tutti i messaggi indirizzati a un determinato dominio. E per leggere la posta ricevuta? E' arrivato il momento di configurare un server POP3, cioè il servizio che ci permette di recuperare i nostri messaggi dal server, utilizzando il nostro client di posta preferito (Eudora, KMail, Evolution... ne esistono altri??). Per i dettagli sul protocollo POP3 (Post Office Protocol v.3) rimandiamo all'articolo precedentemente pubblicato sul Pluto Journal, http: //www.pluto.linux.it/journal/pj0201/protocolli1.html.
In genere, ogni distribuzione *nix esce con la propria versione del demone popd, ma per vari motivi (primo fra tutti le prestazioni) installeremo Qpopper, liberamente scaricabile dal sito della Qualcomm® ( ftp.qualcomm.com/eudora/servers/unix/popper/). Una volta recuperati i sorgenti (ad oggi, l'ultima versione stabile è la 4.0.3) e "scompattati" in una directory, possiamo passare alla vera e propria compilazione. Oggettivamente, l'operazione è veramente intuitiva, specialmente con l'aiuto della meravigliosa guida in formato pdf che è distribuita assieme ai sorgenti... e certamente i più pigri si staranno già chiedendo se non esistano i binari precompilati. Certo che si trovano: è possibile anche il download in formato RPM! Vale però la pena di fare qualche considerazione: in generale, il demone popd si occupa di un servizio (scusate se mutuo il termine dal mondo Microsoft...) che spesso sarà utilizzato in maniera molto pesante... I sorgenti precompilati, primo fra tutti quello di RedHat, si appoggiano al super-demone xinet (il successore di inet): in pratica, il demone viene eseguito solamente quando viene richiesta una connessione; in modalità stand-alone, invece, il demone è sempre in esecuzione. I vantaggi dell'utilizzo tramite xinetd sono che, se nessuno si collega al server POP, non ci sono processi inutili in background. Per contro, nel caso di connessioni frequenti e ripetute, è possibile che si riscontri un deterioramento oggettivo delle prestazioni (lunghi tempi di attesa per la connessione, e un generale rallentamento del server), dovuto al fatto che ogni volta è il super-demone xinet che esegue il demone popd "on demand". Solo una valutazione personale, fatta con cognizione di causa, potrà discriminare volta per volta quale strada conviene effettivamente prendere...
Compileremo quindi il nostro demone come "stand-alone", in modo tale da massimizzare le prestazioni di un POP server sottoposto ad elevato stress. Una volta estratti i sorgenti, cominciamo la compilazione:
tar xzvf qpopper4.0.3.tar.gz cd qpopper4.0.3 ./configure --enable-standalone |
In questo modo, prepariamo la compilazione di Qpopper in modalità stand-alone; se tutto è andato bene, possiamo procedere alla vera e propria compilazione:
make make install |
Abbiamo così ottenuto i binari per il nostro demone, che sono
stati creati in /usr/local/sbin/ (popper).
A questo punto, non
ci resta che automatizzarne l'avvio e l'arresto, utilizzando gli init
script (vedi appendice A). Per verificarne il funzionamento,
basterà eseguire il demone (con il comando /etc/init.d/popper
start), e verificare che effettivamente si sia messo in ascolto sulla
porta 110:
netstat -apn |grep :110 |
Ora abbiamo il nostro demone POP3, pronto per ricevere connessioni da qualsiasi client di posta! Una piccola parentesi: Qpopper supporta molte opzioni, come ad esempio l'utilizzo di connessioni sicure POP3S. La documentazione compresa nel pacchetto spiega tutto in maniera molto chiara.
Quando si crea un utente "manualmente"
(tramite il comando adduser), ad esso viene
automaticamente associata una shell di comandi (ad esempio
/bin/bash). Se però siete degli amanti di Linuxconf
(un popolare programma per l'amministrazione del sistema) avrete visto
che esso dà la possibilità di creare i cosiddetti
"popusers": questi sono dei comuni utenti di sistema, ma che
appartengono tutti ad uno stesso gruppo popuser e che non
hanno shell. In effetti, un utente che utilizza il nostro server di
posta solo per inviare mail e riceverne tramite protocollo POP3, non
necessita di un accesso "interattivo" (ad esempio via telnet, ssh o
ftp). Questa scelta ha però i suoi pro e contro: indubbiamente,
un utente che non ha shell è impossibilitato ad
eseguire comandi sul sistema (cosa che potrebbe essere sfruttata in
caso di un bug dell'applicazione). D'altro canto, la mancanza di una
shell non permette alcune delle cose che abbiamo visto finora: ad
esempio non sarà più possibile utilizzare l'ftp per
l'upload per proprio file di forwarding, né configurare la
risposta automatica (per la quale è necessario eseguire il
programma vacation. Starà quindi a noi decidere
come comportarci: se permettere o meno una shell, in base alle reali
necessità degli utenti, ma soprattutto valutando i reali rischi
a cui può essere esposto un sistema (ad esempio un server di
posta interno è decisamente poco esposto a eventuali
attacchi...).
Esiste comunque la possibilità di utilizzare
shell "ristrette", che permettono cioè solo l'esecuzione di un
ristretto insieme di comandi (ad esempio la bash2), la cui trattazione
esula però dagli scopi di questo articolo.
Nel precedente articolo avevamo già visto l'utilità degli init script per automatizzare l'avvio dei vari demoni. Senza perderci in ulteriori dettagli, quindi, riportiamo un possibile script per il nostro Qpopper, che andrà salvato come /etc/rc.d/init.d/popper (la directory dipende dalla distribuzione):
#!/bin/sh
#
# postfix This shell script takes care of starting and stopping
# Qpopper, the POP3 daemon.
#
# chkconfig: 2345 82 31
# description: Qpopper: daemon for retrieving mail from Internet \
# using POP3 protocol.
# processname: qpopper
#
# Hacked by Dido
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
qpopper=/usr/local/sbin/popper
start() {
action $"Starting POP3 daemon:" $qpopper -s -R
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/qpopper
}
stop() {
action $"Stopping POP3 daemon:" killall popper
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/qpopper
}
RETVAL=0
# See how we were called.
case "$1" in
start)
# Start daemons.
start
;;
stop)
# Stop daemons.
stop
;;
restart)
stop
start
;;
*)
echo $"Usage: $prog {start|stop|restart}"
exit 1
esac
exit $RETVAL |
A questo punto, aggiungiamo il demone con il comando
chkconfig --add popper chkconfig --level 345 popper on |
|
L'autore Tommaso Di Donato è sistemista Linux (Red Hat Certified Engineer) 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. |
|
|
<- SL: Apache - Copertina - SL: Backup -> |
|