Ricerche IT

Panoramica

Nel precedente articolo riguardante la posta elettronica su Linux (le cui avvertenze valgono anche per il presente post), è stato creato un mail server in grado di gestire un unico dominio di posta. Accade però piuttosto spesso di dover gestire più domini di posta, per cui, o si installa un mail server per ogni dominio (cosa che avrebbe un senso solo in caso di alto traffico), oppure, si fanno convivere sullo stesso server di posta più domini, che in caso di realtà medio-piccole è la soluzione ideale. Un’altra casistica non contemplata nel precedente articolo riguarda le liste di distribuzione, cioé la possibilità di avere un indirizzo di posta che recapiti il messaggio ricevuto su più caselle postali. Per questi test faremo riferimento all’ambiente di test descritto in precedenza, dove verrà utilizzato il mail server di test Titano, il quale gestisce il dominio urano.mail; tenere presente che dobbiamo creare le zone DNS relative ai domini virtuali utilizzati nel server DNS Windows Server 2003 DCServer.

Alias e domini virtuali

Per poter gestire la posta di più domini, è necessario definire, oltre al già citato urano.mail (indicato nella direttiva mydestination del file di configurazione /etc/postfix/postfix.conf) che sarà il dominio locale, anche i cosidetti domini virtuali, che corrispondono ai domini che dovremo gestire. A questo punto, è utile distinguere i domini locali dai domini virtuali: nel nostro caso, abbiamo un dominio locale, urano.mail, in cui, ad ogni utente creato sul sistema, corrisponde una casella di posta elettronica; in questo contesto, l’utilizzo di un dominio virtuale, ci consente di definire degli indirizzi di posta con dominio diverso da quello locale, che vengono mappati su una casella di posta elettronica del dominio locale, e che vengono quindi definiti alias virtuali.

Supponiamo, ad esempio, che il nostro mail server debba gestire i domini virtuali miranda.mail, ariel.mail e umbriel.mail; per farlo, dovremo dire a Postfix che intendiamo agire da server SMTP anche per questi domini, come mostrato di seguito:

virtual_alias_domains = miranda.mail ariel.mail umbriel.mail

Ora, dobbiamo inserire nel file di configurazione di Postfix (main.cf) il percorso del file in cui è contenuta la mappa con gli alias virtuali, in cui, ad una casella di posta locale, corrispondono uno o più indirizzi appartenenti ai domini virtuali definiti poc’anzi:

virtual_alias_maps = hash:/etc/postfix/virtual

Definito il file della mappa degli alias virtuali, dobbiamo creare il file stesso ed editarlo:

touch /etc/postfix/virtual
nano /etc/postfix/virtual

Il file va creato seguendo uno stile preciso, come mostrato di seguito:

h.mallow@miranda.mail       hober.mallow@urano.mail
s.hardin@ariel.mail         salvor.hardin@urano.mail
p.palver@umbriel.mail       preem.palver@urano.mail
s.gendibal@umbriel.mail     stor.gendibal@urano.mail

Come si può vedere, nella colonna sinistra del file mettiamo gli alias virtuali, mentre nella colonna di destra, indichiamo a quale utente di sistema va recapitata la posta indirizzata a quello specifico alias virtuale. Ora dobbiamo creare la mappa vera e propria, tramite la “compilazione” in formato binario del file /etc/postfix/virtual, con il comando postmap:

postmap /etc/postfix/virtual

che creerà il file /etc/postfix/virtual.db che sarà quello effettivamente usato da Postfix per l’interrogazione degli alias virtuali.

Così facendo, se spediamo ad esempio una mail a s.hardin@ariel.mail, questa verrà depositata fisicamente nella casella di posta salvor.hardin@urano.mail; ciò in alcune situazioni può andare bene, ma in altre situazioni, questo stato di cose potrebbe non andarci a genio, come in quei casi in cui vogliamo che le caselle di posta dei domini virtuali siano trattate come mailbox a sé stanti, e non legate agli utenti di sistema. Postfix permette di gestire anche queste casistiche, tramite le mailbox virtuali, che verranno esaminate in un articolo successivo.

Liste di distribuzione tramite alias virtuali

