Ricerche IT

Scenario

Facendo riferimento ai due precedenti articoli su Postfix e Dovecot, dove si era vista una configurazione minimale di un server di posta e l’utilizzo di alias e domini virtuali, sempre basandoci sull’ambiente di test precedentemente illustrato, in questo articolo vedremo come utilizzare le mailbox virtuali su Postfix, e quindi come accedere a queste mailbox con Dovecot. L’utilizzo di mailbox virtuali è un passo avanti rispetto alle configurazioni precedentemente trattate, poiché con questo tipo di caselle di posta elettronica, facciamo in modo che le mailbox siano completamente distinte dagli utenti di sistema, in questo modo non saremo costretti a creare un utente Linux da utilizzare ogniqualvolta abbiamo bisogno di una casella di posta. Oltre alle mailbox, avremo anche dei domini virtuali, in tal modo potremo ospitare sullo stesso server caselle di posta elettronica riferite a diversi domini, con tutti i vantaggi del caso. Le informazioni su mailbox e domini virtuali saranno contenute in file di testo sul file system del sistema operativo.

Configurazione di Postfix

Andremo a configurare mailbox virtuali sul server Giapeto per i domini cerere.mail e saturno.mail. In questa situazione, se esistono, è bene cancellare dal file di configurazione /etc/postfix/main.cf tutte le impostazioni relative ad alias e domini virtuali, poiché queste impostazioni andranno eventualmente riscritte secondo il formato richiesto dalle mailbox virtuali. La configurazione precedentemente descritta si esplicita nelle seguenti direttive nel file di configurazione /etc/postfix/main.cf; le altre informazioni riferite ai parametri basilari di Postfix rimangono quelle descritte nell’articolo riguardante la configurazione di base di Postfix:

1
2
3
4
5
6
7

virtual_mailbox_domains = cerere.mail saturno.mail
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

La prima riga fa riferimento ai domini virtuali per i quali il sistema è abilitato a ricevere messaggi di posta, cioè cerere.mail e saturno.mail. La seconda riga fa riferimento alla directory di base scelta come deposito di tutta la posta ricevuta su questo server, al cui interno vi saranno le varie sottodirectory relative ai domini virtuali, e per ogni dominio virtuale vi saranno le directory riferite alle varie mailbox di quel dominio, dove verrà depositata la posta elettronica, secondo il formato di archiviazione Maildir, come vedremo di seguito. La terza riga indica il file dove vengono elencate le mailbox virtuali definite sul sistema e la loro posizione sul file system, a partire dalla directory definita in precedenza col parametro virtual_mailbox_base. La quarta riga specifica l’id minimo dell’utente utilizzato dal sistema per andare a scrivere i file rappresentanti i messaggi di posta sul file system, nella posizione indicata con il parametro virtual_mailbox_base; questo utente avrà un ID utente e un ID di gruppo, specificati con precisione nella quinta e nella sesta riga della porzione del file di configurazione specificata poco sopra. La settima e ultima riga è opzionale, e indica la posizione del file contenente gli alias virtuali delle mailbox virtuali effettive, come descritto nell’articolo precedente riguardante gli alias virtuali, anche se nell’articolo precedente gli alias si riferivano alle mailbox di sistema e non a quelle virtuali.

Modificata la configurazione di Postfix, creiamo la directory che conterrà le mailbox virtuali:

mkdir /var/spool/vmail

Ora invece dobbiamo creare la mappa che conterrà l’elenco delle mailbox virtuali definite sul sistema:

touch /etc/postfix/vmailbox

Quindi andremo ad editare il file vmailbox appena creato per definire l’elenco delle mailbox sul nostro sistema, in questo modo:

1
2
3
4

salvor.hardin@cerere.mail   cerere.mail/salvor.hardin/
hober.mallow@cerere.mail    cerere.mail/hober.mallow/
preem.palver@saturno.mail   saturno.mail/preem.palver/
stor.gendibal@saturno.mail  saturno.mail/stor.gendibal/

Questo è un tipico file di mappa di Postfix, dove nella prima colonna sono indicate le mailbox virtuali, mentre nella seconda è indicato il percorso della casella in cui andrà depositata la posta, a partire dalla “radice” che altro non è che il percorso indicato nella direttiva virtual_mailbox_base del file main.cf, come visto in precedenza; ad esempio, la posta della mailbox virtuale salvor.hardin@cerere.mail verrà depositata nella directory /var/spool/vmail/cerere.mail/salvor.hardin. Da notare lo slash (/) alla fine del percorso di ogni mailbox virtuale, il quale indica a Postfix di archiviare la posta nel formato Maildir.

Creare a questo punto la mappa in formato .db partendo dal file appena editato:

postmap /etc/postfix/vmailbox

Ora editiamo il file di mappa /etc/postfix/virtual in cui andare ad inserire gli alias per le mailbox virtuali:

1
2
3
4

postmaster@cerere.mail    salvor.hardin@cerere.mail
abuse@cerere.mail         salvor.hardin@cerere.mail
postmaster@saturno.mail   preem.palver@saturno.mail
abuse@saturno.mail        preem.palver@saturno.mail

e compiliamo quindi la mappa degli alias:

postmap /etc/postfix/virtual

Configurazione di Dovecot

Configurato Postfix, dobbiamo informare anche Dovecot delle mutate impostazioni di archiviazione della posta elettronica, per cui Dovecot dovrà essere informato della nuova posizione delle mailbox; inoltre, Dovecot non si baserà più sugli utenti di sistema per l’autenticazione sulla casella di posta, per cui andremo a fornirgli un file in cui sono elencati gli utenti ed un file in cui sono elencate le relative password, secondo lo schema stesso di Linux, basato su un file passwd dove sono indicati gli utenti, ed un file shadow dove sono elencate le password. Di seguito vediamo le impostazioni da inserire nel file di configurazione di Dovecot /etc/dovecot/dovecot.conf, fare attenzione ad aprire e chiudere le graffe, esistenti e non, all’interno del file di configurazione:

