Passo 13: Testare IMAP e settare la webmail Roundcube

Testare l’accesso IMAP

Abbiamo già finito la configurazione di Dovecot quindi prelevare le mail usando il protocollo IMAP funziona già. Proviamo usando un semplice ma potente client IMAP: mutt.

mutt -f imaps://john@example.org@webmail.example.org

L’URL della connessione può sembrare un po’ strano per i due caratteri “@”. Di solito mutt si aspetta imaps://utente@server. Siccome usiamo l’indirizzo mail come parte “utente”, otteniamo questo. Dovrebbe esservi richiesta la password che è “summersun”. Se ottenete qualche avviso per il certificato, controllate di aver usato il corretto nome del server per connettervi e che abbiate finito la precedente parte sul certificato/Letsencrypt di questa guida.

Dopo essere loggati vedrete una posta in arrivo vuota:

Molto bene – quindi IMAP funziona.

Abilitare Roundcube

Non tutti sono utenti avanzati che usano applicazioni come Thunderbird, Evolution, kmail o A**le Mail per gestire le mail. Potrebbe sorprendere quanti utenti si accontentano di un’interfaccia web. Ok, allora mettiamone a disposizione una. Uno software molto (se non il più) comune per questo scopo è Roundcube.

Quando abbiamo installato il pacchetto Roundcube all’inizio di questa guida, è stato creato il file /etc/apache2/conf-available/roundcube.conf che ha un link in /etc/apache2/conf-enabled/. Quindi la configurazione generale per Apache è già pronta. Quello che rimane da fare è collegare l’host virtuale della webmail alla cartella che contiene l’installazione di Roundcube.

Il file di configurazione suggerisce questa linea nella configurazione di Apache:

Alias /roundcube /var/lib/roundcube

Questo rende Roundcube accessibile all’indirizzo https://webmail.example.org/roundcube. Tuttavia preferirei omettere quel “/roundcube”. Questo si ottiene facilmente modificando “DocumentRoot” nel file /etc/apache2/sites-enabled/webmail.example.org-https.conf così:

DocumentRoot /var/lib/roundcube

Ricarichiamo la configurazione di Apache…

service apache2 reload

…e adesso è possibile accedere alla webmail da https://webmail.example.org/

Potremmo già accedere inserendo “localhost” come server. Miglioriamo un po’ la configurazione. Il “Server” è sempre “localhost”. Quindi modifichiamo il file /etc/roundcube/config.inc.php e settiamo:

$config['default_host'] = 'localhost';

Ora se ricarichiamo il form del login, il campo “Server” non ci dovrebbe più essere.

Proviamo a loggarci usando il nostro utente di esempio “john@example.org” con la sua password “summersun”. Questo crea una connessione IMAP a “localhost” (sul server) e ci mostra le mail di John:

La posta in arrivo è vuota ma ci siamo loggati con successo. Forte.

Settare il reindirizzamento da HTTP a HTTPS

Per gli utenti che si dimenticano di scrivere “https” invece di “http”, impostiamo un reindirizzamento cosicché saranno rediretti all’URL sicura. Modifichiamo il file /etc/apache2/sites-enabled/webmail.example.org-http.conf ed inseriamo questo nella sezione VirtualHost:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]

Un sysadmin navigato potrebbe chiedersi perché io non abbia usato la forma di reindirizzamento più semplice:

# Don't use this!
Redirect permanent / https://webmail.example.org/

La ragione è che deviare tutte le richieste da HTTP a HTTPS romperebbe il meccanismo di rinnovo automatico di LetsEncrypt. Se un certificato è in scadenza, “certbot” mette un file nella sottocartella .well-known/acme-challenge del nostro DocumentRoot nel nostro host virtuale per verificare il nostro server. Se deviamo queste richieste al vhost HTTPS, la verifica di LetsEncrypt fallirà. Usando la RewriteCond(ition) possiamo escludere quel percorso dalla redirezione.

Assicuratevi che il modulo della redirezione sia abilitato in Apache:

a2enmod rewrite

Rendiamo le modifiche operative:

service apache2 reload

Se adesso aprite http://webmail.example.org/ nel vostro browser dovreste essere rediretti all’URL HTTPS automaticamente.

HTTPS? HTTPS? Reindirizzamento? Confusi?

Ripetiamo come i due host virtuali devono funzionare:

HTTP (/etc/apache2/sites-enabled/webmail.example.org-http.conf)
/.well-known/acme-challenge/ -> servito in /var/www/webmail.example.org per le verifiche di LetsEncrypt
tutto il resto -> deviato in HTTPS in modo che gli utenti possano usare Roundcube in sicurezza
HTTPS (/etc/apache2/sites-enabled/webmail.example.org-https.conf)
/ -> fornisce Roundcube da /var/lib/roundcube

Spero di aver chiarito un po’ le cose. Fate attenzione ai nomi dei due differenti file di configurazione.

Plugin

Più in basso in /etc/roundcube/config.inc.php c’è una lista di plugin che Roundcube carica. Aggiungete almeno i plugin “managesieve” e “password” in questo modo:

$config['plugins'] = array(
 'managesieve',
 'password',
);

Ci sono molti plugin disponibili. Date un’occhiata alla cartella /var/lib/roundcube/plugins/. Potete aggiungerne quante ne volete. Le personalizzazioni dei plugin vanno nelle cartelle /etc/roundcube/plugins/*.

Poi una configurazione opzionale. Il tempo di sessione predefinito in Roundcube è 10 minuti. Questo significa che se un utente non usa la webmail per più di 10 minuti, viene disconnesso. Lo trovo seccante e quindi ho aumentato il timeout ad un’ora. Per farlo aggiungete alla fine del file:

$config['session_lifetime'] = 60;

E se volete cambiare il logo predefinito di Roundcube basta settare:

$config['skin_logo'] = './ispmail-logo.png';

Dovete solo copiare quest’immagine in /var/lib/roundcube/ispmail-logo.png. Il logo deve essere largo 177×49 pixel. Sentitevi liberi di usare questo elegante logo ISPmail che ho creato con le mie mani. 🙂

Se il logo non funziona assicuratevi che i permessi siano corretti:

chmod a+r /var/lib/roundcube/ispmail-logo.png

Quando ricaricate il form del login nel browser, apparirà così:

Configurare il plugin managesieve

Il plugin “managesieve” permetterà ai vostri utenti di creare regole automatiche per gestire la loro posta. Queste regole vengono salvate nel server ed eseguite automaticamente. Però bisogna prima configurare questo plugin. Una configurazione può essere trovata in /usr/share/roundcube/plugins/managesieve/config.inc.php.dist nel vostro sistema. Copiamola nel posto dove Roundcube la cercherà:

cp /usr/share/roundcube/plugins/managesieve/config.inc.php.dist 
 /etc/roundcube/plugins/managesieve/config.inc.php

Nessun’altra modifica è richiesta.

Configurare il plugin password

Se volete permettere ai vostri utenti di cambiare la loro password dovete usare il plugin password. Copiate il file di configurazione predefinito /usr/share/roundcube/plugins/password/config.inc.php nel posto giusto:

cp /usr/share/roundcube/plugins/password/config.inc.php.dist /etc/roundcube/plugins/password/config.inc.php

Il file /etc/roundcube/plugins/password/config.inc.php richiede un paio di modifiche. Dobbiamo dirgli come funziona il nostro database e cosa fare quando un utente vuole cambiare la propria password. Il primo settaggio riguarda la lunghezza minima della password. Raccomando di obbligare almeno 10 caratteri. Infatti la complessità della password non è così rilevante. Considero XKCD cibo per la mente sulla sicurezza delle password. Quindi settiamo:

$config['password_minimum_length'] = 10;

Dobbiamo permettere all’utente di usare la vecchia password come nuova password. Può sembrare stupido ma dobbiamo farlo perché stiamo aggiornando lo schema delle password dall’algoritmo MD5, debole e non salato, con il migliore SHA2:

$config['password_force_save'] = true;

Il plugin password deve sapere come accedere al database:

$config['password_db_dsn'] = 'mysql://mailadmin:ChangeMe@localhost/mailserver';

Sostituite “ChangeMe” con la password casuale creata in precedenza per l’utente “mailadmin” del database.
Adesso diciamo al plugin come scrivere l’hash della nuova password nel database:

$config['password_query'] = "UPDATE virtual_users SET password=CONCAT('{SHA256-CRYPT}', ENCRYPT (%p, CONCAT("$5$", SUBSTRING(SHA(RAND()), -16)))) WHERE email=%u;";

Un po’ strano, eh? Questa query SQL genera un hash password formato da queste parti:

La stringa “{SHA256-CRYPT}”. Dice esplicitamente a Dovecot che questo è un hash SHA256 salato. Potete avere differenti tipi di password cryptate nel vostro database: questo lo rende chiaro.
La password effettiva generata usando la funzione crypt() del sistema operativo (MariaDB lo chiama quando usate la funzione SQL ENCRYPT) concatenando…
- La nuova password in chiaro (Roundcube sostituisce “%p” con questa).
- “$5$” – questo sta per l’algoritmo SHA-256. “man crypt” per vedere quali algoritmi sono supportati da crypt().
- e SUBSTRING(SHA(RAND()), -16) è usato come sale. Il sale aggiunge casualità addizionale che rende molto molto difficile fare il reverse-engineer della vera password dalla stringa cryptata.
E naturalmente vogliamo cambiare la password dell’utente mail corrente. “WHERE email=%u” assicura che scegliamo la riga giusta nel database. Roundcube sostituisce “%u” con nome utente – che è uguale all’indirizzo email nel nostro caso.

(In passato raccomandavo di usare “dovecot pw -s SHA256-CRYPT” per generare le password. Potete farlo ancora. Però effettivamente MySQL è in grado di generare hash SHA256 salati senza chiamare comandi shell. Grazie per il suggerimento, Martin.)

Prossima