[WORKLOG] - Installazione e configurazione di un server di posta SOHO.

[frakka]

Finalmente mi ci sono messo dietro, a poco più di un anno dalla prima istallazione del mio serverino domestico sono riuscito a dedicare un pò di tempo alla configurazione del mail server.
Ci ho lavorato solo oggi, sfruttando gli ultimi giorni di ferie ma il risultato per ora è soddisfacente: Il tuning richiederà ancora diverso tempo ma l'installazione di base sembra correttamente funzionante.

Perchè installarsi un server di posta in casa?
Da qualche anno a questa parte, con il progressivo diffondersi dell'e-mail nel vissuto quotidiano, quasi tutti i provider hanno deciso di modificare le condizioni di accesso alle caselle email fornite gratuitamente, permettendo l'accesso a mezzo client ai propri server di posta solo agli utenti che utilizzano una connessione internet appartenente alla stessa rete del provider, lasciando a tutti gli altri solo una webmail sempre più invasa di spot pubblicitari.
Abbastanza comprensibile, dato che forniscono il servizio gratuitamente, ma per quanto mi riguarda qualcuno se ne è approfittato anche troppo: La webmail fornita dal mio provider è diventata praticamente illeggibile, sono sempre lì a schivare finestre con offerte di centri commerciali e casinò on-line... Ora che ne ho la possibilità, ho finalmente deciso di registrarmi un dominio e mettere in piedi il mio serverino di posta personale, con la mia webmail ed accesso POP/SMTP/IMAP sempre utilizzabile da ovunque decida di connettermi.
Stò valutando anche l'installazione di una soluzione di groupware (SoGO) ma non ne sono ancora certo...

L'installazione di mailserver basato su GNU/Linux per inviare e ricevere email non è nulla di troppo complesso. Molto più complessa è però la manutenzione e la gestione ordinaria del server, per fare in modo che queste email possano sempre arrivare a destinazione senza venire bloccate dagli n-mila controlli antispam, perchè il nostro server non si trasformi in uno strumento per la proliferazione dello spam (open-relay) e perchè sia in qualche modo in grado di combattere/contrastare il flusso di spam che gli verrà riversato contro. Inoltre, non appena si pubblica una macchina su internet l'esame dei log registra continui tentativi di accesso/intrusione.
Il controllo ed il contrasto di tali attacchi fanno parte della ordinaria attività di manutenzione di un server ma richiedono tempo e molta voglia, pena la rapida capitolazione del nostro server. Ultimo aspetto, ma non per importanza, se decidiamo di portarci in casa il server di posta dobbiamo anche preoccuparci di gestirne i backup: Le avarie capitano, il raid non è backup, piangere dopo non serve.

Per quanto sopra esposto, l'installazione di un proprio mailserver può essere interessante a scopo didattico ma la manutenzione che richiede un server di posta ben gestito è molto impegnativa. Io lavoro nell'IT ed ho in gestione un server di posta molto simile a quello che mi sono installato in casa quindi ne approfitto per un "doppio allenamento" e per fare "formazione" extra-lavorativa ma sconsiglio a chiunque pensi di poterlo fare a tempo perso, di cimentarsi nell'impresa.

1. Introduzione e requisiti.
2. iRedMail.
3. Installazione: Introduzione.
   
   • 3.1_ Preparazione del server.
   • 3.2_ Procedura di installazione.
   • 3.3_ Post-Installazione.
   • 3.4_ Post-installazione. Configurazione del DNS pubblico.
   • 3.5_ Post-installazione. Record SPF e Record DKIM.
   • 3.6_ Aggiornamento di iRedMail.
4. Aggiornamento di Roundcube (webmail).
5. Personalizzazione della configurazione di apache.
   • 5.1_ Restrizione dell'accesso ai siti di amministrazione..
   • 5.2_ Spostare i portali di amministrazione su un sito non raggiungibile dall'esterno.
   • 5.3_ Sostituzione del certificato SSL predefinito.
6. Filtri antispam.
   • 6.1_ Filtri antispam: Abilitare il controllo SPF sulla posta in arrivo.
     6.2_ Filtri antispam: Greylisting.
7. Gestione quotidiana.
   • 7.1_ Creazione di una lista di distribuzione.
   • 7.2_ Aggiunta di un utente "interno" alla lista di distribuzione.
   • 7.3_ Aggiunta di un utente "esterno" al dominio alla lista di distribuzione.
8. Protezione passiva del server. Fail2ban.
   • 8.1_ Fail2ban: fail2ban.conf
   • 8.2_ Fail2ban: jail.conf
   • 8.3_ Fail2ban: jail.local
   • 8.4_ filter.d/
     • apache-access_log.conf
     • apache-error_log.conf
     
     
     
   
   

[frakka]

Per quanto mi riguarda, ho già un server installato e funzionante quindi devo solo aggiungere il server (o meglio i server) per la gestione della posta, le funzionalità antispam, antivirus ed una webmail.

Come configurazione “di base”, i server di posta elettronica servono gli utenti locali alla macchina in cui sono installati: Perchè l'utente frakka@miodominio.it possa ricevere un messaggio di posta è necessario che l'utente “frakka” esista come utente sul server che gestisce il dominio “miodominio.it": Questa configurazione è però limitante in quanto se la macchina gestisse più domini non potrei separare le mail destinate a “info@miodominio.it” da quelle destinate a “info@tuttaltrodominio.com”.
L'alternativa (che è anche il caso che interessa a me) è svincolare il dominio o i domini e gli utenti destinatari accettati dagli utenti del server, dando quindi al mio server la possibilità di gestire quelli che vengono normalmente chiamati “domini virtuali”.