1
2
3
4
5
6
7
8
9
10

mail_location = Maildir:/var/spool/vmail/%d/%n
auth default {
  mechanisms = plain login
  userdb passwd-file {
    args = /var/spool/vmail/%d/etc/passwd
  }
  passdb passwd-file {
    args = /var/spool/vmail/%d/etc/shadow
  }
}

Nella riga 1 andiamo a specificare la posizione in cui Dovecot andrà a leggere la posta archiviata da Postfix, utilizzando delle variabili; ciò consente a Dovecot di leggere la posta di più domini, utilizzando la variabile %d, che indica la parte dopo la chiocciola dell’indirizzo di posta (il dominio), e la variabile %n, che indica la parte prima della chiocciola dell’indirizzo di posta (il nome utente): tra l’altro, ciò comporta l’accortezza di autenticarsi indicando, alla richiesta del nome utente, l’indirizzo completo di posta.

La seconda riga indica l’inizio della sezione riguardante le impostazioni di autenticazione su Dovecot, che sono evidenziate ad iniziare dalla terza riga, che indica i meccanismi di transito sulla rete delle password, che nel caso illustrato vengono trasmesse in chiaro per l’autenticazione su Dovecot; questo causa qualche problema di sicurezza, poiché le password viaggiano in chiaro sulla rete, quindi basta sniffarla il tempo necessario per carpire le password. Quarta e quinta riga indicano la posizione del file in cui sono indicati gli utenti possessori di una casella di posta, mentre settima e ottava riga indicano il percorso del file contenente il nome utente e la relativa password; da notare che anche in questo caso è stata utilizzata la variabile %d, seguita dalla directory etc/ che conterrà i due file: tale directory è stata creata semplicemente per coerenza con la struttura delle directory Linux, ma non è assolutamente necessaria.

Creazione directory, utenti e password

Ora bisogna creare gli utenti e le password sia per l’accesso di Postfix alla directory /var/spool/vmail, sia per l’autenticazione su Dovecot da parte di un qualsiasi MUA (Mail User Agent). Cominciamo creando l’utente di sistema che useremo per l’accesso alla directory in cui saranno contenute le mailbox virtuali:

useradd -d /var/spool/vmail -s /bin/false -m -U -u 5000 vmail

Con questo comando creiamo l’utente vmail, a cui assegnamo la home directory /var/spool/vmail e la shell “fasulla” /bin/false, ed a cui assegnamo l’id utente 5000, come indicato nella configurazione di Postfix; inoltre, con l’opzione –U andiamo a creare un gruppo con caratteristiche identiche all’utente appena creato. È possibile notare che la home directory assegnata all’utente vmail corrisponde alla directory indicata in Postfix come directory “root” per l’archiviazione di posta elettronica, in questo modo assegnamo subito a questo utente l’ownership (ovvero la proprietà) della directory, poiché sarà l’utente vmail che effettivamente avrà il compito di archiviare sul file system la posta elettronica.

Il passaggio successivo consiste nel creare le directory relative ai domini, ai file contenenti utenti e password, ed alle mailbox virtuali. Iniziamo con le directory relative ai domini cerere.mail e saturno.mail:

1
2

mkdir /var/spool/vmail/cerere.mail
mkdir /var/spool/vmail/saturno.mail

Ora creiamo la directory etc per ogni dominio, che conterrà i file relativi ad utenti e password corrispondenti alle mailbox virtuali create per ogni dominio; gli utenti e le password verranno utilizzati da Dovecot per autenticare l’accesso alle caselle di posta virtuali:

1
2

mkdir /var/spool/vmail/cerere.mail/etc
mkdir /var/spool/vmail/saturno.mail/etc

Ora andiamo a creare, per ogni dominio, il file degli utenti (passwd) e delle password (shadow), coerentemente con quanto indicato nel file di configurazione di Dovecot:

1
2
3
4

touch /var/spool/vmail/cerere.mail/etc/passwd
touch /var/spool/vmail/cerere.mail/etc/shadow
touch /var/spool/vmail/saturno.mail/etc/passwd
touch /var/spool/vmail/saturno.mail/etc/shadow

Creati i file, bisogna inserire il contenuto relativo a utenti e password, di seguito sono elencati i comandi per inserire i contenuti dei due file degli utenti passwd:

Utenti per il dominio cerere.mail

1
2

echo salvor.hardin::5000:5000::/var/spool/vmail/cerere.mail/salvor.hardin >> /var/spool/vmail/cerere.mail/etc/passwd
echo hober.mallow::5000:5000::/var/spool/vmail/cerere.mail/hober.mallow >> /var/spool/vmail/cerere.mail/etc/passwd

Utenti per il dominio saturno.mail

1
2

echo preem.palver::5000:5000::/var/spool/vmail/saturno.mail/preem.palver >> /var/spool/vmail/cerere.mail/etc/passwd
echo stor.gendibal::5000:5000::/var/spool/vmail/saturno.mail/stor.gendibal >> /var/spool/vmail/cerere.mail/etc/passwd

Dall’analisi di questi file, si può intuire che nel file viene indicato il nome utente, poi l’ID utente e di gruppo (il 5000 preso per l’utente locale vmail), quindi viene indicata la directory in cui Dovecot andrà a leggere la posta per quell’utente

