Sempre il solito server di posta (Debian 6+Postfix+Dovecot+MySql) con ClamAV e SpamAssassin (integrato adattando quest’altra guida).

Premessa:

• da sempre utilizzo una casella @gmail.com come catch-all/archivio. Tutte le mie caselle di posta inoltrano una copia del messaggio alla casella in questione, in questo modo ho costantemente sotto controllo tutti gli indirizzi (una decina) in un unico punto via browser o cellulare Android. Inoltre utilizzando questa soluzione non devo preoccuparmi di limiti e tempi del servizio di recupero messaggi via POP3 messo a disposizione da Gmail;
• lo spam non viene cancellato direttamente, viene archiviato tramite Sieve in una cartella «Spam». Periodicamente controllo la cartella in questione via WebMail alla ricerca di falsi positivi e la svuoto.

Per inoltrare una copia dei messaggi utilizzo direttamente la tabella Forwardings:

• source: indirizzo_originale
• destination: indirizzo_originale, indirizzo_gmail

Problema: la casella e-mail di questo blog riceve un po’ troppa rumenta per i miei gusti, per cui la cartella Spam di Gmail è costantemente piena (le e-mail vengono inoltrate prima dell’applicazione dei filtri). Dovendo tenerla sotto controllo per evitare falsi positivi, la cosa non è piacevole.

La soluzione è inoltrare la posta a livello di Sieve, quantomeno per le caselle più problematiche. Per farlo bisogna modificare la sezione plugin del file /etc/dovecot/dovecot.conf aggiungendo la riga

sieve = /home/vmail/%d/%n/.dovecot.sieve

%d verrà sostituito dal dominio, %n dall’utente (la parte prima della @), per cui il file verrà cercato in un percorso del tipo /home/vmail/example.com/info/.dovecot.sieve per info(at)example.com

Nel file .dovecot.sieve (ricordarsi di assegnare come proprietario l’utente vmail) inserire

require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
  fileinto "INBOX.Spam";
}
else {
  redirect "indirizzo_gmail";
  keep;
}

Nuovo post della serie “appunti per tecnici anziani”.

Una volta configurato il simpatico server utilizzando questa guida come base (Debian 6 con Postfix, Dovecot e MySql per registrare utenti e virtual domain), sorge il dubbio: e adesso come ci accedo via WebMail?

Dopo qualche ricerca ho deciso di provare RoundCube, anche considerando che la nuova versione stabile è stata rilasciata il 14 dicembre 2011 (segno che il progetto è attivo).

Lasciando perdere la versione obsoleta nei repository, configuro il virtual domain per Apache (webmail.example.com) e ci decomprimo i file rimuovendo direttamente la cartella INSTALL. A questo punto bisogna procedere con la configurazione.

Creazione database MySql

Bisogna creare un nuovo database (e volendo un nuovo utente) per gestire sessioni e compagnia bella. Da console di MySql:

CREATE DATABASE roundcubemail;
GRANT ALL PRIVILEGES ON roundcubemail.* TO utente IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
USE roundcubemail;
SOURCE percorsowww/SQL/mysql.initial.sql;

Sostituire username, password e percorsowww con i dati corretti. L’ultima riga esegue un file .sql per creare le tabelle necessarie nel database roundcubemail.

File di configurazione

A questo punto bisogna rinominare (o meglio copiare) i file db.inc.php.dist e main.inc.php.dist in /config rimuovendo il .dist e apportare alcune modifiche.

db.inc.php (stringa di connessione al database MySql)

$rcmail_config['db_dsnw'] = 'mysql://utente:password@localhost/roundcubemail';

main.inc.php

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['smtp_server'] = 'localhost';
$rcmail_config['create_default_folders'] = true;
$rcmail_config['junk_mbox'] = 'Spam';

Spiegazione ultima riga: tramite regole Sieve sposto lo SPAM filtrato da SpamAssassin in una cartella “Spam”, non “Junk” come previsto dal file di configurazione standard.

Plugin per la modifica delle password

