Suite et dernier post concernant cette migration de Google vers notre solution perso.
Une fois toute l’infrastructure en place, il va nous manquer quelque chose : l’importation de vos données personnelles ; oui, celles que vous voulez protéger ;)
Migration
Les contacts
C’est la partie la plus simple, il suffit d’exporter votre liste de contacts et de l’importer :
Rendez vous dans Gmail et suivez les étapes suivantes :
Le fichier généré peut être ensuite importé votre Baïkal via Roundcube. Dans votre carnet d’adresses, choisissez « Importer » :
Sélectionnez ensuite le fichier d’export généré par Gmail, choisissez le carnet d’adresses pointant sur votre Baïkal et cliquez sur « Importer » :
Et voilà, maintenant un peu de patience, le processus peut prendre pas mal de temps si vous avez pas mal de contacts.
Les agendas
Là encore, rien de bien sorcier, il suffit d’exporter ses calendriers au format ICS et de les importer dans le Baïkal via Roundcube.
Les mails
Bon c’est là que ça se corse un peu…
GMail ne fait rien comme tout le monde et utilise des labels pour faciliter le classement de ses mails. Ce n’est pas une mauvaise idée tant qu’on reste en mode « Web ». En consultant son compte via IMAP on retrouve ses labels sous forme de dossiers où vous pouvez consulter tous les mails appartenant au label correspondant. Là où ça devient « drôle » : un mail peu avoir plusieurs labels ! Un mail va donc se retrouver dans le dossier « All Mail » ainsi que dans tous les dossiers des labels auxquels il est associé. Avec un tel système un mail pourra être dupliqué un certain nombre de fois si vous faites une synchronisation bête et méchante…
La première étape est de se rendre dans les paramètres de son comtpe GMail et d’activer l’accès IMAP via l’onglet correspondant :
Une bonne chose est de faire ensuite le tri de ce que vous voulez rendre disponible via l’IMAP en cochant ou décochant la case suivante (onglet « Label ») :
Ca peut être une bonne chose d’enlever la corbeille ainsi que le dossier spam et de s’assurer que les « Chats » seront disponibles.
Une fois tout cela de réglé, on va synchroniser tout ça. Et pour cela, il y a imapsync ! Malheureusement l’outil est passé payant, pas grave on peut récupérer les sources sur le Github :
apt-get install makepasswd rcs perl-doc libmail-imapclient-perl make libfile-copy-recursive-perl
git clone git://github.com/imapsync/imapsync.git
cd imapsync
make install
#Vérifiez si le binaire est bien installé
imapsync -v
Il suffit ensuite de faire un test de migration de votre compte GMail vers votre serveur :
imapsync --host1 imap.gmail.com --user1 username@gmail.com --password1 ******** --host2 <votre_serveur_imap> --user2 username@domaine.tld --password2 ******* --syncinternaldates --ssl1 -ssl2 --noauthmd5 --split1 100 --split2 100 --port1 993 --port2 993 --useheader 'Message-Id' --skipsize --allowsizemismatch --dry --justfoldersizes
Quelques explications :
- –syncinternaldates : permet de synchroniser la date de réception/émission d’un mail
- –split[12] : nombre de message que l’on traite entre deux requêtes IMAP
- –useheader ‘Message-Id’ : on précise le header sur lequel se baser afin d’éviter le freeze du programme en cas de traitement de gros mail
- –skipsize –allowsizemismatch : permet de s’affranchir des problèmes de taille non concordante d’un mail entre les deux serveurs.
- –dry : juste une simulation
- –justfoldersizes permet de vous faire une idée rapide en affichant la taille des dossiers à synchroniser.
Vous pouvez aussi utiliser –debug en cas de souci.
Une fois prêt vous pouvez enlevez les options –dry –justfoldersizes et prendre un café, ça risque de durer longtemps surtout si votre boite mail est bien remplie ou si vous êtes derrière une ligne ADSL.
Avec cette méthode toute votre arborescence sera migré moyennant le souci de duplication de mail évoqué plus haut.
Une autre solution consiste à ne migrer que votre répertoire « All Mail » et de le placer dans un dossier spécifique dans votre nouvelle boite mail. Tant pis pour le classement des mails mais au moins vous éviterez leur duplication pour le moins inutile.
Backup
MX de backup
Parlons un peu du temps de rétention des mails.
Imaginons que pour une raison X ou Y votre serveur mail soit injoignable. Un serveur de mail souhaite vous envoyer un mail mais comme votre serveur n’est pas disponible celui-ci lui reste sur les mains.
La bonne nouvelle, c’est que le serveur ne va pas supprimer tout de suite votre mail, il va réessayer plusieurs fois dans une intervalle de temps qui augmentera au fur et à mesure des essais (c’est le plus souvent exponentiel). Si votre serveur est toujours injoignable au bout de la rétention maximale autorisée, le mail sera renvoyé à l’expéditeur avec un joli message d’erreur lui expliquant le problème.
Ainsi la durée maximale autorisée du downtime avant de perdre des mails ne dépend pas de vous mais de la rétention maximale des serveurs qui souhaitent vous joindre.
Cette valeur vous ne la connaissez pas, elle est en moyenne de 48h mais peut être plus faible ou plus élevée en fonction de l’humeur du sysadmin.
Une bonne idée est donc de vous configurer dans un coin un serveur mail de backup type « Store & Forward ». Comme son nom l’indique celui-ci se contentera de stocker les mails des domaines que vous gérez et les délivrera à votre serveur mail principal quand celui-ci redevient joignable. La bonne nouvelle c’est que c’est maintenant vous qui gérez la rétention maximale :)
Vous pouvez l’installer sur une autre serveur, sur celui d’un pote, ou sur un PC derrière votre ligne ADSL (dans ce cas il vous faudra gérer votre IP dynamique).
Petit exemple de configuration avec postfix /etc/postfix/main.cf :
#Durée de rétention de 3 mois
#On ne sait jamais si vous êtes parti faire le tour du monde :)
maximal_queue_lifetime = 90d
relay_domains = $mydestination, <vos domaines gérés par votre MX principal>
Un petit /etc/init.d/postfix restart et hop.
Maintenant il faut annoncer notre MX de backup dans les DNS, en s’appliquant sur la configuration vue en partie 2 :
mail.roflcopter.fr IN A 88.190.227.29
backup-mail.roflcopter.fr IN A 67.215.65.132
roflcopter.fr IN MX mail.roflcopter.fr 10
roflcopter.fr IN MX backup-mail.roflcopter.fr 20
Vous noterez que le MX de backup a un poids plus important que le primaire. Cela indique aux serveur mails d’utiliser le primaire en priorité puis le backup si jamais le primaire ne répond pas.
Petite remarque, les margoulins qui essaient de vous envoyer du spam vont essayer par tous les orifices connus (surtout si votre serveur de mail applique du GreyListing). Il ne faut donc pas « whitelister » automatiquement les mails provenant de votre/vos MX de backup mais les traiter comme n’importe quel mail.
Backup des données
Là c’est pas compliqué, IredMail fourni plusieurs script d’export de la base LDAP et de la base MySQL qui sont lancés normalement en crontab :
# iRedMail: Backup OpenLDAP data on 03:00 AM
0 3 * * * root /bin/bash /var/vmail/backup/backup_openldap.sh
# iRedMail: Backup MySQL databases on 03:30 AM
30 3 * * * root /bin/bash /var/vmail/backup/backup_mysql.sh
Tout est exporté dans les répertoires /var/vmail/backup/ldap et /var/vmail/backup/mysql. Sachant que vos boites mails sont contenues dans /var/vmail/vmail1 c’est une bonne idée de sauvegarder le contenu du répertoire /var/vmail très régulièrement.
Plusieurs choix s’offrent à vous tels qu’un banal scp sur un autre serveur ou à la maison, ou même déployer un vrai service de backup tel que bacula.
Une autre idée est d’utiliser un client mail lourd à la maison tel que Thunderbird. Au moins tous vos mails seront rapatriés et stockés chez vous.
Aller plus loin
Converse.js
Merci à xorriso qui via son commentaire m’a fait découvrir Converse.js. C’est un simple applet de chat compatible XMPP super bien foutu et très ergonomique.
Et il y a même un plugin roundcube : https://github.com/priyadi/roundcube-converse.js-xmpp-plugin.
Voici la configuration, via le fichier config.inc.php, que j’ai adoptée afin d’avoir ma session XMPP en auto-login sur le roundcube :
// Hostname portion of XMPP username (bare JID), example: "example.net"
$rcmail_config['converse_xmpp_hostname']= function($args) {
return preg_replace('/^.*@/', '', $args['user']);
};
// Username portion of XMPP username (bare JID), example: "user"
// if this contains @, this will only take the part before @,
// and the part after @ will replace the hostname definition above.
$rcmail_config['converse_xmpp_username']= function($args) {
return preg_replace('/@.*$/', '', $args['user']);
};
// XMPP password
$rcmail_config['converse_xmpp_password']= function($args) {
return $args['pass'];
};
Rainloop
J’en ai parlé quelques fois sur mon shaarli…
Rainloop est un webmail en cours de développement très intuitif et bien foutu. Il lui manque encore quelques fonctionnalités (tel que la gestion des filtres Sieve, ou un bon calendrier compatible CalDav) mais c’est un projet à suivre de très très près.
Je ne serais pas surpris de l’utiliser d’ici quelques mois à la place de Roundcube…
En conclusion
Voilà, j’espère que ce tutoriel en cinq parties vous aura permis de vous convaincre de la possibilité de se passer plus ou moins facilement de Google tout en gardant un niveau de service acceptable.
Il y a pas mal de travail à faire pour mettre en place une telle architecture et ce n’est malheureusement pas à la portée du premier venu. Après rien n’empêche de mettre en place ce service pour vous et de le proposer ensuite à votre entourage (famille, amis).