Ora bisogna popolare il file shadow con le password degli utenti. Siccome voglio che le password siano criptate (ad esempio utilizzando l’algoritmo md5, anche se non è il più sicuro che esista), per generare le password dovrò utilizzare il comando dovecotpw. Ad esempio, per assegnare a tutti gli utenti la password Password00, dovrò scrivere qualcosa del genere:

Password per il dominio cerere.mail

1
2

echo salvor.hardin:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow
echo hober.mallow:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

Password per il dominio saturno.mail

1
2

echo preem.palver:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow
echo stor.gendibal:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow

A questo punto, avendo trafficato con l’utente root all’interno della directory /var/spool/vmail, è necessario reimpostare l’ownership della directory e del suo contenuto con il comando

chown –R 5000:5000 /var/spool/vmail

Collaudo del sistema

Per testare il server di posta elettronica, è sufficiente inviare una mail ad uno degli indirizzi di posta appena creati, e Postfix, alla ricezione della mail, creerà la directory in cui depositare la posta e che rappresenterà il deposito di tutta la posta per quella determinata mailbox. Se voglio controllare cosa accade durante la ricezione della mail, sia per curiosità, sia per motivi di troubleshooting, è possibile consultare il log della posta, contenuto nel file /var/log/mail.log, che ci darà tutte le informazioni che ci necessitano. Se invece voglio controllare in tempo reale che accade, posso utilizzare un’opzione sciccosa del comando tail in questo modo:

tail –f /var/log/mail.log

che mi mostrerà appunto in tempo reale le righe che vengono eventualmente aggiunte al file /var/log/mail.log.

Conclusioni

Questa configurazione comincia ad essere un tantino più professionale rispetto alle configurazioni proposte in precedenza, infatti ora possiamo gestire con maggiore flessibilità più domini ed i relativi utenti, che non sono più utenti di sistema, per cui possiamo avere lo stesso nome utente per domini diversi. Questa configurazione però ha anche alcuni difetti, ovvero il metodo di creazione di utenti e password per l’accesso alla posta elettronica, che è un po’ macchinoso basandosi sulla riga di comando; un’altra mancanza non indifferente è rappresentata dal fatto che sostanzialmente, con questa configurazione, ci fidiamo di tutto ciò che ci arriva, poiché non vi sono restrizioni sulla posta in arrivo.

Per la definizione delle mappe delle mailbox virtuali e degli alias, nonché per la definizione di utenti e password per Dovecot, vedremo in seguito una configurazione in cui Postfix e Dovecot utilizzano MySQL al posto delle tecniche trattate finora, mentre per spam e antivirus verranno analizzati alcuni strumenti come greylist e blacklist, e ClamAV come sistema di scansione antivirus della posta elettronica. Rimane fondamentale una corretta configurazione di Postfix per impedire che il nostro MTA funga da open relay, ciò dipende essenzialmente, per quanto visto finora, da ciò che si inserisce nel parametro mynetworks, come illustrato negli articoli precedenti.

Link di riferimento

How to configure PostFix and Dovecot for Virtual Users with out a Database

Scenario

Su una rete con un dominio Microsoft Windows Server 2003, con un’organizzazione Exchange Server 2003, è stato abilitato il Push Direct per la sincronizzazione di un dispositivo mobile (PDA, Smartphone, ecc…) tramite Exchange ActiveSync. Nella situazione che ho affrontato, il client ActiveSync è un Nokia N73 con installato MailForExchange, anche se in questa situazione il client utilizzato non ha nessuna importanza.

Problema

Lo scenario sopra riportato, funziona perfettamente, tranne che per un piccolissimo dettaglio: le mail nuove, non ancora lette, non vengono sincronizzate con il client, ovvero, Nokia MailForExchange non sincronizza i messaggi fino a quando questi non sono letti in un altro modo, cioé tramite Outlook oppure OWA; dal punto di vista dell’utente non è molto comodo. La configurazione di Exchange e di MailForExchange è stata rivista e rivoltata fino allo sfinimento, senza trovare una soluzione funzionante, anche perché, alla fine, non era lì il problema…

Soluzione

Non essendoci problemi nella configurazione, rimane qualcosa di esterno alle applicazioni utilizzate; infatti, una volta disabilitato Trend Micro ScanMail for Exchange, la sincronizzazione dei messaggi funziona in tutte le situazioni, sia con i vecchi che con i nuovi messaggi. Una volta individuato il responsabile, bisogna metterlo in condizione di non nuocere, ma a quel punto, la ricerca della soluzione al problema diventa abbastanza semplice; grazie a Google, ho potuto verificare che il problema consiste nell’aggiornamento di Trend Micro ScanMail for Exchange dalla versione 7 alla versione 8, il quale lascia una voce di registro chiamata VirusScanProactiveScanning in queste chiavi (i numeri dopo Private- e Public- sono puramente indicativi):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<servername>\Private-3484c833-f074-4793-97a0-0bbbcdbb7c75

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<servername>\Public-a785d57d-8a08-44ce-86c4-04bfea4691e5

per eliminare il problema basta cancellare la voce di registro incriminata e riavviare i servizi di ScanMail, a questo punto, il problema è risolto e possiamo goderci la nostra mail push sul telefonino.

Link di riferimento

http://social.technet.microsoft.com/Forums/en-US/exchangesvrmobility/thread/f37095ac-3e52-474e-9467-46872242469e

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.

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)

Una delle situazioni più antipatiche che un amministratore di un server di posta deve affrontare, è la richiesta da parte di qualche utente (che, sapendo di romperti le scatole, ed essendo in difficoltà, farà la richiesta nel modo più suadente possibile) di recuperare un messaggio/elemento (o più messaggi/elementi) cancellato per sbaglio. In genere la cosa è piuttosto antipatica, soprattutto se si tratta di andare a ripristinare dei messaggi dai nastri di backup.