Tramite gli alias virtuali è possibile creare anche liste di distribuzione, ovvero indirizzi di posta elettronica virtuali che servono per reindirizzare i messaggi ricevuti dall’alias virtuale stesso agli indirizzi di posta specificati come destinatari del messaggio.

Vediamo un esempio: aggiungiamo una riga al file /etc/postfix/virtual come mostrato di seguito:

oratori@umbriel.mail        p.palver@umbriel.mail, s.gendibal@umbriel.mail

Come già specificato, sulla sinistra compare l’alias virtuale, sulla destra compaiono gli indirizzi di posta a cui vogliamo reindirizzare i messaggi ricevuti sull’indirizzo oratori@umbriel.mail; da notare che i diversi indirizzi devono essere separati da una virgola, e che, in questo caso i membri della lista di distribuzione sono a loro volta alias virtuali, ma potrebbero essere tranquillamente utenti di sistema.

Salvato il file, dobbiamo ricompilare il file /etc/postfix/virtual in questo modo:

postmap /etc/postfix/virtual

Ora possiamo testare il corretto funzionamento della lista di distribuzione, e se tutto va bene, inviando un messaggio all’indirizzo oratori@umbriel.mail, il messaggio arriverà ai due indirizzi p.palver@umbriel.mail e s.gendibal@umbriel.mail, i quali, essendo alias, non hanno una propria casella di posta e quindi il messaggio finirà effettivamente nelle caselle di posta preem.palver@urano.mail e stor.gendibal@urano.mail.

Conclusioni

In questo articolo abbiamo apportato qualche miglioramento al nostro server di posta basilare, ora possiamo gestire più domini sulla stessa macchina e possiamo gestire liste di distribuzione all’interno della nostra organizzazione. I metodi utilizzati possono essere utilizzati in piccole realtà, ma per ambienti più complessi, è bene utilizzare altre metodiche per raggiungere gli stessi risultati, che verranno illustrate in altri articoli sull’argomento.

Fino ad oggi, avevo sul blog una pagina in cui avevo raccolto alcuni collegamenti ipertestuali a pagine con documentazione varia relativa alle tematiche di questo spazio. Questi link li ho tenuti aggiornati per un po’, dopodiché ho mollato lì la cosa, anche perché nel frattempo mi sono arrangiato con Google Reader, impostando i tag e le stelle agli articoli dei blog che seguo per poterli poi ritrovare in caso di bisogno. Ma i blog del feed reader non sono la mia unica fonte di conoscenza, alle volte, cercando cose che mi interessano, mi imbatto in articoli interessanti che non meritano l’oblio, quindi ho deciso di aprire un account su Delicious, dove, alla bisogna, inserisco i bookmarks che ritengo meritevoli.

Oggi ho pensato ad una cosa: perché non sostituire i link utili nella pagina del blog con la lista dei bookmarks su Delicious? Bene, mi sono messo quindi alla ricerca di un plugin per Wordpress che mi permettesse di inserire la lista dei miei bookmarks di Delicious, peccato che la ricerca non abbia fornito l’esito sperato, infatti ciò che ho trovato io (ma può essere che mi sia sfuggito qualcosa) non risponde alla mia semplice esigenza, poiché ho letto solamente di plugin che permettono di inserire un certo numero di bookmarks in un widget sulla sidebar, cosa che ho provato a fare ma che ho levato subito con un moto di ribrezzo, poiché i link di quel tipo nella sidebar mi paiono decisamente inutili.

Cerca che ti ricerca, ho pensato di andare direttamente alla base, cioé sul sito di Delicious, dove ho trovato una simpatica pagina coi tools relativi a Delicious, tra cui vi sono Linkrolls e Tagrolls. Linkrolls consiste in un semplice script JavaScript, personalizzabile in base a vari parametri, con cui elencare un numero a piacere di bookmarks relativi al proprio account. Ciò era proprio quel che mi serviva, quindi lo provo e vedo che funziona alla perfezione, ma mi rendo subito conto che questa pletora di collegamenti ipertestuali è decisamente dispersiva.

A questo punto, rivolgo la mia attenzione su Tagrolls, che elenca la lista (o la tag cloud) dei tag utilizzati per categorizzare i propri bookmarks. Anche in questo caso, si tratta di uno script JavaScript che possiede diversi parametri personalizzabili (come l’ordinamento e l’aspetto); lo provo, e verifico che pure questo tool funziona perfettamente, ottenendo il risultato voluto.

