[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]

Non stò a parlare della configurazione dei singoli utenti di ciascun dominio: La versione free di iredadmin è relativamente limitata in quanto ad opzioni e funzionalità raggiungibili dall'interfaccia e la creazione di un nuovo utente è estremamente semplice.
Le versioni free di iredadmin, contrariamente alle controparti a pagamento, non dispone però di un'interfaccia per la configurazione di liste di distribuzione: E' comunque possibile procedere manualmente, seguendo le procedure documentate sul wiki di iredmail.
La procedura cambia in base allo specifico backend che si è scelto di utilizzare e non è comodissima. Però per un singolo dominio è comunque accettabile mentre, se i domini e gli indirizzi da gestire aumentano, è una di quelle funzionalità che giustificano il passaggio alla versione a pagamento.

Io ho installato la versione con backend LDAP e la documentazione ufficiale per questa procedura è reperibile qui.

La creazione di una lista di distribuzione si divide in due parti: consiste nella creazione di un oggetto nella struttura LDAP del dominio interessato e nella successiva aggiunta di ogni membro a questa lista. In assenza di iRedAdmin Pro, lo sviluppatore ha previsto l'installazione durante il setup di un noto tool per la gestione di queste strutture di dati da un'interfaccia web. Il tool si chiama phpLDAPAdmin, è un progetto opensource e, salvo modifiche post-installazione, è raggiungibile agli url "https://ip_del_server/phpldapadmin/" o "https://ip_del_server/ldap/" e per ottenere l'accesso amministrativo è necessario utilizzare la password del manager LDAP fornita in fase di installazione.
Un riepilogo di queste informazioni è comunque disponibile nel file "iRedMail.tips" generato dal tool di installazione di iRedMail.

L'interfaccia del tool mostra, sulla sinistra, il tree che costituisce la radice della directory, avente come root il domain indicato in fase di installazione per la struttura LDAP. All'interno del tree si trovano diversi oggetti tra cui l'oggetto "o=domains" che contiene tutti i domini virtuali che il server gestisce mentre sulla destra si trovano il dettaglio degli oggetti selezionati e i campi modificabili.

Come prima cosa, all'interno del tree "o=domains" individuare il dominio all'interno del quale si vuole creare la lista di distribuzione e selezionare il tree "o=Groups". Sulla destra, selezionare poi "Create a child entry" creare un nuovo oggetto all'interno di questo tree.
La guida sul sito ufficiale propone poi di selezionare il template "default" e successivamente "mailList" nel menù "ObjectClasses": Il template non l'ho trovato, mi risulta già selezionato come si può vedere dalle indicazioni riportate nel top del questo frame, probabilmente la guida si riferisce ad una versione più vecchia. Nella seconda ed ultima fase di questa procedura c'è da selezionare "mail" nel menù a tendina e compilare i sottostanti campi necessari.

Le informazioni di inserire, opportunamente ripartite nei relativi campi, sono: l'indirizzo email della lista di distribuzione ("Email"), i permessi di accesso a questa lista (una policy che definisce chi è autorizzato a scrivere alla lista di distribuzione), lo stato della lista (attivata/disattivata, "accountStatus"), un nome semplice per la visualizzazione ("cn" o Common Name) con un testo descrittivo (Description) ed i servizi per cui questo oggetto è autorizzato.

Le accessPolicy sono predefinite disponibili sono "public", "domain", "subdomain", "membersOnly", "moderatorsOnly", "memebersAndModeratorsOnly": sono gestite e documentate con un tool apposito, sempre facente parte di iRedMail. L'uso di queste policy è molto utile per ridurre la solita valanga di spam in ingresso, restringendo l'accesso solo agli utenti che ne hanno effettivo bisogno.
Un altro attributo su cui è necessaria una specifica sono gli "enabledService": La guida riporta per questo attributo 3 valori da inserire ma mi risulta che il tool permetta in realtà l'inserimento di un solo valore alla volta... Conviene quindi inserirne solo uno, aggiungendo i successivi solo in un secondo momento. La procedura mostrata nello screenshoot non mi risulta funzionante.
Inserite le informazioni si può cliccare sul pulsante "Create Object" e, verificata la correttezza, procedere con la creazione dell'oggetto. Una volta creato, può essere modificato per aggiungere i valori mancanti all'attributo "enabledService":

[frakka]

La lista appena creata esiste ora come oggetto LDAP ma non è popolata: In assenza di membri assegnati, postfix tratterà la lista come un utente inesistente, restituendo nei log del server di posta il seguente errore:

Recipient address rejected: User unknown in virtual mailbox table;

L'appartenenza alla lista è gestita come attributo del singolo utente: Non è quindi possibile modificare aggiungere in un colpo solo tutti gli utenti (a meno, ad esempio, di modificare il template per i nuovi utenti, per rendere questo attributo parte degli attributi predefiniti del nuovo utente) ed è necessario agire aggiungendo un utente alla volta.

Espandendo il tree "ou=Users", sempre sotto il tree del dominio in cui stiamo creando la lista, è possibile individuare l'account che si vuole aggiungere e selezionarlo:

Se è la prima volta che l'utente viene aggiunto ad una lista, l'attributo "memberOfGroup" non sarà disponibile e dovrà essere aggiunto tramite la funzione "Add new attribute -> memberOfGroup" e valorizzando il campo compilabile con l'indirizzo email della lista, selezionando "Update Object" per salvare le modifiche. In caso contrario, sarà sufficiente aggiungere un valore all'attributo esistente, similmente a come fatto in precedenza per l'attributo "enabledService". Non ci sono particolare limitazioni al numero di liste a cui può essere aggiunto l'utente.

Dalla rubrica della webmail, se è stato precedentemente attribuito il valore "displayedInGlobalAddressBook" all'attributo "enabledService" della lista di distribuzione, è ora possibile verificare se il nuovo oggetto compare nell'elenco degli indirizzi disponibili nell'elenco indirizzi globale e se il funzionamento è quello atteso:

[frakka]

La procedura precedente permette di gestire solo contatti email registrati all'interno del dominio specifico. Creare una lista che permetta di inoltrare messaggi ad indirizzi non appartenenti al dominio gestito dal server non è problematico ma segue una procedura leggermente diversa: La lista in sè è identica ma è necessario creare un oggetto "contatto email" nell'apposito tree "Externals" ed aggiungervi l'attributo "memberOfGroup", similmente a quanto visto in precedenza.
A queste liste, è possibile applicare gli stessi attirbuti e gli stessi valori visti in precedenza, sia per quanto riguarda le policy di accesso che per gli enabled services.

La procedura che cambia leggermente è la creazione del contatto email, che si fà espandendo il tree "Externals" e selezionando la tipologia "mailExternalUser".

Per aggiungere alla lista un utente interno già esistente, è sufficiente aprirne il profilo e aggiungere un "Value" all'attributo "memberOfGroup" dell'utente.

[Daniele]

Iscrittissimo! Leggero' con interesse come al solito! :-)

Inviato dal mio LG-P990 con Tapatalk 2