Nel caso di Exchange, un ripristino da backup è un’operazione piuttosto delicata, poiché, se non si segue una strategia intelligente, il ripristino è un vero delirio; ad esempio, se si fa solamente il backup dello store, tramite ntbackup, bisogna ripristinare lo store, montarlo a parte e poi estrarre ciò che serve, questo almeno in linea teorica, io per fortuna non ho mai dovuto compiere quest’operazione, che secondo me equivale ad un impeto masochistico degno del miglior Tafazzi.

Rimanendo nell’ambito del backup, una strategia un minimo più intelligente può essere quella di utilizzare uno strumento come Exmerge (descritto, anche se non in modo completo, in quest’articolo), oppure un software di backup che consenta di effettuare il salvataggio delle singole cassette postali.

In ogni caso il ripristino di un backup è sempre una grossa rottura, ma, nel caso di Exchange, esistono strumenti per poter ripristinare gli elementi cancellati, a patto che questi non siano stati cancellati da più di una settimana (Exchange conserva gli elementi cancellati per una settimana come impostazione predefinita).

Nel caso siano stati cancellati alcuni messaggi o altri tipi di elementi dalla propria cassetta postale (per cancellati si intende che i messaggi sono stati rimossi anche dalla posta eliminata), è possibile utilizzare una funzione di Outlook, che consiste nell’entrare nella cartella Posta eliminata, quindi andare sul menu Strumenti -> Recupera posta eliminata, dove è possibile recuperare i messaggi cancellati da non più di una settimana, come mostrato nella figura seguente:

Figura 1 - recupera posta eliminata

Da questa finestra è possibile decidere se ripristinare l’elemento in Posta eliminata oppure se rimuoverlo definitivamente.

Diverso il caso se si cancella per errore uno o più elementi da una cartella pubblica, poiché, in questo caso, gli elementi cancellati non finiscono nella cartella Posta eliminata, ma semplicemente svaniscono. In realtà, è possibile ripristinare gli elementi eliminati dalle cartelle pubbliche utilizzando il tool PFDAVAdmin rilasciato da Microsoft, il cui utilizzo principale consiste nella gestione centralizzata delle autorizzazioni sulle cartelle pubbliche, ma che può essere utilizzato ottimamente per ripristinare elementi rimossi incautamente da una cartella pubblica. Una volta scompattato PFDAVAdmin, lanciare l’eseguibile dal server Exchange utilizzando l’account Administrator, quindi cliccare sul menu File -> Connect ed impostare il valore del server Exchange e del Global Catalog dell’organizzazione, lasciando selezionata l’opzione Public Folders, come illustrato in figura 2:

Figura 2 - finestra di connessione di PFDAVAdmin

Effettuata la connessione, espandere l’albero a sinistra e andare a selezionare la cartella pubblica da cui vogliamo recuperare l’elemento cancellato, quindi, selezionare la scheda Items e l’opzione in basso Deleted contents, quindi selezionare l’elemento/gli elementi da recuperare, cliccare col tasto destro e selezionare la voce Recover items, come evidenziato in figura 3:

Figura 3 - finestra di recupero elementi di PFDAVAdmin

Una volta cliccato su Recover Items, cliccare Ok sulla finestra di notifica dell’avvenuto ripristino, dopodiché verificare che l’elemento sia stato effettivamente ripristinato, cosa che in genere avviene.

La cosa bella di questo tool, è che le stesse operazioni è possibile compierle anche sulle cassette postali dell’intera organizzazione, a patto di avere le autorizzazioni del caso sulle mailbox dei singoli utenti; per poter gestire le cassette di posta, nella finestra di connessione mostrata in Figura 2 bisogna indicare l’opzione All mailboxes in luogo dell’opzione Public Folders.

Link di riferimento

http://support.microsoft.com/?scid=kb%3Ben-us%3B924044&x=4&y=9

ExMerge è un’utilità fornita da Microsoft, che consente di esportare o importare, da o verso Exchange, cassette postali in formato .PST. Questa utility è utile soprattutto quando è necessario spostare le cassette postali da un server Exchange ad un altro server Exchange, oppure se si vuole fare un “backup dei poverelli” delle cassette di posta, utile se per fare il salvataggio di Exchange abbiamo solo NTBackup, che fa il backup dell’Information Store ma non delle singole caselle di posta.

Per utilizzare ExMerge, dobbiamo assicurarci di non avere nella nostra organizzazione cassette postali superiori ai 2GB; se queste esistono, è necessario ridurre le loro dimensioni, dopodiché, è possibile scaricare ExMerge dal sito Microsoft, file che quindi va scompattato, per poi copiare i file ExMerge.exe e ExMerge.ini nella cartella degli eseguibili dell’installazione di Exchange, “c:\Percorso-Cartella-Installazione-Exchange\bin”. Prima di poter eseguire l’utility però, bisogna compiere alcuni passi preliminari:

1. creare e/o modificare un utente che abbia accesso alle cassette postali con i privilegi “Send as” e “Receive as”
2. fermare, se necessario, il servizio SMTP per non ricevere ed inviare messaggi di posta durante la fase di esportazione/importazione
3. effettuare un salvataggio completo dell’Information Store, per poterlo ripristinare in caso di problemi

