In questa esercitazione si è voluto realizzare un server di posta su di una macchina linux Red Hat 8.0 (kernel 2.4.18) capace di gestire utenti reali su di un dominio reale e utenti virtuali su dominio virtuale, per questa ragione si è scelto di utilizzare Postfix e Vm-pop3d a dispetto dei predecessori Sendmail ed un classico demone pop3 quale Qpop che trattavano solamente utenti reali, ossia esistenti sulla macchina con tanto di autenticazione tramite i file /etc/passwd ed /etc/shadow; questo anche per un fattore di sicurezza.
Prima di entrare nello specifico occorre però dare un’occhiata al funzionamento della posta elettronica ed a esaminare le varie parti che lo compongono:
- MAILBOXES
- MUA
- MTA
Uno degli attuali mail system è costituito da mailboxes, ossia directory per contenere la posta dell’utente stipata in un unico file, le singole mail sono divise fra loro da un separatore che consentirà poi di essere divise dal client nel caso del protocollo pop3.
MUA è l’acronimo di Mail User Agent e sta a significare quel componente che permette di far ricevere la posta ad un client (pop3) e solitamente lavora sulla porta 110/TCP (nel nostro caso utilizziamo vm-pop3d come MUA)
L’MTA significa Mail Transfer Agent e come facile da intuirsi è il protocollo SMTP (Simple Mail Transfer Protocol) che sta in ascolto sulla porta 25/TCP, nella nostra esercitazione si utilizza Postfix come MTA.
La slide che segue può aiutare a comprendere come i tre componenti sopra descritti interagiscono tra di loro dando vita ad un vero server di posta:
L’esempio è tratto dall’esercitazione con la sola differenza che il dominio sara.it è il dominio reale della macchina e il dominio dominio3.it è il dominio virtuale della stessa, quindi è un sistema di posta unico.
L’utente user1.sara.it tramite terminale manderà un messaggio di posta al proprio MTA che lo inoltrerà nella mailboxe di sara.it se la mail è diretta ad un utente del proprio dominio oppure eseguirà un forward al MTA di dominio3.it se la mail è destinata ad un utente dell’altro dominio di posta. Quando l’utente user1.sara.it vorrà scaricare la propria mail, sarà compito dell’MUA di sara.it inoltrargli la posta dalla propria mailbox.
Specifiche tecniche del sistema:
- hostname: fila2
- domainname: sara.it (dominio reale)
- dominio virtuale: dominio3.it
- utente reale: [email protected]
- utente virtuale: [email protected]
- Indirizzo ip: 192.168.0.133/24
Software utilizzati:
- Red Hat 8.0 (2.4.18)
- Vm-pop3d-1.1.6-2
- Postfix-20011210-1
- Openwebmail
- Apache-2.0
- Librerie compat-db-3.3.11-2 (necessarie per postfix)
- Webmin-1.050-1
- Openwebmail-1.81-20030113
- Text-iconv-1.2 (Necessario per openwebmail)
Occorre subito dire che per installare vm-pop3d è necessario disinstallare qualsiasi altro demone pop3 con tutte le sue dipendenze, la medesima cosa è necessaria per l’installazione di postfix (in particolare rimuovere sendmail).
Installazione di webmin
Nell’eseguire il progetto, saltuariamente, potrebbe far comodo dell’ausilio di Webmin, un tool di amministrazione del sistema, raggiungibile via web sulla porta 10000 (di default). Per installare il pacchetto in formato rpm basta il comando:
#rpm -ivv Webmin-1.050-1.noarch.rpm
Installazione di postfix
Prima di eseguire l’installazione del server smtp occorre installare le librerie compat-db-3.3.11-2 per evitare in futuro il fastidioso errore di dipendenza. Il pacchetto compat-db-3.3.11-2.rpm è reperibile su rpmfind.net, ottimamente navigabile anche con il browser testuale Lynx.
#rpm -ivv compat-db-3.3.11-2.rpm
Il pacchetto Postfix-20011210-1.rpm contiene il software necessario già compilato per la nostra distribuzione di linux, quindi con il comando
#rpm -ivv Postfix-20011210-1.rpm
si ottiene l’installazione senza problemi di dipendenze.
Installazione di vm-pop3d
Per installare il server pop3 occorre eseguire il comando:
#rpm -ivv Vm-pop3d-1.1.6-2.src.rpm
Essendo il pacchetto in formato .src.rpm eseguendo il precedente comando si installano i sorgenti del programma in un file chiamato Vm-pop3d-1.1.6-2.tar.gz che sarà necessario decomprimere
#tar -xvzf Vm-pop3d-1.1.6-2.tar.gz
e spostarsi nella directory creata
#cd Vm-pop3d-1.1.6-2
per poter verificare alcune cose nel file vm-pop3d.h ossia negli header dei sorgenti
#vi vm-pop3d.h
in particolare è necessario verificare le seguenti impostazioni:
#define VIRTUAL_UID 8 #define VIRTUAL_MAILPATH /var/spool/virtual #define VIRTUAL_PASSWORD_PATH /etc/virtual #define VIRTUAL_PASSWORD_FNAME passwd
Verificate le impostazioni avviamo la configurazione, compilazione ed installazione del programma con
#./configure && make && make install
l’operatore && tra un comando e l’altro permette di eseguire il secondo comando solo se quello prima è andato a buon fine.
Al termine dell’installazione ci restituisce alcune informazioni utili, una delle quali è la locazione del demone vm-pop3d che risiede in /usr/local/sbin.
Configurazione di xinetd
Successore del vecchio demone inetd, xinetd è un demone che rimane in ascolto su diverse porte tcp di sistema ed attiva i demoni sotto di lui per ogni chiamata ad essi riservate; questo per una questione di risparmio delle risorse in quanto tutti gli altri demoni non sono attivi anche nel tempo in cui sono inutilizzati. Nella directory /etc/xinetd.d vi sono tutti i file di configurazione dei servizi che xinetd ha in carica, occorre aggiungere quindi anche un file vm-pop3d per far si che il demone assuma anche il controllo di vm-pop3d.
#vi /etc/xinetd.d/vm-pop3d
All’interno occorre inserire la seguente sintassi :
service pop3
{
disable = no
wait = no
socket_type = stream
protocol = tcp
user = root
instance = 25
server = /usr/local/sbin/vm-pop3d
server_arg = -i
log_type = SYSLOG local4 info
log_on_success = PID HOST EXIT DURATION
log_on_failure = HOST ATTEMPT
}
Brevemente occorre spiegare le varie righe: service pop3 indica il tipo di servizio offerto, disable=no è l’istruzione per abilitare il servizio, wait=no per obbligarlo ad attivarsi subito dopo di una chiamata, socket_type è il tipo di flusso che il demone deve aspettarsi, protocol il protocollo di trasporto, user l’utente con cui il demone deve essere attivato, instance quante istanze di se stesso creare, server la locazione del demone nel filesystem, server_arg gli argomenti da passare al demone, log_type il tipo di logging da effettuare, log_on_success cosa loggare in caso di connessione avvenuta e log_on_failure cosa loggare in caso di connessione rifiutata.
Creato e salvato il file è necessario un riavvio di xinetd per permettergli di attivare le nuove configurazioni
#/etc/init.d/xinetd restart
Configurazione di postfix
Tutti i file di configurazione di postfix si trovano nella directory /etc/postfix ed il primo file che andremo a configurare è /etc/postfix/aliases
#vi /etc/postfix/aliases
Al termine del file, sotto la sezione #CHANGE THIS LINE TO AN-¦-¦-¦-¦-¦-¦-¦-¦-¦ dobbiamo inserire l’alias per l’utente root con la sintassi
root: user1
Per ora possiamo salvare il file, ma ciò non basta perchè postfix ha bisogno del file aliases sotto forma di data base, per convertire quest’ultimo in data base eseguire il comando
#postalias aliases
verrà creato nella medesima directory il file aliases.db.
Subito dopo è necessario editare il file di configurazione principale chiamato main.cf, sempre nella stessa directory
#vi main.cf
ed in particolare prestare attenzione ai seguenti settaggi (in ordine sparso):
queue_directory = /var/spool/postfix command_directory = /usr/sbin mail_owner = mail default_privs = mail myhostname = fila2.sara.it mydestination = fila2.sara.it, dominio3.it mynetworks = 192.168.0.0/24 alias_maps = hash:/etc/postfix/aliases mail_spool_directory = /var/mail
I parametri elencati ora potrebbero essere commentati di default nel file di configurazione, quindi decommentarli e settarli come
alias_database = hash:/etc/postfix/aliases virtual_maps = hash:/etc/postfix/virtual canonical_maps = hash:/etc/postfix/sender_canonical defer_transport = smtp
Se invece non esistono proprio (cosa improbabile) è sempre possibile inserirli al termine del file dopo la scritta #Other configurations parameters
Come abbiamo settato le variabili mail_owner e default_privs con l’utente mail, è necessario andare a verificare che l’utente mail sia un utente reale della macchina e che abbia l’uid numero 8 nel file /etc/passwd.
Il prossimo passo è quello di creare i due file /etc/postfix/sender_canonical e /etc/postfix/virtual dove il primo si occupa di associare ad ogni utente reale e non un indirizzo di posta che andrà a visualizzarsi nel campo mittente in ogni mail che l’utente invierà ed il secondo specifica tutti gli utenti virtuali e non e il dominio virtuale della macchina per associarli ad un indirizzo che il server possa comprendere.
Sia nel file sender_canonical che nel file virtual occorre inserire anche il nostro utente reale ed il dominio reale proprio perchè postfix non fa distinzione fra loro e li considera entrambi utenti virtuali.
Anche questi due file appena creati necessitano della conversione in data base ma questa volta con il comando
#postmap sender_canonical #postmap virtual
Verranno creati i file .db.
Configurazione di vm-pop3d
Innanzitutto prima di passare alla configurazione del demone bisogna creare le varie cartelle che conterrano la posta degli utenti e le cartelle contenenti il i file di autenticazione. La slide che segue può aiutare a capire come lavora il demone:
Iniziamo a creare le mailboxes
#mkdir /var/spool/virtual #mkdir /var/spool/virtual/sara.it #mkdir /var/spool/virtual/dominio3.it
postfix creerà all’interno di ogni directory del dominio una directory relativa all’utente e proprio per questo le directory dei domini devono avere diritti 770, per far questo
#cd /var/spool/virtual #chmod 770 sara.it #chmod 770 dominio3.it
e devono essere di proprietà dell’utente root e del gruppo mail
#chown root.mail sara.it
#chown root.mail dominio3.it
Occupiamoci ora dell’autenticazione degli utenti che richiedono il servizio pop3 alla macchina, come mostra la slide precedente occorre creare la directory /etc/virtual con all’interno le due directory che prendono il nome dai due domini della macchina a loro volta, all’interno sarà necessario chiamare un file denominato passwd che dovrà contenere il nome dell’utente relativo a quel dominio accompagnato dalla password criptata con una sintassi simile alla seguente: nomeutente: LJHm45HyhtgG (dove LJHm45HyhtgG è la password criptata)
#mkdir /etc/virtual
#mkdir /etc/virtual/sara.it
#mkdir /etc/virtual/dominio3.it
Per criptare la password esistono molti tool utili al nostro scopo, uno dei quali è il file binario htpasswd presente nel sistema se è installato il serverweb Apache.
Spostiamoci nella prima directory
#cd /etc/virtual/sara.it
#htpasswd -c passwd user1
Cosଠfacendo verrà creato il file passwd nella directory /etc/virtual/sara.it. Da notare che se dovessimo aggiungere un altro utente al file del dominio sara.it bisognerebbe evitare di ripetere il comando con l’opzione -c (create) se no il vecchio file verrebbe ricreato e non aggiornato con l’aggiunta dell’ulteriore utente.
Facciamo lo stesso per dominio3.it
#cd /etc/virtual/dominio3.it
#htpasswd -c passwd user2
Come ultima operazione si andrà a configurare postfix per lo smistamento della posta nelle directory create prima, per far questo il file da editare è /etc/postfix/aliases. Sotto la sezione #CHANGE THIS LINE TO AN-¦-¦-¦-¦-¦-¦-¦-¦-¦ dove avevamo aggiunto già l’alias per l’utente root, inseriamo le seguenti righe
user1.sara.it: /var/spool/virtual/sara.it/user1
user2.dominio3.it: /var/spool/virtual/dominio3.it/user2
La configurazione del server di posta è terminata, ora occorre avviare/riavviare il demone postfix per far si che assuma le nuove configurazioni e si metta in ascolto sulla porta 25/TCP.
#/etc/init.d/postfix restart (oppure start)
Se il demone fosse già attivo e si volesse far assumere la nuova configurazione senza disattivalo evitando quindi un down temporaneo del servizio lo possiamo fare con il comando
#/etc/init.d/postfix reload
Per testare il corretto funzionamento del server basta impostare gli account su due client (settando come server smtp e pop3 là¢â‚¬â„¢indirizzo ip 192.168.0.133) all’interno della stessa LAN e dello stesso segmento di rete, scambiarsi la posta reciprocamente e provare a scaricarla.
Generazione dello script per aggiungere utenti e domini
Come abbiamo visto le operazioni per aggiungere anche solo un utente virtuale o un dominio virtuale alla macchina sono varie e complesse, proprio per questo si è deciso di automatizzarle con uno script (upuser) che verrà poi inserito nel PATH dell’utente root in modo che solo l’amministratore di sistema possa avviarlo. Il sorgente dello script lo si trova in allegato n° 6.
Installazione di OpenWebMail
La prima cosa da fare è installare il pacchetto text-iconv-1.2 per soddisfare le dipendenze di openwebmail, lo facciamo con il comando
#rpm -i text-iconv-1.2.rpm
Ora passiamo all’installazione della webmail.
Openwebmail è un pacchetto per implementare una webmail sul nostro server in modo da abilitare gli utenti di posta a controllare la posta da remoto tramite browser.
La versione da noi installata è la 1.81-20030113 e la possediamo in formato rpm quindi con il comando
- rpm -ivv openwebmail-1.81-20030113.rpm
Verrà installato il tutto nella directory /var/www/cgi-bin/openwebmail (la suddetta directory è di default se si utilizza Apache 2.0 come serverweb, altrimenti è liberamente configurabile e lo vediamo nel passo successivo).
Il primo file di configurazione che andremo ad editare sarà openwebmail.conf all’interno della directory /var/www/cgi-bin/openwebmail/etc inserendo i seguenti parametri:
mailspooldir /var/mail ow_htmldir /var/www/data/openwebmail ow_cgidir /var/www/cgi-bin/openwebmail spellchek /usr/bin/aspell default_language it auth_module auth_pop3.pl use_homedirspool no use_homedirfolders no enable_changepwd no enable_autoreply no enable_setforward no enable_setfrommail no autopop3_at_refresh yes auth_withdomain no autopop3_at_refresh yes
Il secondo file di configurazione, è auth_pop3.pl sempre nella sottocartella etc ed i parametri sono
$pop3_authserver='localhost'; $pop3_authport='110'; $local_uid='48';
NB: la variabile $local_uid=’48’ deve contenere l’UID dell’utente apache visto che openwebmail interagisce con il suddetto demone, un modo per sapere l’UID dell’utente apache è quello di andarlo a vedere nel file /etc/passwd
Un ulteriore file da controllare è il file auth_unix.pl che deve contenere la sintassi
My $unix_passwdfile_plaintext='/etc/passwd'; My $unix_passwdfile_encripted='/etc/shadow';
Ora dobbiamo occuparci dei file dove postfix scrive le mail ossia /var/spool/virtual/sara.it/user1 e /var/spool/virtual/dominio3.it/user2 dandogli come permessi 666 nel metodo ottale:
#chmod 666 /var/spool/virtual/sara.it/user1 #chmod 666 /var/spool/virtual/dominio3.it/user2
Il prossimo passo è quello di creare dei piccoli file di configurazione per ogni dominio presente all’interno della directory /var/www/cgi-bin/openwebmail/etc/sites.conf, creeremo dunque due file:
#vi sara.it
con all’interno:
mailspooldir /var/spool/virtual/sara.it auth_withdomain yes auth_module auth_pop3.pl
#vi dominio3.it
con all’interno:
mailspooldir /var/spool/virtual/dominio3.it auth_withdomain yes auth_module auth_pop3.pl
Entrambi i file servono per dire ad ogni dove andare a prendere i file di mail e come autentificare gli utenti.
Per ultima cosa controlliamo se la directory /var/www/cgi-bin/openwebmail abbia come owner sia là¢â‚¬â„¢utente che il gruppo apache.
L’inizializzazione del servizio è affidata al comando
#openwebmail-tool.pl à¢â‚¬â€œ-init
Potrebbero risultare degli errori, quindi occorre seguire le indicazioni che ci vengono fornite come output.
Per controllare il funzionamento, da un client della stessa rete, ci colleghiamo via browser all’indirizzo dove troviamo la pagina di login e proviamo ad accedere alle mail-box sia con utente reale che virtuale.
Abbiamo in seguito configurato 3 server di posta all’interno della classe ed un server DNS per far sଠche i 3 server si vedessero e riuscissero a forwardare la posta.