Ok, funziona tutto. Ma se un utente non ha accesso al database MySql come può modificare la propria password? Semplice: basta attivare il plugin “Password” cambiando questa riga in main.inc.php

$rcmail_config['plugins'] = array('password');

Anche in questo caso il plugin ha un file di configurazione da sistemare (rinominare o copiare senza .dist il file /plugins/password/config.inc.php.dist).

$rcmail_config['password_confirm_current'] = true;
$rcmail_config['password_db_dsn'] = 'mysql://mailadminutente:mailadminpassword@localhost/maildb';
$rcmail_config['password_query'] = 'UPDATE users SET password=ENCRYPT(%p) WHERE email=%u LIMIT 1';

Nel mio caso l’utente MySql di RoundCube è diverso da quello utilizzato per gestire gli utenti di posta, per cui devo modificare la stringa di connessione specificando user, password e database corretti. Anche la stringa SQL deve essere adeguata in base alla struttura del database.

Permettere al browser di memorizzare utente e password
Anche in questo caso bisogna mettere mano al file di configurazione principale main.inc.php.

// Allow browser-autocompletion on login form.
// 0 - disabled, 1 - username and host only, 2 - username, host, password
$rcmail_config['login_autocomplete'] = 2;

Look

Questo è l’aspetto con il tema default di RoundCube 0.7

Questo invece è il nuovo tema “Larry” su trunk (0.8 via svn)

Proseguendo il discorso iniziato ieri, oggi ho messo mano al tema dando una decisa ripulita alle immagini (soprattutto al numero di file utilizzati). Ecco cosa vede da oggi un utente con Internet Explorer 6 (banner in alto a destra)

Con l’occasione ho scoperto che il fido IETester non gradisce questo script per le PNG, per cui mi è toccato installare una macchina virtuale con XP e Internet Explorer 6. Fortunatamente Microsoft mette a disposizione delle VM già predisposte e utilizzabili con Windows 7 e XP Mode, per cui l’operazione ha richiesto pochi minuti 😀

Da qualche giorno è disponibile sull’Android Market la nuova versione dell’app WordPress per Android (attualmente è arrivata alla versione 2.0.1). Il salto in avanti rispetto alla versione precedente è davvero impressionante 🙂

Questa è la dashboard iniziale:

E questa è la sezione per la gestione dei commenti (la gestione pagine/articoli è strutturata in modo analogo):

Come per il motore principale WordPress.org è possibile contribuire alla traduzione segnalando errori o correzioni. Un paio di settimane fa ho rivisto e completato la traduzione esistente, cercando di eliminare un po’ di errori come forme di cortesia, misto di seconda/terza persona, inconsistenza nella traduzione di alcuni termini chiave come “post”, Camel Case come se piovesse. Non seguendo da vicino lo sviluppo di WordPress, onestamente non pensavo uscisse una nuova versione in tempi così brevi 🙂

Da ieri pomeriggio risulta particolarmente problematico raggiungere i domini mozillaitalia.org (sito e forum).

Il problema non è sicuramente legato al server, visto il carico ridottissimo che risulta accedendo via ssh, secondo il “sysadmin” che ci segue il problema è legato al sovraccarico dei DNS, a me sembrerebbe un problema di routing visto che il risultato non cambia cercando di raggiungere l’IP del server :-\

traceroute to 69.64.58.98 (69.64.58.98), 64 hops max, 52 byte packets
 1  192.168.133.20 (192.168.133.20)  1.994 ms  0.855 ms  0.823 ms
 2  * * *
 3  172.17.121.45 (172.17.121.45)  31.736 ms  31.762 ms  30.381 ms
 4  172.17.120.1 (172.17.120.1)  30.565 ms  31.453 ms  31.977 ms
 5  172.17.10.129 (172.17.10.129)  34.452 ms  33.577 ms  32.612 ms
 6  172.17.10.89 (172.17.10.89)  32.181 ms  32.645 ms  32.834 ms
 7  pos1-10-0-0.milano26.mil.seabone.net (195.22.192.29)  35.270 ms  36.815 ms  35.213 ms
 8  ge12-0.franco32.fra.seabone.net (89.221.34.55)  54.930 ms  53.671 ms  53.926 ms
 9  te0-7-0-0.mpd21.fra03.atlas.cogentco.com (130.117.15.45)  61.616 ms  61.365 ms  60.586 ms