Il passaggio n. 1 consiste nella creazione di un utente, che chiameremo ExMerge, che possa accedere alle cassette postali di tutti gli utenti con i privilegi “Send as” e “Receive as”. Per creare l’utente, utilizzare la console “Active Directory Users and Computers”, e da qui rendere l’utente appartenente al gruppo Administrators (già presente di default in ogni installazione di Windows Server 2003), dopodiché, delegare l’amministrazione dell’organizzazione Exchange all’utente ExMerge andando su System Manager, quindi cliccare col tasto destro sul nome dell’organizzazione Exchange e selezionare la voce “Delegate Control”, che apre un wizard, da lì aggiungere l’utente ExMerge agli utenti che già hanno la possibilità di amministrare Exchange, avendo cura di assegnargli il ruolo “Exchange Full Administrator”, quindi terminare il wizard confermando le scelte effettuate. A questo punto, bisogna fare i conti con le impostazioni predefinite di Exchange Server 2003, che per gli utenti facenti parte di un gruppo amministrativo (come appunto il gruppo Administrators), nega l’autorizzazione “Send As” e “Receive As” sul (o sui) Mailbox Store, per cui, bisogna impostare in modo esplicito le autorizzazioni “Send As” e “Receive As” sul Mailbox Store per l’utente ExMerge, oppure creare un gruppo di protezione specifico per gli utenti che vogliamo abilitare a questo compito, e delegare a questo gruppo l’amministrazione di Exchange. In questo caso, avendo bisogno di un unico utente, possiamo evitare di creare un gruppo di protezione.

Ora eseguire, se necessario, il passaggio numero 2 e fermare il servizio SMTP, per impedire che vengano spediti e ricevuti ulteriori messaggi di posta, che in una fase di migrazione o ripristino possono incasinare per bene le cose, e che comunque possono essere perduti al termine di questa fase. Non rimane altro da fare che effettuare un salvataggio dell’Information Store, o tramite un software di backup o semplicemente copiando il contenuto della cartella mdbdata (o comunque della cartella in cui è posizionato il database delle mailbox di Exchange).

A questo punto, è possibile far partire ExMerge, non con un doppio click ma cliccando col tasto destro sull’eseguibile selezionando la voce “Run as”, quindi specificare l’utente ExMerge appena creato e cliccare Ok. Ora possiamo scegliere tra due modalità, la modalità “One Step”, che esegue un salvataggio dello store ed un ripristino su un altro server in un unico passaggio - e la modalità “Two Step”, che consente di effettuare l’esportazione e l’importazione delle cassette postali in due fasi distinte, utile se vogliamo fare un backup o un restore delle cassette postali sullo stesso server Exchange.

In questo caso, vediamo la modalità Two Step: dopo aver scelto questa voce, viene richiesto se effettuare lo Step 1 (esportazione) o lo Step 2 (importazione), quindi, dopo aver scelto di fare l’esportazione delle cassette postali, specificare il server Exchange dal quale si vogliono estrarre le cassette di posta, indicando anche il Domain Controller del dominio per velocizzare le operazioni, tenere presente però che il DC va indicato con attenzione se ci troviamo in un ambiente multidominio, poiché verranno esportate solamente le cassette postali facenti parte del dominio a cui appartiene il DC indicato nella casella “Domain Controller (DC) Name”

Giunti fin qui, ExMerge richiede quali cassette di posta vogliamo esportare (nel nostro caso tutte), quindi, una volta selezionate le mailbox che ci interessano, andiamo avanti e selezioniamo l’impostazione della lingua di default (nel nostro caso Italiano) e selezioniamo, per maggior sicurezza, anche il flag “Use last mailbox login locale”, che consente di utilizzare l’impostazione della lingua utilizzata su una determinata casella durante l’ultimo accesso alla stessa.

Ora dobbiamo selezionare la cartella di destinazione in cui salvare i file .PST delle mailbox, quindi, fatto questo, possiamo procedere con l’estrazione vera e propria, la cui durata dipende ovviamente dal numero di caselle di posta e dal loro “peso”. Finita l’esportazione, è possibile controllare il file ExMerge.log per verificare che non vi siano stati errori in questa fase. Se tutto è andato bene, avremo una sorta di backup di tutte le cassette di posta della nostra organizzazione, che sono ripristinabili in ogni momento, con il vantaggio, a differenza di un salvataggio generico dell’Information Store, che possiamo effettuare il restore anche della singola casella postale.

Il restore di una cassetta di posta può essere fatto sempre con ExMerge, e sempre con le stesse modalità descritte in precedenza, tranne che per la scelta dello Step, infatti per effettuare un ripristino deve essere scelto lo Step 2, come mostrato nella figura sottostante:

La cosa a cui dobbiamo prestare attenzione in questa fase, è la modalità di importazione o ripristino della cassette di posta, infatti, quando ci viene richiesto il server Exchange sul quale vogliamo ripristinare le mailbox, è bene, prima di andare avanti, premere il pulsante “Options” e indicare con che modalità avviene il ripristino.

Dall’immagine precedente, è possibile vedere che nella scheda “Import procedure” ci viene richiesto come ripristinare gli elementi della cassetta postale; trattandosi di un ripristino, la cosa più probabile è che si vogliano sovrascrivere gli elementi già presenti, opzione attivabile cliccando su “Replace existing data in target store”, anche se la scelta da effettuare dipende sempre dal contesto nel quale ci troviamo. Ora è possibile proseguire seguendo i passi svolti in precedenza, facendo attenzione a selezionare la cartella sorgente dalla quale pescare i file .PST salvati in precedenza, dopodiché è possibile procedere con il restore vero e proprio. Se tutto è andato bene, avremo ripristinato le nostre cassette di posta, in ogni caso, è sempre bene verificare tramite il file di log (ExMerge.log) che non vi siano stati errori non bloccanti.