Inoltre, perchè la mie email possano arrivare correttamente a destinazione è necessario che la configurazione che andrò ad applicare sia conforme a determinati usi, alcuni dei quali dettati dal buonsenso, altri maturati nel tempo e molto utilizzati nella lotta allo spam. I requisiti principali da soddisfare sono i seguenti:

1. La disponibilità di un IP statico: Un IP statico è facilmente tracciabile e isolabile. Chi non ha nulla da temere lo usa tranquillamente, uno spammer che sparge schifezze verrebbe bannato da tutti i server nel giro di poche ore. Inoltre i range di IP che i provider usano da assegnare alle connessioni domestiche sono noti e generalmente dinamici: Un pc infetto da un qualche malware che invia spam molto probabilmente avrà un indirizzo dinamico.
   
2. La disponibilità di un reverse DNS: Questo è un po' più complesso e non sempre si riesce ad avere. Il servizio DNS normalmente viene utilizzato in modalità di risoluzione diretta e cioè partendo da un nome host come può essere Google si interroga il server DNS che gestisce la zona di risoluzione diretta del dominio per ottenere il corrispondente indirizzo IP “173.194.35.179”.
   La risoluzione inversa è invece la richiesta che un client fa al server DNS che gestisce la zona di risoluzione inversa di quale nome host corrisponde ad un determinato indirizzo IP. Questa tecnica è usata dai server di posta per capire se l'indirizzo IP che ha inviato una determinata email è davvero chi dice di essere. Purtroppo questo tipo di associazione non si fa normalmente sul server DNS che gestisce il dominio perchè questo server gestisce appunto solo la zona di risoluzione diretta: La zona di risoluzione inversa è gestita direttamente dal provider che fornisce la connettività in quanto assegnatario del range di IP e quindi la richiesta di attivare questa registrazione deve passare dal provider. Non è nulla di complesso ma non tutti lo fanno. Per riuscire ad averla ho chiesto al mio ISP, che ha girato la richiesta etc... ed alla fine dopo un sollecito ed una decina di giorni di attesa è stata attivata.
   Questa registrazione non è indispensabile ma in assenza di un reverse DNS corretto il nostro IP potrebbe essere trattato come un IP dinamico e le nostra mail incappare in un qualche filtro antispam (“reverse DNS lookup”... esperienza personale!!).
   
3. L'accesso al pannello di controllo del nostro dominio, o almeno, la possibilità di fare aggiungere/modificare il record “MX” inserito nella zona di ricerca diretta del dominio (o dei domini) che si vanno a configurare.
   
4. Una macchina su cui installare i server necessari per la gestione dei servizi di mailing, raggiungibile sulle porte configurate e quindi la possibilità di gestire il firewall della macchina e il NAT sulla rete, se necessario.

Nel quarto punto ho parlato al plurale perchè, effettivamente, i server da attivare e configurare sono più di uno: Lo scambio di traffico email tra server avviene sempre e solo attraverso il protocollo SMTP quindi perchè il nostro server sia in grado di inviare la nostra posta in uscita e ricevere quella in arrivo da internet deve avere un servizio SMTP attivo e configurato.
Le mail così ricevute vengono depositate sul filesystem del server e non sono però direttamente consultabili dal classico client di posta: La consultazione della posta da parte del client avviene solitamente tramite il protocollo POP3 o IMAP nelle sue varie versioni quindi è necessario attivare e configurare anche uno o più server in grado di gestire questi protocolli.
In ultimo, se si vuole rendere disponibile una web-mail è necessario configurare anche un server HTTP/HTTPS per ospitare il sito web da cui consultarla.

Questo è, riassumendo, il flusso logico ed il “progetto” contenete i componenti necessari per la gestione ed installazione di un tipico server di posta:

Inoltre, dato che non viviamo in un mondo perfetto, è bene implementare anche alcuni servizi per la gestione dello spam e lo scan antivirus del traffico email, che devono essere integrati con i server citati in precedenza.
Ovviamente è inoltre necessario creare una base comune perchè tutti questi server possano interagire tra loro, verificare le credenziali utente ed accedere a file condivisi (si pensi ad esempio all'accesso contemporaneo alla stesse mail da parte della webmail o di un client di posta). Detta così, la cosa sembra molto complicata ed effettivamente cimentarsi da zero nell'installazione e configurazione di tutte le parti mostrate nello schema non è per nulla semplice neppure con l'ausilio delle moltissime guide reperibili in rete perchè il modo di realizzare questa interazione è tutt'altro che univoco e i componenti possono cambiare o avere requisiti e prerequisiti diversi sulla base della versione installata. Inoltre nello schema riportato sopra manca anche la “base dati” contenente tutte le informazioni sugli utenti che è un altro aspetto da non sottovalutare.

Personalmente ci abbiamo provato in due quasi a tempo pieno per un paio di giorni, poi abbiamo rinunciato.

[frakka]

Fortunatamente, per la mera installazione del server esistono anche diverse distribuzioni Linux preconfigurate per operare come mailserver per piccole aziende, già fornite di tutto quello che serve: Tutto il lavoro di installazione, configurazione e soprattutto integrazione dei componenti riportati sopra è già stato fatto e collaudato, basta inserire le necessarie informazioni di configurazione ed il nostro server è bello che operativo.

Io però ho già un server installato e perfettamente funzionante che non voglio dismettere quindi ho cercato altro e mi sono imbattuto in iRedMail, un progetto opensource e assolutamente gratuito sviluppato da Zhang Huangbin che attualmente supporta 9 delle maggiori distribuzioni *nix disponibili.
Il prodotto "iRedMail" è uno script che installa e configura in poco più di una minuto (davvero!!) tutto il necessario per installare e rendere operativa la struttura mostrata nello schema precedente, oltre a creare la base dati per la gestione degli utenti (con la possibilità di scegliere se utilizzare come archivio MySQL, Postgre oppure OpenLDAP). Lo script installa anche una comoda interfaccia web per la gestione.
In verità lo script fa anche di più dato che si offre, se vogliamo, di aprire le porte necessarie nel firewall, installata e configura uno strumento per il monitoraggio del server e un sistema di scan dei log con la possibilità di bannare automaticamente gli IP con comportamenti sospetti... Sono anche disponibili diverse guide per l'integrazione con alcune famose suite di groupware o con domini ActiveDirectory. Aggiunta che non guasta mai, l'interfaccia di amministrazione è localizzata anche in italiano.

Il prodotto è in realtà destinato ai piccoli ISP, non proprio all'utenza domestica: Infatti lo stesso sviluppatore mette a disposizione a pagamento anche una versione “Pro” del suo pannello di amministrazione visibile e completamente testabile all'indirizzo Online demo of iRedAdmin-Pro - web-based admin panel for iRedMail che, per una cifra assolutamente ragionevole dato il settore cui si rivolge, permette di gestire in modo completamente grafico diversi strumenti avanzati di throttling e quote utente che obiettivamente in un servino domestico non serviranno mai ma che sono una manna in determinati ambienti. Senza stare a dilungarsi troppo, è un prodottino veramente completo che offre anche diverse possibilità di integrazione con gli ambienti Microsoft AD.
Nell'azienda dove lavoro abbiamo acquistato la versione con backend MySQL per un mailserver che gestisce alcuni nostri domini secondari e posso confermare che ne siamo estremamente soddisfatti.

Lo strumento “Pro” per il mio utilizzo domestico è eccessivo (nonchè purtroppo fuori budget!) e con qualche adattamento che sarebbe comunque necessario la versione free andrà credo molto più che bene.
Nell'ottica di un fare test futuri sull'integrazione del server con una struttura MS Active Directory, ho optato per installare la versione con base dati OpenLDAP.

[frakka]

La mia installazione ha come base di partenza il solito serverino citato in precedenza, si tratta di una Debian 6.x 64bit ed è tra le distribuzione supportate dal progetto iRedMail.
Il progetto è molto ben documentato in tutte le sue parti, sfrutta i principali software disponibili nel mondo opensource e il sito dispone di diverse guide che coprono la maggior parte delle problematiche ci si può trovare ad affrontare, anche per l'integrazione con tool di terze parti.

I principali componenti del server sono:

• Postfix: E' il server SMTP vero e proprio, quello che si occupa del trasferimento dei messaggi.
• Dovecot: E' il server che si occupa di fornire l'accesso ai client tramite i protocolli POP3 ed IMAP, oltre che di fornire il servizio “Managesieve”.
  La funzionalità “Sieve” (RFC 5228) è la possibilità di gestire il filtering delle mail all'interno della mailbox tramite regole definite dall'utente tramite script scritti e compilati in linguaggio “sieve” senza la necessità di dover dare accesso diretto al filesystem del server agli utenti per caricare gli script delle regole. La scrittura delle regole è fattibile direttamente tramite una comoda interfaccia grafica accessibile dalla webmail.
• Apache: Beh... L'onnipresente server web.
• MySQL: E' un motore di database. In questo caso, non viene utilizzato per registrare le informazioni utente (come accade invece nella versione con backend MySQL) ma solo i dati delle applicazioni (quarantena delle mail, policy,...).
• OpenLDAP: E' una directory utente, simile ad ActiveDirectory di Microsoft e serve sostanzialmente per registrare le anagrafiche degli utenti dei domini di posta accettati dal server.
• Amavisd, SpamAssassin, ClamAV: Forniscono le funzionalità di policy management, antivirus e antispam al mailserver.
• Roundcube: E' una webmail scritta principalmente in AJAX. Forse non è la migliore o più sicura disponibile per Linux (così avevo letto tempo addietro) ma è graficamente più attraente di squirrelmail e tutto sommato sembra fare molto bene il suo lavoro. Ha funzionalità espandibili tramite plugin, anche se la loro installazione non è sempre banale.
• Awstats: E' uno strumento di analisi dei log di apache e postfix, restituisce diverse informazioni sullo stato del server e sul traffico che lo interessa.
• Fail2ban: Questo strumento, come vedremo, è davvero una chicca: E' un tool che si occupa di analizzare i log del server per individuare corrispondenze con stringhe definite dall'utente e applicare determinate azioni. Nel caso specifico, possiamo configurarlo per individuare tentativi di exploit e di forcing del server e applicare determinate azioni come mettere in DROP nel firewall del server l'indirizzo IP dell'attaccante... E funziona davvero bene!! Per contro, la sintassi delle regole non è proprio semplicissima, soprattutto per i neofiti e per chi è digiuno di programmazione o se si vogliono scrivere regole un po' complesse.
• Logwatch: Stranamente non è per nulla citato nel sito di iRedMail ma viene installato e configurato anche questo strumento che giornalmente invia all'amministratore del server un report con lo stato del server e diverse altre informazioni molto utili.
• Backup: Le ultime versioni hanno incorporato anche uno script per il backup della configurazione del server... Non li ho mai provati perchè in ufficio usiamo altri strumenti ma in questa installazione mi torneranno molto utili.

Installare e configurare un "server di posta" significa installare e configurare per interagire tra loro tutti i componenti sopra elencati in modo da ottenere il comportamento riportato in questa immagine:

La versione gratuita di iRedMail fà tutte queste cose, restituendo un server di posta completamente funzionate. Ci sono poi da applicare alcuni tweaking e customizzazioni specifiche della particolare installazione ma parte più lunga e noiosa del lavoro se la sbriga tutta lo script.
Davvero mica male...

[frakka]

Non dovendomi curare della procedura di installazione ed integrazione delle varie componenti non ho intenzione di soffermarmi più del minimo necessario per descrivere questa fase: La configurazione ed integrazione di PostFix, Dovecot, OpenLDAP e MySQL è terribilmente lunga, complessa e noiosa: sono davvero contento che se la sia smazzata Zhang...
L'installazione dell'intero server si fa scaricando l'ultima versione del file dal sito, lanciando i 3 comandi elencati nelle relative guide (è disponibile sulla home anche un video!), fornendo le 4 informazioni di configurazione basilari e aspettando che finisca. iRedMail di preoccupa di scaricare dai repository ufficiali della distribuzione i software necessari, le relative dipendenze e fare tutta l'installazione.

Lo script nasce per essere installato su un sistema nuovo e, anche se non ho ancora implementato servizi che potrebbero interferire o venire compromessi dalla procedura di installazione, preferisco magari soffermarmi di più sull'integrazione di iRedMail nell'installazione che ho già realizzato e su eventuali personalizzazioni o modifiche, in particolare relativamente ad alcuni dei componenti del server come Fail2ban.

Come detto, la guida per installare iRedMail su Debian è disponibile sul sito, seguendo le istruzioni per Debian 6.x (Squeeze).

Rispetto alla mia installazione, la prima problematica che si incontra è il nome host: Avendo inizialmente preparato il server per una rete locale, il nome host non è utilizzabile per una macchina esposta su internet in quando l'FQDN utilizza un dominio che termina con “.lan” invece che uno dei domini riconosciuti dai DNS pubblici.

Il mio server è attualmente raggiungibile da internet e funziona perfettamente quindi il problema qual'è?
Che una volta configurato il mailserver, per consegnare una mail in uscita si “presenterà” al server destinatario usando il suo FQDN: terminando in .lan non può avere una risoluzione inversa valida, ricadendo quindi in molti dei filtri antispam citati in precedenza.

La soluzione più semplice sarebbe quella proposta sul sito: modificare il nome host per adottarne uno che sia valido anche su una rete pubblica. Preferisco però non rinominare il mio server, quindi adotto una soluzione diversa che richiederà poi una leggera modifica anche alla configurazione di postfix (il terzo screen è riferito appunto al tuning post-installazione):

In teoria, tutti i repository necessari dovrebbero essere già abilitati nel mio sistema anche se riferiti ad un server Debian in Italia piuttosto che al repository centrale ma l'avvio dell'installazione mi ha restituito un errore relativo alla mancanza del pacchetto "dialog", che si è immediatamente risolto inserendo anche il repository US nella configurazione di apt:

Scaricando dal sito ufficiale il pacchetto di installazione e decomprimendo l'archivio come indicato nella guida è infine possibile lanciare l'installazione:

[frakka]

L'installazione consiste appunto nello scaricare l'installer sul server, decomprimere l'archivio, lanciare l'installer e fornire le informazioni richieste:

La seconda schermata chiede come prima cosa di indicare la directory sul server che dovrà conservare le mail: In base al carico di lavoro del server questa directory potrebbe aumentare considerevolmente di dimensioni e, in installazioni più grandi, è una best-practice tenerla in una directory non montata sullo stesso device della root (per evitare che una eventuale saturazione dello spazio disponibile possa bloccare il server), magari dotata di un filesystem come LVM che ne permetta l'estensione a caldo o la creazione di snapshot per scopi di backup.
Nel mio caso potrei, ad esempio, destinarla nella partizione del disco meccanico che ho montato in “/download” ma non è protetta da RAID, non ho adottato LVM o altri filesystem e semmai dovessi spegnere il server per qualche ora non sarebbe una tragedia quindi per ora va bene lì. In futuro magari si vedrà, al limite sostituisco la SSD con una unità più grande e sposto la partizione...

La fase successiva, è la selezione del back-end che conterrà le informazioni utente perchè molte delle informazioni che l'installer richiederà in seguito saranno specifiche per la configurazione del backend scelto. La versione Free basata su OpenLDAP dispone attualmente di qualche funzionalità in più rispetto alla sua omologa basata su MySQL (che stà comunque recuperando) e può essere modificata facilmente per integrarsi con una struttura ActiveDirectory di Microsoft già esistente, la versione basata MySQL per contro dovrebbe risultare un pochino più leggera in quanto non richiede l'installazione del server OpenLDAP ma le differenze sono davvero minime.
Per questa installazione ho scelto LDAP e la schermata successiva è la richiesta della password del "Manager" (amministratore) della struttura LDAP. MySQL deve comunque essere installato, per gestire praticamente tutto quello che non riguarda le anagrafiche degli utenti (contatti degli utenti, quote e ratio di utilizzo del server, configurabile per dominio e/o per singolo utente, il percorso della directory che ospita la casella di posta dell'utente, etc...): La password di root richiesta qui non è quindi quella dell'utente "root" di sistema ma dell'amministratore "root" di MySQL (l'equivalente dell'utente sa di SQL...)

Questa schermata riguarda la prima configurazione della struttura LDAP: LDAP ospiterà tutti i domini virtuali configurati sul server, le informazioni qui richieste servono solo per configurare una struttura iniziale che sarà usata per configurare i vari servizi in modo che possano interfacciarsi con la struttura delle anagrafiche. L'installer creerà all'interno della struttura qui indicata un account utente diverso dal "Manager" che fornirà a tutti i servizi le credenziali per consultare l'archivio degli utenti.
Non è assolutamente necessario utilizzare per questa configurazione i riferimenti del server o un dominio che andrà effettivamente in funzione, si può usare praticamente anche il valore di esempio...

Viene poi chiesta la configurazione del "primo dominio" ospitato sul server. In questo dominio verrà registrato l'utente "postmaster" utilizzato come super-amministratore del server di posta, come si può vedere dalle schermate successive: Questo è forse l'unico dominio che è meglio/raccomandabile non eliminare mai, non ho idea di quali possano essere le conseguenze. Ho quindi utilizzato quello che sarà il mio dominio più importante (nonchè, probabilmente, l'unico...)
La schermata successiva è la richiesta di password per un utente predefinito denominato "test" che fino alle versioni precedenti era invece "www" ma poco importa, dato che lo eliminerò al termine dell'installazione:

Infine, raccolte tutte le informazioni necessarie, viene mostrato un elenco di tool opzionali ma utili per la gestione del server. Fino alla versione 0.74 era poi necessario impostare la lingua di default da usare per la webmail ma da questa versione (che ha aggiornato anche la versione di RoundCube installata) la lingua da usare per la webmail viene autorilevata dalle impostazioni del browser. La localizzazione, intesa come la gestione ad esempio del formato data, non è però completa e necessita poi di ulteriori interventi (di default, viene proposta come Y-M-D). I singoli utenti hanno comunque la possibilità di impostare la lingua e il formato data/ora dall'interno della propria webmail.
Selezionati i tool, è possibile confermare e avviare l'installazione vera e propria. In una posizione poco felice, a dire il vero, l'installer ci avvisa di rimuovere il file “config” che si trova all'interno della directory di installazione al termine dell'installazione: Questo file contiene tutte le informazioni fornite comprese le password degli utenti del server di posta e degli utenti di sistema quindi lasciarlo in giro dopo che ha esaurito la sua funzione è inutile e pericoloso. A mio parere questo warning rischia di passare inosservato o essere dimenticato quindi sarebbe stato meglio proporlo in fondo alla procedura di installazione.
L'installer propone anche la rimozione di eventuali applicazioni potenzialmente incompatibili, come ad esempio "sendmail" che usavo per gestire l'invio delle notifiche del server. Non è necessario riconfigurare nulla, il server sarà comunque in grado di inviare le eventuali notifiche usando "postfix", senza richiedere ulteriori interventi.

L'attivazione di questi servizi richiede una configurazione del firewall che ne permetta il funzionamento e l'installer fornisce un set di regole già pronte ma io ho già un mio script di gestione del firewall quindi rifiuto e passo oltre. Le porte da aprire sono comunque queste (TCP), con i relativi servizi:
http 80
https 443
smtp 25
smtps 465 e 587
pop3 110
pop3s 995
imap 143
imaps 993

In 10 minuti (compreso il tempo di fare gli screenshoot, il download dei pacchetti necessari, rimuovere i conflitti e configurare il tutto) il server di posta è installato e pronto.
Durante l'installazione vengono creati 3 account di sistema (vmail, iredapd ed iredadmin) ed installati e configurati con un settaggio predefinito i server e tool che comporranno il server di posta (OpenLDAP server, MySQL database server, Postfix, Policyd, Dovecot, ClamAV, Amavisd-new, SpamAssassin, Roundcube, phpLDAPadmin, phpMyAdmin, Awstats e Fail2ban oltre i tools specifici sviluppati da dall'autore iRedAdmin ed iRedAPD).

[frakka]

Come si può vedere dall'ultimo screen-shot con il riepilogo, lo script ha usato per la configurazione dei siti web su cui sono ospitate le applicazioni un FQDN non corretto, dato che non ho voluto modificare il nome host della macchina. Questo si riflette anche nella configurazione di postfix e richiedere alcune configurazioni post-installazione, per rimediare al problema.

Nello specifico, la prima cosa da correggere è la configurazione di postfix.
Il problema si rimedia correggendo alcune opzioni in uno dei file di configurazione principali, il file /etc/postfix/main.cf, e riavviando postfix:

myhostname = server.fracassetti.lan
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
myorigin = server.fracassetti.lan
mydestination = $myhostname, localhost, localhost.localdomain, localhost.$myhostname

myhostname = posta.fracassetti.it
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
myorigin = posta.fracassetti.it
mydestination = $myhostname, server.fracassetti.lan, localhost.fracassetti.lan, localhost, localhost.localdomain, localhost.$myhostname

Inizialmente ho inserito in "mydestination" anche il dominio "fracassetti.it" che è il "primo dominio" configurato nel server. La configurazione sembra comunque correttamente funzionante ma Postfix non era del tutto d'accordo:

postfix/trivial-rewrite[22125]: warning: do not list domain fracassetti.it in BOTH mydestination and virtual_mailbox_domains

quindi ho rimosso il dominio dall'elenco in "mydestination" ed il warning è scomparso.

root@server:~# /etc/init.d/postfix restart
Stopping Postfix Mail Transport Agent: postfix.
Starting Postfix Mail Transport Agent: postfix.
root@server:~# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 posta.fracassetti.it ESMTP Postfix (Debian/GNU)

Ci sarà poi da lavorare su apache per correggere la configurazione dei siti web ma a quella ci guardo in un secondo momento.

Rispetto alla configurazione predefinita, ho anche attivato un ulteriore tabella di alias, per la gestione degli alias relativi agli indirizzi email. La versione a pagamento mette a disposizione una comoda interfaccia per la gestione degli alias dei singoli utenti o di interi domini (ad esempio, per quegli utenti che hanno sia un indirizzo email relativo al dominio.it e al dominio.com) mentre la versione free ne è totalmente priva. Si potrebbe agire su LDAP ma trovo più comodo nella mia configurazione utilizzare il database degli alias di postfix.
Per configurazione predefinita, postfix legge gli alias dal file "/etc/postfix/aliases" che ha però il limite di poter gestire solo account locali e non virtuali. Prendendo spunto da qui e applicando quanto indicato qui ho attivato anche una "alias table" per gli account virtuali. In sostanza, creando un semplice file di testo contenete delle righe nel formato "user@domain address, address, ..." oppure "user address, address, ..." o ancora "@domain address, address, ..." è possibile istruire postfix per gestire anche gli alias relativi a domini virtuali.

user@domain address, address, ... => Reindirizza le mail destinate all'utente "user@domain" agli indirizzi indicati come "address". Questo formato ha la priorità più alta sulle eventuali regole che dovessero seguire nel file.
Ad esempio, la forma:
frakka@dominio.it pluto@libero.it, pippo@alice.it
reindirizza le mail destinate a "frakka@dominio.it" che arrivano al server verso gli indirizzi email "pluto@libero.it" e "pippo@alice.it" (utile anche per creare delle liste di distribuzione).

user address, address, ... => Reindirizza le mail destinate agli utenti "user" per cui il dominio è indicato come "$myorigin" oppure contenuto nelle opzioni "$mydestination", "$inet_interfaces" o "$proxy_interfaces" riportate nella configurazione di postfix vista sopra, agli indirizzi indicati come "address". Sostanzialmente, sostituisce la funzionalità di quanto riportato nel file "/etc/postfix/aliases" con il vantaggio di poter utilizzare però anche indirizzi "user" non necessariamente locali al server.

@domain address, address, ... => Reindirizza le mail ricevute per il dominio "@domain" agli indirizzi indicati come "address". Le regole in questo formato hanno la precedenza più bassa ma sono anche le più pericolose da usare: "@domain" è una wildcard e istruisce postfix per inoltrare tutte le mail relative al dominio "@domain" indipendentemente dall'esistenza o meno dello specifico destinatario, col risultato che tenterà di inviare mail a destinatari non esistenti e di inviare un report di "undeliverable" a indirizzi di mittenti che sono spessi fasulli, sovraccaricando inutilmente il server col rischio di finire in qualche blacklist.

Ho creato il file /etc/postfix/virtual_aliases con il seguente contenuto:

abuse altramail@libero.it
postmaster altramail@libero.it
webmaster altramail@libero.it
hostmaster altramail@libero.it

Che quindi istruisce postfix a reindirizzare tutte le mail destinate agli utenti "abuse", "postmaster", "webmaster" e "hostmaster" per i domini contenuti nelle opzioni "$myorigin", "$mydestination", "$inet_interfaces" o "$proxy_interfaces" (posta.fracassetti.it, server.fracassetti.lan, localhost.fracassetti.lan, localhost, localhost.localdomain, localhost.posta.fracassetti.it.) all'indirizzo email "altramail@libero.it".
In questo stesso file, è possibile gestire anche gli alias per gli utenti di posta registrati nei domini virtuali. Aggiungendo in calce le seguenti righe:

# Alias relativi al dominio fracassetti.it
#
postmaster@primodominio.it altramail@libero.it
info@primodominio.it matteo@primodominio.it

E' possibile ottenere il reindirizzamento desiderato.


Questo per risolvere le incongruenze derivanti dal diverso hostname della macchina. Inoltre iRedMail usa l'utente "postmaster@" come utente non abilitato alla posta per accedere al pannello di configurazione, rendendo problematica la ricezione della posta per questo account: Questi indirizzi sono destinazioni particolari, in pratica account "standard" previsti da alcune RFC per ogni dominio (l'utente "postmaster" è richiesto dal registro italiano per tutti i domini ".it" registrati) ma, appunto, essendo account standard tendono a riempirsi di spam e preferisco saturare la mailbox di libero che il mio serverino.
Su molti server non sono neppure più manutenuti, in barba agli standard...

Postfix non è però in grado di utilizzare direttamente il file così creato: Lanciare il comando:

 postmap /etc/postfix/virtual_aliases

genera il file "/etc/postfix/virtual_aliases.db" che può essere invece letto. E' poi necessario configurare postfix per leggere le informazione contenute, modificando l'opzione:

virtual_alias_maps = proxy:ldap:/etc/postfix/ldap/virtual_alias_maps.cf, proxy:ldap:/etc/postfix/ldap/virtual_group_maps.cf, proxy:ldap:/etc/postfix/ldap/virtual_group_members_maps.cf, proxy:ldap:/etc/postfix/ldap/catchall_maps.cf

in:

virtual_alias_maps = hash:/etc/postfix/virtual_aliases, proxy:ldap:/etc/postfix/ldap/virtual_alias_maps.cf, proxy:ldap:/etc/postfix/ldap/virtual_group_maps.cf, proxy:ldap:/etc/postfix/ldap/catchall_maps.cf

In realtà il post prevedeva la modifica dell'opzione in:

virtual_alias_maps = hash:/etc/postfix/virtual_aliases

Ma ho provato a lasciare anche gli altri mapping e non sembrano creare particolari problemi.

Riavviare postfix per applicare le modifiche.


[EDIT del 05∕02∕2013]
In seguito ad una piccola revisione, ho modificato anche queste due istruzioni (le reti indicate sono le mie reti locali) nel "/etc/postfix/main.cf":

#mynetworks = 127.0.0.0/8
mynetworks = 127.0.0.0/8 192.168.200.0/24 192.168.150.0/24
#smtpd_enforce_tls = no
smtpd_enforce_tls = yes

Inoltre, se si volesse abilitare anche il funzionamento della porta 587 per la ricezione della posta in arrivo sarebbe necessario decommentare la seguente riga all'inizio del file
"/etc/postfix/master.cf":

submission inet n - - - - smtpd

e riavviare Postfix, oltre che ovviamente aprire la porta nel firewall.

[frakka]

Perchè il server possa ricevere posta, è necessario che gli sia recapitata.
Perchè un server esterno possa conoscere l'indirizzo IP del server di posta in arrivo di uno specifico dominio, è necessario che il nome host della macchina sia configurato nella zona DNS relativa al dominio come record di tipo "MX" (Mail Exchanger). Tale nome host deve poi essere riconducibile ad un record "A", non necessariamente appartenete a quella zona.
Es:

[matteo@arch-UEFI Desktop]$ dig @208.67.222.222 mx alice.it +short
15 smtp.aliceposta.it.

"alice.it" ed "aliceposta.it" sono, appunto, due zone DNS diverse ed è il server "smtp.aliceposta.it" che fornisce il servizio posta in arrivo per "alice.it"

Questa configurazione si fà nella gestione del DNS che ci mette a disposizione il registrant presso cui abbiamo registrato il dominio. Nel mio caso, la situazione è la seguente:

[matteo@arch-UEFI Desktop]$ dig @208.67.222.222 mx fracassetti.it +short
10 posta.fracassetti.it.

Al record "MX" è sempre associato un valore di priorità, generalmente pari o multiplo di 10, per dare un ordine di preferenza nel caso siano presenti due o più server di posta.

Al record "MX" deve poi essere assegnato il corrispondente record "A":

[matteo@arch-UEFI Desktop]$ dig @208.67.222.222 a posta.fracassetti.it +short
77.89.33.26

Questi sono i record DNS minimi indispensabili.
E' poi buon costume nonchè, di fatto, necessario che il record MX sia anche dotato di una risoluzione inversa correttamente funzionante (record PTR). In caso contrario, molti programmi antispam associano la mancanza di una risoluzione inversa corretta ad un IP dinamico, marcando i messaggi in arrivo come SPAM o rigettandoli direttamente. Come accennato in precedenza, questa è una configurazione che però può fare solo l'ISP in quanto è necessario agire sulla zona di ricerca inversa.

[matteo@arch-UEFI Desktop]$ dig @ns3.acantho.net -x 77.89.33.26 +short
posta.fracassetti.it.

La parte finale della guida all'installazione, cita poi altri due tipologie di record DNS, il record "SPF" ed il record "DKIM".

[frakka]

Per una spiegazione completa di cosa sono questi record, si rimanda al sito di riferimento per SPF e DKIM.
Velocemente, si tratta di cui record di tipo "TXT" registrati nella zona DNS di riferimento per il dominio che contengono informazioni sui server che sono autorizzati ad inviare posta per il dominio.

Nel caso di SPF, fornisce l'elenco dei server autorizzati ad inviare posta (che possono essere diversi dal record MX che è invece il server deputato a riceverla): Quando un server con il filtro SPF abilitato riceve un messaggio, come prima cosa verifica quindi sul DNS del mittente se il server da cui il messaggio è arrivato è listato nel record SPF, in caso contrario lo considera SPAM.
La sintassi del record non è sempre immediata ma con un pochino di pratica e l'aiuto dei test che si trovano su alcuni siti (SPF Query Tool oppure Mail Server Diagnostics - Accessplus) si può riuscire con facilità a ottenere un record corretto.
I record:

v=spf1 a:posta.fracassetti.it ptr:posta.fracassetti.it -all

e

v=spf1 ip4:77.89.33.26/32 a:posta.fracassetti.it ptr:posta.fracassetti.it -all

sono entrambi record SPF validi per il mio dominio e specificano che solo il server "posta.fracassetti.it" (identificato in vari modi) è autorizzato ad inviare mail per il dominio in cui si trova il record ("fracassetti.it") ottenuto. Se il mio server ospitasse altri domini, il record SPF da inserire nella zona DNS di tali domini sarebbe lo stesso.

[matteo@arch-UEFI Desktop]$ dig @208.67.222.222 txt fracassetti.it +short
"v=spf1 ip4:77.89.33.26/32 a:posta.fracassetti.it ptr:posta.fracassetti.it -all"

DKIM, invece, è un record che contiene una della chiavi della firma elettronica con cui il server di posta in uscita firma ogni messaggio in transito. In questo modo, verificando la corrispondenza delle firme, il server che riceve un messaggio firmato tramite DKIM può avere o meno la conferma che il messaggio è stato originato proprio da un server che detiene la chiave privata della firma riportata nel record.
Il record DKIM è quindi un pò più complesso da generare, generalmente vengono usati dei tool appositi. iRedMail, in fase di installazione, si preoccupa già di generare la chiave necessaria anche se nel riepilogo generato dalla versione 0.81 non si vede (probabile bug).

Per ottenere il record DKIM da inserire nel nostro DNS, possiamo utilizzare il comando:

root@server:~# amavisd-new showkeys
; key#1, domain fracassetti.it, /var/lib/dkim/fracassetti.it.pem
dkim._domainkey.fracassetti.it. 3600 TXT (
  "v=DKIM1; p="
  "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQOZAqGHp2yRr4U3L0OPYpytja"
  "RkmFsOPH4f0RO1u67eEM3EPULqeAg/tfcm5Z/J98hGGCjKM0bCdKWzHj3nn/Bsom"
  "UICirWdOsDcdEm8bxDthNsK3G2vPXjWXyMO3L7di5pGhMd388eWzBBn6CJ7FHaRw"
  "EdhD+ssYRB6Td+2i4wIDAQAB")

che può essere incollato nel nostro file di zona del DNS se gestito da bind, altrimenti si può creare un record denominato "dkim._domainkey.fracassetti.it." con il seguente contenuto:

v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQOZAqGHp2yRr4U3L0OPYpytjaRkmFsOPH4f0RO1u67eEM3EPULqeAg/tfcm5Z/J98hGGCjKM0bCdKWzHj3nn/BsomUICirWdOsDcdEm8bxDthNsK3G2vPXjWXyMO3L7di5pGhMd388eWzBBn6CJ7FHaRwEdhD+ssYRB6Td+2i4wIDAQAB

Una volta inserito il record, può essere verificato con il comando:

root@server:~# amavisd-new testkeys
TESTING#1: dkim._domainkey.fracassetti.it    => pass

Purtroppo non tutti i gestori lo supportano. Nel mio caso, Aruba prevede l'inserimento solo di record SPF: Sono riuscito anche ad inserire un record presunto DKIM ma non sono per nulla sicuro che funzioni davvero, avevo letti di diversi problemi con questo gestore.

[EDIT:]
Ho verificato il record creando una copia della zona con il mio bind e inserendo il record. Il test viene superato, segno che la chiave e la firma sono corrette. Peccato che verificando le forme usando una servizio esterno, come quello di port25.com ottengo questo risultato:

DKIM check:         permerror

[...]
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         permerror (no usable key records)
ID(s) verified: 
Canonicalized Headers:
    user-agent:RoundCube'20'WebMail'0D''0A'
    message-id:<4d01b34eeb48803b15b88c520709cc94@fracassetti.it>'0D''0A'
    subject:test'20'spf'0D''0A'
    to:'0D''0A'
    from:miamail@fracassetti.it'0D''0A'
    date:Sat,'20'25'20'Aug'20'2012'20'18:13:52'20'+0200'0D''0A'
    mime-version:1.0'0D''0A'
    dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=fracassetti.it;'20'h=user-agent:message-id:subject:subject:to:from:from:date:date'20':mime-version;'20's=dkim;'20't=1345911232;'20'x=1346775232;'20'bh=frcCV1k9oG'20'9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;'20'b=

Canonicalized Body:
    '0D''0A'
    

DNS record(s):
    dkim._domainkey.fracassetti.it. TXT (no records)

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

Quindi è probabile che il problema sia proprio il record sul DNS di Aruba...

[frakka]

Roundcube è la webmail fornita ed installata con iRedMail.
Non è famosa per essere la più sicura al mondo ma ha una bella interfaccia ed è piuttosto completa in termini di funzionalità. La versione installata con l'ultima versione di iRedMail è la 0.72 mentre l'ultima versione disponibile sul sito è la 0.81.

Con la versione 0.8 c'è stato un aggiornamento del tema predefinito, che risulta decisamente più gradevole del precedente oltre alla correzione di diverse vulnerabilità quindi mi sono deciso a tentare l'aggiornamento. Il pacchetto viene fornito con le istruzioni ed un tool per l'aggiornamento, procedura che è coperta anche dal wiki di iRedMail. Unendo le due cose, sono riuscito ad effettuare l'aggiornamento senza particolari problemi.

Come prima cosa, ho fatto il backup del database di roundcube con il comando:

# mysqldump -u root -p roundcubemail > /root/mysql-db-roundcubemail.sql

Poi, unendo le istruzioni dei due wiki, ho scaricato l'ultima versione di roundcube (0.8.1) e l'ho decompressa in una directory temporanea (/root/roundcube) invece che nel percorso di destinazione con il comando:

 # tar xzf /root/roundcubemail-0.8.1.tar.gz

Infatti lo script per l'aggiornamento di roundcube deve essere lanciato da un percorso diverso dalla destinazione finale, in quanto effettua l'aggiornamento "in place" dell'installazione che trova. Ho quindi copiato il contenuto della directory "/usr/share/apache2/roundcubemail-0.7.2" in "/usr/share/apache2/roundcubemail-0.8.1" con il comando:

 mkdir /usr/share/apache2/roundcubemail-0.8.1
 cp -ar /usr/share/apache2/roundcubemail-0.7.2/* /usr/share/apache2/roundcubemail-0.8.1

Poi ho lanciato l'aggiornamento seguendo le istruzioni contenute nel file "UPGRADING" all'interno della directory in cui ho decompresso l'archivio, indicando come "" la copia della vecchia installazione nel nuovo percorso:

cd roundcubemail-0.8.1
./bin/installto.sh /usr/share/apache2/roundcubemail-0.8.1

L'installer ha provveduto ad aggiornare l'installazione che ha trovato, rilevando correttamente le versione di partenza (0.7.2), richiedendo solo l'aggiunta al file di configurazione di un parametro che nelle precedenti non era evidentemente indicato (support_url).
Ho poi provveduto ad eseguire i passaggi finali indicati nella guida di iredmail, rimuovendo il link simbolico alla directory "roundcubemail" e ripuntandolo verso il nuovo percorso:

chown www-data:www-data /usr/share/apache2/roundcubemail-0.8.1/{temp,logs}
rm roundcubemail
ln -s /usr/share/apache2/roundcubemail-0.8.1 roundcubemail
chmod 0000 /usr/share/apache2/roundcubemail-0.8.1/{CHANGELOG,INSTALL,LICENSE,README,UPGRADING,installer,SQL}

Riavviato apache, tutto ok.

/etc/init.d/apache2 restart

[EDIT del 13 Settembre 2012]:

Il log di apache si riempie di segnalazioni di questo tipo:

[Wed Sep 12 22:27:52 2012] [error] [client 79.23.140.62] PHP Notice: Undefined offset: 1 in /usr/share/apache2/roundcubemail-0.8.1/skins/larry/svggradient.php on line 26, referer: https://posta.fracassetti.it/?_task=...Sent&_framed=1
[Wed Sep 12 22:27:54 2012] [error] [client 79.23.140.62] PHP Notice: Undefined offset: 1 in /usr/share/apache2/roundcubemail-0.8.1/skins/larry/svggradient.php on line 26, referer: https://posta.fracassetti.it/?_task=...art=2&_frame=1

Sono warning, non errori e a quanto pare sono originati in seguito a connessioni alla webmail con IE9 (e forse successivi). Non c'è una vera e propria soluzione credo e non è neppure un vero e proprio problema. Semplicemente per evitare che mi riempia però i log, ho trovato questo workaround sul forum di Roundcube e sembra funzionare senza problemi evidenti.