Tutto bene quindi? Non proprio, perché, trattandosi di uno script JavaScript, chi naviga tenendo disabilitato l’interprete JavaScript, non visualizza un bel niente. Per risolvere il problema, ho pensato di fornire un contenuto alternativo tramite il tag <noscript>, in cui includere il link alla mia pagina su Delicious, così da non escludere chi preferisce navigare con JavaScript disabilitato.

Comunque, se qualcuno dei lettori volesse segnalare un metodo alternativo per gestire i bookmarks di Delicious, o un metodo più elegante riguardante il contenuto alternativo allo script JavaScript, lo può come sempre segnalare nei commenti.

Avvertenza

Questo articolo è stato redatto a scopo didattico e di test, per cui, si sconsiglia fortemente di adottare questa configurazione in ambiente di produzione, poiché non fornisce i necessari requisiti di sicurezza, a causa del tipo di installazione trattata e NON dei prodotti utilizzati.

Panoramica

In questo articolo verrà trattata l’installazione basilare di un server di posta elettronica su un server Debian Etch. La configurazione proposta rispecchia quella trattata nell’ambiente di test precedentemente descritto, dove verrà preso come server di posta il server Titano, il quale ha l’indirizzo IP 192.168.1.11 e su cui verrà configurato il dominio di posta urano.mail. I prodotti scelti per questa installazione di test sono Postfix, che funge da MTA ed espone il servizio SMTP, e Dovecot, che verrà utilizzato per esporre i servizi POP3 ed IMAP4, per far sì che gli utenti della rete possano consultare la propria posta elettronica. Lo scambio di e-mail avverrà con il server Exchange DCServer (dominio giove.mail) e con il server Linux Giapeto (dominio saturno.mail), il quale verrà configurato allo stesso modo del server Titano.

Cenni teorici

In questo articolo, verranno usati software che permettono la trasmissione e la ricezione di messaggi di posta elettronica. Per scambiare i messaggi tra i vari mail server, il protocollo usato sulla rete Internet è SMTP (Simple Mail Transfer Protocol), il quale, come dice il nome, è responsabile della trasmissione, e ricezione, dei messaggi di posta elettronica tra server di posta. Il server SMTP passa il messaggio ricevuto al Mail Delivery Agent (MDA), che spesso diventa un Local Delivery Agent (LDA), il quale si occupa di depositare il messaggio nella casella di posta elettronica dell’utente locale.

L’archiviazione del messaggio ricevuto, per quanto concerne il mondo Linux / Unix, può avvenire principalmente in due formati, mbox e maildir. Mbox ha la peculiarità di archiviare tutti i messaggi di posta elettronica in un unico file per ogni utente, mentre maildir crea un file per ogni messaggio ricevuto. Entrambi i sistemi presentano vantaggi e svantaggi in termini di flessibilità e prestazioni; a mio parere lo svantaggio principale di mbox è il fatto che, usando un unico file monolitico per ogni casella, in caso di problemi si rischia di perdere l’intero contenuto della casella stessa, cosa che diventa molto più difficile utilizzando maildir.

Un MTA ha il compito di movimentare i messaggi di posta, ma non è in grado di presentarli in una qualche forma all’utente finale. Per raggiungere lo scopo, bisogna installare un server POP3 e/o IMAP4, protocolli che permettono di poter presentare i messaggi di posta in un formato riconoscibile ad una applicazione client installata sull’host dell’utente finale, chiamata client di posta elettronica o Mail User Agent (MUA). POP3 è un protocollo piuttosto datato che consente appunto la lettura della posta elettronica tramite un Mail User Agent, il quale normalmente si connette al server POP3 e scarica i messaggi cancellandoli dal server; tale comportamento è d’ostacolo per quegli utenti che debbono consultare la posta da diverse posizioni, oppure per quegli utenti che condividono l’utilizzo di una mailbox. Per ovviare a questi problemi, esiste il protocollo IMAP4, che mantiene i messaggi di posta sul server, in modo tale da metterli a disposizione a prescindere dalla posizione dalla quale ci si connette; inoltre, mantiene una connessione permanente tra client e server, con i vantaggi del caso, rendendosi quindi il protocollo da scegliere per utilizzi professionali del servizio di posta elettronica.