E’ importante ricordare che il formato del file .PST creato da ExMerge è quello di Outlook 97-2002, per cui, viene a mancare il supporto ai file con dimensioni superiori ai 2GB, come accennato in precedenza; ho avuto un’esperienza del genere, la quale mi ha insegnato che ExMerge non ha apparentemente problemi a creare file .PST maggiori di 2GB, ma poi, quando si tenta di ripristinare la cassetta postale salvata, viene restituito un errore generico che ci informa che l’importazione del file PST non è andata a buon fine, quindi, spulciando il log di ExMerge (il file ExMerge.log, presente nella cartella in cui abbiamo salvato ExMerge.exe, l’eseguibile dell’utilità) troviamo questa riga:

Error configuring message service (MSPST MS) (UNKNOWN ERROR) (CMapiSession::CreateEMSPSTProfile)

Da questa piccola disavventura, si può trarre l’insegnamento che, in caso di utilizzo di ExMerge, è bene verificare, prima di lanciarlo, che le cassette postali di Exchange non superino i 2GB di dimensione; ancor meglio sarebbe utilizzare delle mailbox quota che impediscano di avere cassette postali più grandi di una certa dimensione, ma questo non sempre si può fare, purtroppo molta gente continua ad utilizzare la posta elettronica in modo improprio, tenendo nella propria casella di posta migliaia di messaggi semplicemente temendo la remota possibilità che servano in un imprecisato futuro.

Link di riferimento:
http://blogs.ugidotnet.org/alexblog/articles/24659.aspx (bell’articolo su ExMerge)
http://support.microsoft.com/kb/292509 (impostazione di un gruppo di protezione per l’utilizzo di ExMerge, io ho usato una strada leggermente diversa)
http://technet.microsoft.com/it-it/library/aa997470(EXCHG.65).aspx (strategie e procedure consigliate per ExMerge)

Se si utilizza Exchange come server di posta elettronica, la configurazione predefinita prevede un invio diretto dei messaggi di posta utilizzando il server DNS predefinito configurato sul server stesso per la risoluzione dei nomi di dominio e per l’interrogazione sul record MX del dominio del destinatario, quindi si connette direttamente ai server SMTP dei destinatari delle mail per il recapito dei messaggi. Ciò però non sempre è possibile, ad esempio perché un range di indirizzi è finito in una blacklist, quindi, per evitare questi problemi, ci si può appoggiare ad un server SMTP esterno alla nostra organizzazione per l’invio delle mail, che prende il nome di "smart host".

Per impostare uno smart host, su Exchange come su qualsiasi altro server di posta, dobbiamo considerare che in genere i provider consentono l’accesso al proprio server SMTP solo a quegli host che si connettono sulla loro rete, quindi è bene utilizzare il server SMTP del proprio provider, anche se alcuni provider richiedono anche informazioni di autenticazione sul server SMTP per poter inviare messaggi; Exchange prevede due metodi di configurazione di un server SMTP esterno: l’impostazione dello smart host sul server virtuale SMTP e la creazione di un connettore SMTP.

Per impostare uno smart host sul server SMTP virtuale andare su System Manager e fare il percorso Servers -> NomeServer -> Protocols -> SMTP -> tasto destro su Default SMTP Virtual Server, quindi cliccare su Properties, da lì andare sul tab Delivery e quindi andare sul pulsante Advanced e lì impostare l’indirizzo del server SMTP esterno nella casella "Smart host"; l’indirizzo da impostare può essere un normale indirizzo FQDN oppure un indirizzo IP compreso tra parentesi quadre (es. [1.1.1.1]), quindi una volta impostato cliccare su Ok per tornare alla schermata precedente. A questo punto, si può cliccare di nuovo su Ok se la configurazione è completata, oppure si deve cliccare sul pulsante "Outbound security" se bisogna inserire anche informazioni di autenticazione per poter inviare messaggi tramite il server SMTP esterno; in quest’ultimo caso, cliccare su "Basic autentication" ed inserire nome utente e password, quindi mettere un segno di spunta sulla voce "TLS encryption" se è necessario stabilire una connessione criptata con lo smart host. Ora non rimane che cliccare due volte su Ok, quindi basta riavviare il servizio SMTP per attivare le nuove impostazioni.

L’altro modo per configurare uno smart host consiste nella creazione di un connettore SMTP. Un connettore SMTP permette di stabilire la connessione tra il nostro server Exchange (o tra i diversi server Exchange della nostra organizzazione) e il mondo esterno, inoltre, un connettore SMTP ci dà anche la possibilità di utilizzarlo per inviare posta solamente verso certi domini, oltre a permettere di bilanciare il carico tra i diversi server Exchange presenti sulla nostra rete. Quando si crea un connettore SMTP bisogna, tra le altre cose, impostare la modalità di recapito della posta in uscita, cioè bisogna dire se spedire la posta direttamente utilizzando DNS per la risoluzione dei nomi oppure se utilizzare uno smart host, che è la situazione che interessa a noi. Per impostare lo smarthost, basta selezionare la voce "Forward all mail through this connector to the following smart hosts" e digitare il nome del server SMTP a cui inoltreremo la mail provenienti dalla nostra organizzazione; anche in questo caso, valgono le considerazione fatte in precedenza in merito all’eventuale autenticazione sul server SMTP smart host. Ora bisogna impostare almeno un server Exchange "bridgehead" (testa di ponte) responsabile dell’invio della posta tramite il connettore che si sta creando; se abbiamo un unico server Exchange nella nostra organizzazione, questo andrà impostato obbligatoriamente come server bridgehead. Ora rimane da impostare lo spazio degli indirizzi del connettore, cioè bisogna specificare se il connettore è responsabile dell’invio di messaggi per ogni dominio esistente o solamente per alcuni domini, quindi, andare sul tab "Address space", cliccare su Add e digitare * se si vogliono comprendere tutti i domini come indirizzi validi per il connettore (impostazione predefinita), dopodiché, poco più in basso, è possibile specificare l’ambito di validità del connettore (Connector scope), se non si ha un’organizzazione complessa lasciare l’impostazione di default "Entire organization".