10  te0-0-0-2.mpd21.ams03.atlas.cogentco.com (130.117.48.137)  64.813 ms
    te0-4-0-2.mpd21.ams03.atlas.cogentco.com (154.54.39.173)  68.272 ms
    te0-3-0-2.mpd21.ams03.atlas.cogentco.com (130.117.2.41)  67.981 ms
11  te0-4-0-2.ccr21.lpl01.atlas.cogentco.com (154.54.58.62)  71.509 ms
    te0-3-0-2.mpd22.ams03.atlas.cogentco.com (154.54.39.185)  68.140 ms
    te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89)  67.236 ms
12  te0-3-0-4.ccr21.ymq02.atlas.cogentco.com (154.54.6.141)  143.779 ms
    te0-2-0-4.ccr21.ymq02.atlas.cogentco.com (154.54.0.70)  145.520 ms
    te0-0-0-7.ccr22.lpl01.atlas.cogentco.com (154.54.37.106)  75.592 ms
13  te0-1-0-4.ccr22.ymq02.atlas.cogentco.com (66.28.4.21)  144.662 ms
    te0-2-0-7.mpd21.yyz02.atlas.cogentco.com (154.54.7.213)  175.277 ms
    te0-4-0-4.ccr22.ymq02.atlas.cogentco.com (154.54.44.213)  145.563 ms
14  te0-1-0-6.ccr22.yyz02.atlas.cogentco.com (154.54.42.237)  149.700 ms
    te0-1-0-3.mpd21.ord01.atlas.cogentco.com (154.54.42.9)  180.738 ms
    te0-2-0-6.mpd22.ord01.atlas.cogentco.com (66.28.4.57)  163.137 ms
15  te0-2-0-6.ccr22.ord01.atlas.cogentco.com (66.28.4.137)  180.530 ms
    te0-2-0-0.ccr22.ord01.atlas.cogentco.com (154.54.7.109)  176.713 ms
    te0-5-0-2.ccr22.ord01.atlas.cogentco.com (154.54.7.169)  162.576 ms
16  * * *
17  38.104.162.66 (38.104.162.66)  179.616 ms  230.761 ms  182.787 ms
18  static-ip-209-239-125-4.inaddr.ip-pool.com (209.239.125.4)  170.469 ms  167.386 ms  169.566 ms
19  colossus913.server4you.de (69.64.58.98)  165.629 ms  165.805 ms  166.072 ms

UPDATE ore 17: come peraltro suggerito via mail da un gentile lettore, il routing non c’entrava una fava. Dopo aver perso un paio d’ore per capire da che parte guardare Plesk e trovare i relativi log (bleah!), ho trovato un errore relativo al raggiungimento del limite di MaxClients. A quel punto mi sono accorto che il file apache2.conf risultava modificato giusto ieri a mezzogiorno, reimpostato il valore di MaxClients a 150 e tutto è tornato a funzionare (spero…).

Da qualche tempo medito di alleggerire e ottimizzare il tema WordPress di Mozilla Italia, lavorando soprattutto sul fronte immagini, in modo da ridurre il consumo di banda e velocizzare il caricamento della pagine.

Stamattina, complice la mancanza di sonno e la necessità di tenere le mani occupate per non scorticarmi vivo, ho deciso di dare un’occhiata alle statistiche del sito, in particolare per capire se là fuori ci sono ancora dei malati di mente che navigano con Internet Explorer 6. Risultato:

Il 12,90% degli utenti che utilizza Internet Explorer è ancora fermo alla 6 e rappresenta il 6,49% delle visite totali. Forse la fine del mondo ce la meritiamo…