Nel nostro caso, useremo Postfix come MTA, archiviando la posta nel formato maildir, quindi utilizzeremo Dovecot come server IMAP e POP3 e Outlook e Windows Mail come MUA.

Installazione e configurazione di Postfix

Per installare i software che ci servono, utilizzeremo i pacchetti .deb della distribuzione, in modo da mantenere un ambiente coerente, rinunciando però alle ultime versioni dei software (che è la filosofia di Debian, orientata alla stabilità ed alla sicurezza). Riguardo all’installazione di Postfix, basta un semplice:

apt-get install postfix

che richiede di specificare che tipo d’installazione di Postfix effettuare, noi sceglieremo “Sito Internet”, senza specificare uno smart host, poiché, nell’ambiente di test, non è necessario spedire mail al “mondo reale”:

Figura 1 - Scelta installazione Postfix

dopodiché, ci verrà richiesto il dominio da utilizzare per la posta elettronica, noi indicheremo il dominio urano.mail, come mostrato in figura 2:

Figura 2 - Scelta del dominio

Ora Postfix è installato, si tratta di fare qualche piccolo aggiustamento alla configurazione. Per prima cosa, abilitiamo la rete LAN del server Titano a mandare posta tramite il nostro MTA aggiornando il parametro mynetworks nel file di configurazione /etc/postfix/main.cf, che diventerà così:

mynetworks = 127.0.0.1/8 192.168.1.0/24

Quindi aggiungiamo due parametri, che indicano la directory di spooling delle mail e il formato di archiviazione dei messaggi delle mailbox, scegliendo Maildir, che creerà una directory Maildir per ogni home directory presente sul sistema:

queue_directory = /var/spool/postfix
home_mailbox = $HOME/Maildir/

Fatto questo, chiudiamo e salviamo il file /etc/postfix/main.cf, quindi possiamo far ripartire Postfix tramite il comando:

/etc/init.d/postfix restart

Ora, possiamo creare gli utenti di sistema, che fungeranno anche da mailbox per il server di posta. Gli utenti non hanno bisogno di un accesso shell, per cui verrà fornita loro la shell /bin/false, e faranno parte del gruppo mail:

useradd -m -g mail -s /bin/false salvor.hardin
useradd -m -g mail -s /bin/false hober.mallow

Ora possiamo provare a mandare una mail da un client di posta già configurato nell’ambiente di test all’indirizzo salvor.hardin@urano.mail, se tutto va come deve andare, dando il seguente comando

ls -l /home/salvor.hardin/Maildir/new

dovremmo vedere un file, ed aprendolo con un editor di testo, è possibile leggere il contenuto che altri non è che il testo della mail precedentemente inviata, comprese le intestazioni. A questo punto possiamo considerare terminata la configurazione di Postfix.

Installazione e configurazione di Dovecot

Per verificare il corretto funzionamento di Postfix, abbiamo consultato il file system del server Titano, ma per un utente “normale”, la cosa è alquanto scomoda. Si impone quindi l’installazione di un server POP3 - IMAP che consenta ad un qualsiasi client con installato un MUA di consultare la posta elettronica. La nostra scelta ricade su Dovecot, il quale ha la simpatica caratteristica di cercare di rendere semplice la propria configurazione e di supportare entrambi i formati di archiviazione della posta più diffusi, mbox e maildir. Per installare Dovecot ricorriamo al solito apt:

apt-get install dovecot-common dovecot-popd dovecot-imapd

Fatto questo, come per Postfix, anche con Dovecot dovremo fare qualche piccola modifica al file di configurazione, il cui percorso è /etc/dovecot/dovecot.conf. Per prima cosa, andremo a specificare quali protocolli rendere disponibili con Dovecot, impostando in questo modo la direttiva protocols:

protocols = imap imaps pop3 pop3s

Scendendo poco più giù nel file di configurazione, configureremo Dovecot in modo tale che accetti le password inviate dal client come testo in chiaro (ciò non è molto sicuro ma ci aiuta a semplificarci la vita in questo ambiente di test), impostando questa direttiva:

disable_plaintext_auth = no

Ora dobbiamo impostare il percorso in cui si trovano le caselle di posta ed il formato in cui sono archiviati, nel nostro caso maildir:

mail_location = maildir:~/Maildir

Il resto del file può essere lasciato invariato, quindi salviamo il file e riavviamo il demone Dovecot, tramite il solito

/etc/init.d/dovecot restart

dopodiché possiamo testare il nostro server IMAP configurando un qualsiasi MUA che supporti il protocollo IMAP; io ad esempio, per velocità, ho testato Windows Mail, il client di posta predefinito di Windows Vista, che funziona senza problemi con il server IMAP Dovecot senza bisogno di accorgimenti particolari, se si esclude il fatto che a prima vista sembra non comparire la cartella Posta in arrivo; in questo caso, basta sottoscrivere la cartella Posta in arrivo, la quale comparirà immediatamente rendendo possibile leggere i messaggi presenti nella casella di posta in oggetto.

Considerazioni personali sui MUA per Windows

Siccome, per i miei test, avevo a disposizione Windows Mail, ho utilizzato quello. Ho testato altri client di posta, cominciando da Microsoft Outlook (quello compreso nella suite Office, per intenderci), ed i risultati sono stati sconfortanti. Utilizzando Outlook 2003 per connettermi in IMAP sul server di posta, per prima cosa sul server vengono create solo le cartelle Posta in arrivo e Posta indesiderata, per cui, tra le altre cose, non viene creata la cartella Posta inviata; se anche creiamo la cartella Posta inviata a mano, con Outlook 2003 non c’è modo di archiviare la posta inviata nella cartella sul server.

Inizialmente, non usando praticamente mai IMAP, pensavo che fosse un mio problema, invece, surfando sul Web, ho potuto constatare che si tratta di una “caratteristica” di Outlook, che è aggirabile solamente creando una regola ad hoc. Per me tutto ciò è delirante. Si comporta leggermente meglio invece Outlook 2007, che ha gli stessi difetti di Outlook 2003, ma il cui comportamento relativamente alla posta inviata è modificabile in modo semplice agendo sulla configurazione dell’account di posta. In questo articolo del blog ilcava.it è descritto come procedere in questi casi. Da quanto ho potuto vedere io, anche con Outlook 2007 la cartella Posta inviata va creata a mano.

A questo punto ho voluto provare anche Thunderbird per Windows, che si comporta decisamente meglio, infatti, basta configurare normalmente un account di posta, che crea solamente le cartelle Posta in arrivo e Cestino, ma al primo invio di un messaggio, viene creata automaticamente sul server la cartella Posta inviata, così come viene creata una cartella Drafts se si salva un messaggio come bozza. Come già segnalato, Windows Mail si comporta piuttosto bene con IMAP.

Non ho provato alcun MUA per Linux, ma immagino che non diano particolari problemi.

Se qualcuno tra i lettori ha qualche suggerimento relativamente a quanto scritto con l’utilizzo di Outlook con IMAP, ed in particolare dell’interazione tra Outlook e Dovecot, i commenti sono a disposizione.

Conclusioni

Dopo aver testato con successo il corretto funzionamento di Postfix e Dovecot, possiamo ritenere conclusi, per il momento, i nostri test. Come scritto nell’avvertenza all’inizio dell’articolo, questa configurazione è adatta solamente a scopi (auto)didattici, poiché, configurando in questo modo un server di posta, non abbiamo nessuna protezione contro i virus, contro lo spam e contro il phishing (anche se, soprattutto nell’ultimo caso, la miglior protezione l’abbiamo sopra le spalle, basta usarla), inoltre, non utilizziamo quegli strumenti (come database relazionali o LDAP) per definire domini virtuali e caselle di posta. In poche parole, questa configurazione è decisamente migliorabile, e questi passi in avanti saranno oggetto dei prossimi articoli sull’argomento.

Link di riferimento

• Postfix (home page)
• Dovecot (home page)
• Protocollo SMTP (Wikipedia)
• Protocollo POP3 (Wikipedia)
• Protocollo IMAP (Wikipedia)
• MTA, MDA, MUA (Documentazione Red Hat Linux)
• Configurazione di Postfix (Blog di Marco Buttignon)