Seguendo uno dei due metodi sopra esposti, è possibile utilizzare un server esterno alla nostra organizzazione per inviare messaggi di posta elettronica.

Dopo un’installazione di Exchange Server 2003, vanno create le relative cassette di posta, e qui la situazione dipende da cosa si è fatto prima di installare Exchange: se erano presenti già in precedenza utenti di Active Directory (AD), dopo aver installato Exchange bisogna creare una cassetta di posta per gli utenti già esistenti, mentre per tutti gli utenti AD creati successivamente all’installazione di Exchange, è necessario indicare in fase di creazione se associare o meno una nuova cassetta di posta all’utente.

In entrambi i casi, gli indirizzi di posta elettronica vengono assegnati automaticamente alla cassetta di posta seguendo un determinato criterio, definito nella "default policy" visualizzabile andando su System Manager -> Recipients -> Recipient Policies; il criterio predefinito corrisponde al dominio di Active Directory, per cui se ho un utente con alias "utente" ed ho un dominio AD con nome DNS "dominio.lan", l’indirizzo di posta creato in modo predefinito è "utente@dominio.lan". Questo tipo di indirizzamento ha solamente validità locale, e siccome di certo non installiamo Exchange solo per la comunicazione interna, è necessario cambiare la policy predefinita, aggiungendo una policy con una priorità più alta (cioé col numero più basso) oppure modificando direttamente la policy predefinita, in modo da avere indirizzi di posta con un dominio identico al dominio registrato dalla nostra società; inoltre, è possibile personalizzare la parte a sinistra dell’indirizzo e-mail utilizzando le variabili messe a disposizione da Exchange.

Per creare una nuova policy, andare su System Manager -> Recipients -> Recipient Policies e quindi cliccare sul menu Action -> New e quindi scegliere "Recipient policy", si aprirà una finestra di dialogo in cui dobbiamo indicare se la nuova policy riguarda gli indirizzi di posta elettronica (E-mail Addresses) o se riguarda la gestione delle cassette postali (Mailbox Manager Settings), in questo caso scegliamo la prima voce, E-mail Addresses, clicchiamo su Ok e comparirà la finestra in cui, per prima cosa, va inserito un nome per definire il criterio (in questo caso, chiameremo la policy "Dominio Aziendale"), quindi, cliccheremo sul pulsante "Modify" per creare un filtro che applichi la policy solo a determinati elementi presenti in Active Directory; la lista degli elementi a cui è possibile applicare è mostrata in figura 1:

Figura 1

Nella maggior parte dei casi, sarà sufficiente selezionare solamente "Users with Exchange mailbox", poiché difficilmente useremo la stessa policy per gli utenti e per i gruppi, più probabilmente gli utenti seguiranno un criterio ed i gruppi un altro criterio, quanto ai Contatti, è improbabile definire per essi una policy comune; da notare che, cliccando sulla scheda Advanced, è possibile creare dei filtri con criteri più stringenti per selezionare solamente, ad esempio, parte degli utenti con cassette di posta rispondenti a determinati criteri. Fatto questo, cliccare su Ok ed ancora su Ok al messaggio successivo, quindi andare sulla scheda "E-mail Addresses (Policy), cliccare sulla voce SMTP presente (corrispondente alla policy di default di Exchange) e cliccare sul pulsante "Edit" per modificare il criterio; a questo punto, è opportuno conoscere le variabili necessarie per comporre la nostra policy, che si baserà su nome e cognome dell’utente:

%g -> Given name -> Nome
%s -> Surname -> Cognome

Se ad esempio abbiamo il dominio dell’azienda che prende il nome di "nomeazienda.com" e vogliamo che gli indirizzi aziendali siano tutti del tipo "mario.rossi[at]nomeazienda.com", dovremo specificare la seguente policy:

%g.%s@nomeazienda.com

In realtà, molto spesso le aziende usano spesso indirizzi del tipo "m.rossi@nomeazienda.com", ed in questo caso, per avere il risultato voluto, nella policy bisogna scrivere questa stringa:

%1g.%s@nomeazienda.com

dove 1 indica che andrà preso per la variabile %g solamente il primo carattere, in questo caso l’iniziale del nome appunto (per ulteriori informazioni sulle variabili utilizzabili in questo contesto consultare la relativa pagina della Knowledge Base Microsoft). Una volta scritto il criterio, cliccare su Ok e quindi su Yes, e la policy è attiva. Gli indirizzi di posta verranno quindi modificati a seconda dell’intervallo di aggiornamento specificato in "Recipient Update Services" presente nella voce "Recipients" nella struttura generale di System Manager. E’ possibile specificare in seguito una ulteriore policy per i gruppi di distribuzione, ad esempio utilizzando le variabili %d (Display name) o %m (Alias Exchange dell’utente AD), così da avere due policy distinte per gruppi ed utenti.

Exchange Server in edizione Standard ha il problema di non poter scaricare mail da server POP3 per poi recapitarle alle caselle di posta locali, poiché questa versione non ha un connettore POP3, presente invece nella versione Small Business di Exchange. Per ovviare a questo problema, esistono diversi connettori POP3 per Exchange, ma, per quel che ho visto io, sono tutti a pagamento. Se non si vogliono spendere altri soldi per acquistare un connettore POP3 (per quanto diversi connettori non hanno certo importi proibitivi) e si ha un’altro PC a disposizione, è possibile installare hMailServer, un mail server open source per Windows dall’interfaccia semplice e funzionale, e che permette di scaricare la posta elettronica da un server POP3 e di inoltrarla all’indirizzo desiderato sul server Exchange. Detto così è semplice, e in effetti non è una soluzione molto complicata da utilizzare, ma bisogna prestare un po’ di attenzione a ciò che si fa.

Dando per scontato di avere Exchange Standard 2003 funzionante e correttamente configurato, dovremo installare hMailServer sull’altra macchina Windows (meglio un Windows Server, ovviamente se dobbiamo installare una macchina "solo" per quello scopo, conviene acquistare un connettore POP3), la cui installazione non è complicata ed è spiegata piuttosto bene nella documentazione presente sul sito di hMailServer. Tenere presente che hMailServer ha bisogno di un database di appoggio, che può essere MySQL o SQL Server (la stessa installazione di hMailServer può installare una propria versione minimale di MySQL, personalmente preferisco installarmi autonomamente MySQL).

Dopo aver installato hMailServer, va creato il dominio della posta; è consigliabile scegliere un nome di dominio differente sia dal dominio "ufficiale" di posta elettronica sia dal dominio Active Directory, e quindi, sotto il cappello di questo dominio, vanno create le caselle di posta elettronica, una per ogni casella accessibile sul server POP3 da cui dobbiamo scaricare la posta.

Per ogni casella di posta creata in hMailServer, dovremo andare nella scheda "Account esterni", cliccare sul pulsante "Aggiungi" ed inserire le informazioni relative a server POP3, nome utente e password - parametri che vengono forniti dal fornitore del servizio - inoltre, bisogna indicare ogni quanti minuti si scaricheranno i messaggi dal server e se si vogliono cancellare o meno i messaggi sul server POP3; inserite queste impostazioni, bisogna indicare a quale indirizzo vanno inoltrati tutti i messaggi ricevuti sulla casella di posta definita su hMailServer andando sulla scheda "Inoltro", in cui bisogna indicare l’indirizzo al quale inviare i messaggi. Qui bisogna prestare particolare attenzione alla situazione un po’ particolare: su Exchange sono definite le caselle con indirizzo di posta primario quello "ufficiale" corrispondente al dominio aziendale - ad esempio azienda.it - quindi, la policy predefinita per gli indirizzi di posta sarà "@azienda.it"; in tal caso, se su hMailServer inoltriamo le mail verso gli indirizzi di posta "@azienda.it", queste verranno di nuovo ricevute sul server di posta del nostro fornitore di servizio, ed hMailServer le riscaricherà, creando un circolo vizioso che porterà in un tempo più o meno breve alla saturazione del servizio. A questo punto abbiamo due soluzioni:

1. creare per ogni utente di Active Directory un indirizzo di posta secondario (e non predefinito) che termina con il dominio definito in AD stessa (ad esempio, @azienda.lan) ed inoltrare le mail verso quest’indirizzo;
2. creare una zona azienda.it sul DNS del domain controller e definire come record MX del dominio il server Exchange.

Se seguiamo la soluzione numero 1), dovremo definire nella scheda "Inoltro" di ogni casella di hMailServer l’indirizzo di posta corrispondente all’utente e che termina con "@azienda.lan", se invece seguiamo la soluzione numero 2), utilizzeremo come indirizzo di inoltro gli indirizzi di posta "ufficiali" (@azienda.it), avendo cura di impostare come server DNS del server hMailServer l’indirizzo IP del domain controller, cosa che si deve fare in ogni caso. Personalmente preferisco la soluzione numero 1), poiché in questo modo si evita di far confusione con gli indirizzi, identici in tutte le situazioni, mentre utilizzando indirizzi "@azienda.lan", la parte amministrativa è più impegnativa ma le due situazioni sono ben distinte, senza contare che così facendo non si va ad impiastricciare il DNS di Active Directory, particolare non trascurabile. L’utilizzo di hMailServer come connettore POP3 presenta un vantaggio da prendere in considerazione, cioé il fatto che è possibile mantenere il messaggio nella cartella di hMailServer, in questo modo si ha una copia di tutti i messaggi ricevuti, cosa utile in caso di disastri con il server Exchange, anche se ovviamente la cosa migliore è avere una buona strategia di backup.

Intelligent Message Filter (IMF) di Exchange Server 2003 archivia i messaggi di posta elettronica bloccati a livello di gateway in una cartella ben definita (qui maggiori dettagli). IMF però ha un difetto, cioè quello di non indicare il valore SCL (Spam Confidence Level) di ogni messaggio di posta; questo è un limite piuttosto antipatico, poiché in caso di falsi positivi bloccati a livello di gateway ed archiviati nell’apposita cartella non sapremo quali contromisure prendere.

Un modo per visualizzare il livello SCL delle singole mail però esiste, e consiste nella creazione di una voce di registro di sistema sul server Exchange, quindi andare in HKLM\Software\Microsoft\Exchange\ContentFilter e creare un nuova voce con valore DWORD e chiamarla ArchiveSCL e quindi impostarne il valore ad 1.

Ora i messaggi archiviati "per errore" da IMF nella cartella UceArchive avranno una nuova intestazione chiamata X-SCL, ed in cui a fianco compare il valore da 1 a 9 di SCL ed il corrispondente valore in percentuale. L’intestazione X-SCL è visibile semplicemente aprendo il file .eml con il blocco note.