Hébergement mail et présomption d’innocence

Ça fait quelques temps que je vois sur les internets des gens qui jettent l’éponge après s’être lancé dans l’aventure de hébergement de leur mails.

La raison : devoir sans cesse se justifier auprès – entres autres – des GAFAM. Car malheureusement la présomption d’innocence n’existe pas dans ce milieu. Vous serez jugé (ou au mieux présumé) coupable de spam et ce jusqu’à preuves du contraire. Votre mail, s’il n’essuie pas un refus catégorique de prise en charge de la part du serveur, atterrira  donc dans le dossier Spam de votre destinataire. Bon courage pour être lu…

Pourtant, de simples précautions suffises pour que ça se passe relativement bien (bon sauf pour Microsoft qui a juste décidé d’être con…). Passons-les en revue.

État des lieux

Avant d’entreprendre toute action, la première chose à faire est de faire l’état des lieux de votre archi de courrier sortant. Pour cela, il y a plusieurs services en ligne :

Le principe, vous envoyez un mail – comme à votre habitude – à une adresse bien connue et on vous dit comment vous êtes perçu. (Juste niveau spam hein, pour le look faut voir ailleurs).

Bon, je vous avoue j’ai mon petit préféré. Leur batterie de test est plutôt complète et ils vont même jusqu’à donner l’URL des résultats via un bounce. Cela permettra aussi de valider la configuration de votre serveur mail et que ceux-ci arrivent bien dans votre boite mail.
Normalement si votre serveur mail se fait envoyer bouler définitivement par un autre, celui-ci devrait, tout vexé qu’il est, vous générer un rapport de non délivrance et le fourrer dans votre Inbox. Chose plutôt utile, car au moins vous serez au courant qu’un mail envoyé n’a jamais atteint sa destination finale.

Testons

Première chose à faire, donc, envoyer un mail à l’adresse indiquée et attendre patiemment. En effet, la première chose testée est le respect de leur politique de greylisting :

2017-02-02T14:11:57+01:00 thyburce postfix/smtp[22445]: 9B0A6C01E7: to=<test@allaboutspam.com>, relay=mx.allaboutspam.com[96.126.107.60]:25, delay=5.9, delays=0.02/0.01/0.3/5.5, dsn=4.0.0, status=deferred (host mx.allaboutspam.com[96.126.107.60] said: 452 Greylisted. Please try again after some time. (in reply to end of DATA command))

Il faut donc que votre serveur attende quelques minutes avant de retenter un nouvel envoi de mail.

Quelques minutes plus tard…

2017-02-02T14:18:26+01:00 thyburce postfix/smtp[23008]: 9B0A6C01E7: to=<test@allaboutspam.com>, relay=mx.allaboutspam.com[96.126.107.60]:25, delay=395, delays=389/0.01/0.32/5.6, dsn=5.0.0, status=bounced (host mx.allaboutspam.com[96.126.107.60] said: 552-Thanks for using ALLABOUTSPAM.COM Email server test. Your test results are 552 available at http://www.allaboutspam.com/email-server-test-report/?key=D979EE770E39318B6D5A9AC11561364E  (in reply to end of DATA command))

Le mail part et… se fait envoyer bouler du serveur. Tout est nominal ! C’est le comportement voulu, le message d’erreur comporte un lien avec le résultat de l’analyse de votre système de courrier sortant. Théoriquement vous devriez avoir un rapport de « bounce » dans votre boite mail.

Allons voir le détail de ce rapport…

Le Reverse DNS

Premier truc, le serveur distant va la plupart du temps faire une résolution d’adresse inverse (IP > Nom). Vous devez avoir une résolution inverse fonctionnelle !

Le HELO

Et non il ne manque pas un L :)

C’est la première chose à dire lorsqu’on se présente en SMTP à un autre serveur. Faut dire bonjour. Et quant à faire, autant se présenter correctement.

Ici votre serveur devrait se présenter selon un nom de domaine résolvable et si possible correspondant au domaine obtenu plus haut par résolution inverse. Là c’est la classe, vous marquez des points (non vraiment pour de vrai).

Les Blacklist

Il existe tout un tas de blacklist disponible gratuitement, privées ou sur abonnement. Ici tout dépend de ce que vous avez en face. Le mieux c’est de vérifier aussi par vous-même. N’oubliez pas de tester les domaines portés par votre serveur mail ainsi que vos IP de sortie ! 

La plupart du temps il n’y a pas de raison que votre domaine soit blacklisté à moins d’avoir :

  • envoyé une quantité de spam auparavant,
  • repris un ancien domaine déjà blacklisté pour la raison précédente,
  • un domaine contenant des mots explicites.

Pour l’IP c’est un peu plus fourbe… Si vous êtes derrière de l’ADSL, n’y pensez même pas vous êtes blacklisté et il n’y aura rien à faire. Ça ne vous empêchera pas d’envoyer des mails (si votre FAI le permet).

Il peut aussi arriver qu’un ou plusieurs voisins de votre plage d’IP envoient du spam et certains éditeurs de blacklist décident de bannir en totalité la plage d’IP associée.

La plupart des éditeurs possèdent un formulaire de contact afin de demander d’être retiré de leur liste. De mon côté, j’ai toujours eu un retour positif de leur part (après avoir montré patte blanche bien sûr).

Une fois votre courrier sortant bien configuré, c’est la seule partie qui rester à surveiller de temps en temps et qui vous demandera parfois un peu de fil à retordre. Rien de bien méchant cependant c’est juste un peu d’administratif :)

Le SPF & DKIM

Ça on ne les présente plus… Ils sont obligatoires (vraiment). Le SPF c’est un record à publier dans son DNS, ça ne coûte rien à faire et il y a des tutos partout sur le net pour le mettre en place.

Le DKIM c’est un poil plus compliqué, un record DNS + conf de votre serveur mail pour signer tous les mails sortant. Encore une fois : un petit tuto et on n’en parle plus. Une fois que c’est en place ça j-u-s-t-e marche.

Inutile de préciser que le test doit être positif.

URIBL (Realtime URI Blacklist)

Ça c’est plus vicieux. J’imagine que vous n’allez pas envoyer des liens à vos proches pour une augmentation de taille de chibre ! Par contre, certains Header SMTP peuvent faire tiquer l’antispam qui pourrait considérer le mail comme du Spam (déjà qu’il est sur la défensive…).

De mon côté, j’ai mis en place une politique de nettoyage des headers des mails sortant pour éviter toutes fuites d’info non souhaitées et éviter que l’antispam distant me fasse un caca nerveux !

Petite contrainte avec le DKIM cependant : postfix doit nettoyer les headers avant la transmission au processus de signature DKIM. En effet, la signature DKIM se base sur tout le contenu du mail. Si vous altérez le contenu (suppression des headers) après la signature, celle-ci ne sera plus valide.

Idem pour le courrier entrant, le plus simple étant de ne pas y toucher.

Il faut donc appliquer notre politique de nettoyage qu’aux courriers sortant uniquement.

Bonne nouvelle postfix sait faire ça. Rendez-vous dans le fichier master.cf et localiser la ligne submission (qui correspond au service SMTP des courriers sortant) :

On va lui rajouter un petit service de « cleanup » :

submission inet n       -       n       -       -       smtpd
    -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
    -o cleanup_service_name=subcleanup
    -o content_filter=smtp-amavis:[127.0.0.1]:10026

Chez moi c’est Amavis qui s’occupe de la signature DKIM c’est donc le dernier service appeler avant l’envoi effectif du mail.

Tout en bas du fichier rajouter les lignes suivantes :

subcleanup unix n       -       -       -       0       cleanup
    -o header_checks=pcre:/etc/postfix/headers_cleanup.pcre

On demande donc au service d’aller faire le ménache dans les headers.

Mais PoGo que contient ce fichier headers_cleanup.pcre ?

I'M GLAD YOU F**KING ASKED ! | made w/ Imgflip meme maker

/^Received:/                            IGNORE
/^X-Originating-IP:/                    IGNORE
/^X-Mailer:/                            IGNORE
/^Mime-Version:/                        IGNORE
/^Message-Id:/                          IGNORE

Les header Received révèlent tout le parcours du mail avant d’arriver à votre serveur de mail sortant. Ils indiquent notamment IP/Nom de domaines internes par lesquels le courrier aura transité avant d’être jeté dans les Internet. C’est justement ça qui peut titiller certains antispam à cheval sur les règles (note pour plus tard, insérer ici un jeu de mot selon l’inspiration du moment…).

X-Originating-IP, s’il est supporté par votre client mail (ou webmail) peut révéler votre IP publique utilisée par votre client lors de l’envoi de votre mail.

Le nettoyage des autres headers permettent d’éviter la divulgation d’information non pertinentes.

En conclusion

Faites en sorte d’avoir le rapport le plus clean possible car une fois tous ces points vérifiés, tout devrait bien se passer.

N’hésitez pas à relancer le test tous les 2/3 mois.

Davdroid, RFC 6764, DNS et Nextcloud

Et oui rien que ça !

Les présentations

Davdroid permet de synchroniser contacts et agendas via carddav et caldav avec son android. Son intégration est totalement transparente, et ça juste marche ! (soulignons-le).

Pour cela, il suffit de rentrer l’url de son serveur Nextcloud, son login et mot de passe comme indiqué ici.

Et si je vous disais qu’il est possible de n’entrer que son email et mot de passe pour configurer son compte ? *

*Offre soumise à conditions : vos utilisateurs doivent s’authentifier via leur adresse mail (voir ici pour plus d’explications)

Introducing RFC 6764

Le RFC 6764 permet via des enregistrements DNS de publier les informations de connexion à des ressources Caldav/Carddav pour un domaine donné.

La publication d’une ressource utilise deux type d’enregistrements DNS :

  • Un de type SRV pour renseigner le nom ou IP du serveur ainsi que le port à utiliser.
    #Exemple d'un serveur caldav sans TLS 
    _caldav._tcp SRV 0 1 80 calendar.example.com. 
    
    #Exemple d'un serveur caldav avec TLS 
    _caldavs._tcp SRV 0 1 443 calendar.example.com.
  •  Un de type TXT pour le path.
    #Exemple d'un serveur caldav sans TLS 
    _caldav._tcp TXT "path=/caldav"
    
    #Exemple d'un serveur caldav avec TLS 
    _caldavs._tcp TXT "path=/caldav"

(même concept avec carddav, les records sont de la forme _carddav._tcp / _carddavs._tcp)

Exemple de configuration avec Nextcloud

Imaginons que notre serveur soit joignable sur https://nextcloud.example.com/nextcloud.
Voici la configuration DNS qu’il faudrait apporter dans ce cas :

_caldavs._tcp SRV 0 1 443 nextcloud.example.com.
_caldavs._tcp TXT "path=/nextcloud/remote.php/dav/"

_carddavs._tcp SRV 0 1 443 nextcloud.example.com.
_carddavs._tcp TXT "path=/nextcloud/remote.php/dav/"

Évidemment c’est à adapter en fonction de votre environnement !

Cette configuration doit être rajoutée sur tous les domaines mails gérés par votre serveur.

Une fois cela fait, plus besoin d’indiquer quoi que soit d’autre à Davdroid que sont email/mot de passe et il retrouvera ses petits tout seul !

A+ sous l’bus Google – Partie 6

Avoir franchir le grand pas, il est temps de faire un retour d’expérience sur les 3 ans passés !

3 ans plus tard

Eh bien, mes mails sont toujours auto-hébergés ! J’ai même fermé mon compte GMail.

En fait, je n’ai rien de bien notable à vous faire partager. Ça juste marche !
A part certaines fois où j’ai dû m’occuper de blacklistage sauvage du range d’adresse IP par Microsoft ou un éditeur d’anti-spam pro. Oui maintenant c’est plus simple de ban des /24, « tirons d’abord et envoyons les questions dans /dev/null ».

La machine portant les mails a subit une migration Debian 7 > Debian 8 sans heurs ainsi que plusieurs mises à jour mineures et majeures d’Iredmail (toujours aussi bien documentées au passage).

A part cela, nan vraiment RAS !

A moins que… Continuer la lecture de A+ sous l’bus Google – Partie 6

A+ sous l’bus Google – Partie 5

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 :

Contact Manager

Contact Manager

Le fichier généré peut être ensuite importé votre Baïkal via Roundcube. Dans votre carnet d’adresses, choisissez « Importer » :

Carnet d'adresses

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 » :
Importer les contacts

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 :2014-04-04 16_57_41-Settings - Gmail

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 ») :

2014-04-04 16_59_38-Settings - Gmail

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&nbsp;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).

A+ sous l’bus Google – Partie 4

Ah quel plaisir d’avoir ses contacts et calendrier(s) synchronisés sur son téléphone et son webmail !
Un nouveau numéro de téléphone à noter ? Une simple édition du contact dans votre webmail et son numéro apparaîtra dans votre téléphone.
L’intégration de ce genre de services dans la vie de tous les jours la rend plus facile.

Cela dit, Google n’a pas le monopole du plaisir, des solutions existent et nous allons les mettre en place :)

Le choix du serveur

Tout d’abord choisissons un protocole libre et ouvert…
Bon, dans ce domaine, il n’y a pas trop le choix : on va utiliser les extensions CalDAV et CardDAV de WebDAV.
Il faut donc dans un premier temps trouver un serveur parlant couramment ces deux protocoles. A l’heure où j’écris ces lignes, seulement quelques serveurs implémentes ces protocoles de façon sérieuse et facile à mettre en place, voici ma courte sélection :

J’ai rapidement éliminé OwnCloud, il faudrait l’utiliser quotidiennement pour que cela vaille le coup, et ce n’est pas le cas pour moi.
J’ai ensuite testé les autres candidats en gardant à l’esprit qu’il faudra mettre les mains dans le cambouis ! Eh oui, si on reprend mon « cahier des charges » de la partie 1, je souhaite une authentification unique au niveau des différents services ! Le serveur doit donc pouvoir s’y plier d’une façon ou d’une autre.

Baïkal est rapidement sorti du lot, à vrai dire j’ai été conquis par son côté minimaliste (faire une chose et une seule, mais la faire correctement), et le fait d’avoir pu, simplement grâce à deux patchs, réaliser la partie authentification.
Pis Baïkal ça sonne russe, et le lac portant ce nom est magnifique :)

Je vais expliquer dans la suite comment procéder. Cela dit, rien ne vous empêche d’utiliser un autre serveur Cal/CardDAV.

Où l’on parle de Baikal

A l’époque où j’ai commencé à titiller la chose, Baïkal (en version 2.4) avait besoin de deux patchs pour s’intégrer dans ma solution :

  • Un patch pour le support des adresses mail comme nom d’utilisateur, or le problème est réglé depuis la sortie de la version 2.5.
  • Un patch pour ajouter le support de l’authentification IMAP. Il fallait configurer en dur dans le fichier php le serveur IMAP sur lequel baser l’authentification. C’était sale mais ça fonctionnait bien.

Avant d’écrire cet article, je me suis promené sur le Git de Baïkal et quelle ne fut pas ma surprise de voir ce pull request : enfin, un support d’authentification externe LDAP/MAIL propre et intégré à l’interface \o/
Voyez plutôt :

Ah si regardez ça si c'est pas propre :)

success_kid

Pour vous faciliter la vie, et en attendant que le pull-request soit accepté et déployé dans une hypothétique nouvelle version, je vous ai préparé un git avec une version de Baïkal 2.7 déjà patchée.

Pour le déployer chez vous :

git clone https://wtf.roflcopter.fr/git/pogo/baikal.git

Il suffit ensuite d’installer et configurer Baikal en suivant le guide officiel.

Pour le type d’authentification, choisissez « Mail » en StartTLS et entrez l’IP ou le nom de votre serveur mail. Vous pouvez, si vous le désirer, utiliser le LDAP d’iRedMail au lieu de l’authentification IMAP, à vous de voir :)

Vous n’aurez normalement pas besoin de créer d’utilisateur dans Baïkal, lors d’une première connexion authentifiée, il sera créé automatiquement.

Pour le débug de l’authentification il y a même une doc avec la liste des commandes à entrer et l’interprétation des erreurs.

Baïkal n’offre que la partie serveur Card/CalDAV, il faut donc maintenant s’occuper de la partie client.

MyRouncube

J’expliquait dans la première partie que je voulais une interface où les mails, contacts et calendriers sont intégrés. Ayant fait le choix d’utiliser Roundcube je suis parti en quête de plugins.
Voilà le résultat : le quasi néantcorbeau3ce8
Un plugin carddav plus maintenu depuis 2 ans (fonctionnel cependant), mais rien de sérieux pour le calendrier.

Pourtant un nom revient souvent dans mes recherches : MyRoundcube.

MyRoundcube propose une bonne liste de plugins offrant au webmail une dimension un peu plus « pro ». Certains sont payant, d’autres gratuits. Le hic : les plugins qui nous intéressent ici sont payant.
Ils existent dans une version « light », mais les fonctionnalités intéressantes (support CalDAV pour le calendrier, intégration automatique des contacts, …) font partie des versions payantes.

Installer le plugin calendar_plus coûte 8 crédits (soit 8€), les mises à jour majeures sont payantes : entre 4€ et 1€ (depuis 9 mois, il n’y en a eu qu’une, les autres mises à jour ont été considérées comme des « bug fix », donc gratuites).
Le plugin carddav_plus  coûte 6 crédits (soit 6€) avec des mises à jour entre 3€ et 1€.
La liste des tarifs est disponible ici.

J’avoue avoir pas mal hésité, mais en voyant le nombre de téléchargement, un support plutôt réactif et un maintient constant des plugins, je me suis décidé de leur laisser une chance.

Personnellement j’ai préféré prendre le pluging carddav chez eux, mais pour limiter les frais, vous pouvez très bien ne prendre que le calendrier et utiliser plugin carddav cité plus haut.

Pour l’installation et le téléchargement des plugins, il faut forcément passer par leur « plugin_manager » qui va prendre la main sur la gestion des plugins au sein de Roundcube. Pour les explications et la documentation d’installation c’est par ici que ça se passe.

Pour les différentes URL (CalDAV et CardDAV) à renseigner lors de la configuration de ces plugins, je vous conseille de faire un tour sur l’article très complet d’Idleman.
Il vous servira aussi pour configurer la synchronisation de votre téléphone.

Synchronisons !

Votre webmail est maintenant complet, quoi de mieux que de retrouver tout ça sur votre téléphone ?

Pour synchroniser ses mails, vous pouvez utiliser le client mail fourni de base avec d’Android, ou K-9.
K-9 est plus complet, et est hautement configurable (parfois limite trop).

Pour la synchronisation (dans les deux sens) des contacts et des calendriers, deux choix s’offrent à vous :

  • Davdroid : une seule application pour tout synchroniser, mais payante (2.99 €)
  • Le couple Caldav-Sync (2.59 €) & CardDAV-Sync free.
    Attention à ne pas confondre avec Caldav Sync Free Beta qui n’est pas du même auteur et qui – pour le moment – ne propose que la synchronisation dans un seul sens.
    Pour supporter et encourager le développeur, je vous invite grandement à installer la version payante de CardDAV-Sync une fois la version gratuite prise en main.

Avec ces applications, vos contacts et calendriers seront intégrés dans votre Android tout comme avec votre compte Google.

Quelques réflexions…

J’ai vraiment été surpris du peu d’implémentation sérieuses (et maintenus) de CalDAV/CardDAV, je vous invite à faire un tour sur la page Wiki dédiée, vous verrez que ce n’est pas folichon… Est-ce un manque d’intérêt de la part de la communauté ?

Peut-être est-ce dû à la complexité du protocole, vu les nombreux RFC gravitant autour, ça peut en rebuter plus d’un…
Heureusement une librairie PHP existe : SabreDav.
Owncloud et Baïkal (entres autres) se reposent dessus. J’espère que dans le futur on verra plus de projets basés dessus :)

 

Au prochain épisode : on migrera vos données Google vers votre installation et se penchera sur le côté « backup » de la chose.

A+ sous l’bus Google – Partie 3

Et voici la troisième partie de ce tutoriel ! Aujourd’hui on va parler de XMPP et améliorer notre spamassassin :)

XMPP sans ta mère

Partir de Google, cela signifie partir aussi de Gtalk et surtout d’Hangout.

Comme annoncé lors de la sortie de Hangout, celui-ci ne supportera plus XMPP… Encore une preuve du renfermement de ces géants du web… un repli sur soit même entraînant ses utilisateurs dans de bien belles prisons dorées (même remarque pour Microsoft – Skype, Facebook, Twitter, …).
Utilisons donc un protocole respectueux des principes d’Internet : XMPP.

XMPP, c’est un peu le « SMTP » de la messagerie instantanée. C’est un protocole décentralisé et son fonctionnement ressemblent à celui du mail.
Un client XMPP ne va pas directement parler à un autre client, il va passer par son serveur d’appartenance, qui va : soit établir une session sur le serveur distant et transmettre le message, soit transmettre le message au client s’il appartient au même serveur.

Il y a donc deux types de connexion possible en XMPP : c2s (client to serveur) et s2s (server to server).

Comme une adresse XMPP est de la même forme qu’une adresse mail, il est possible de n’utiliser qu’une seule et même adresse pour les protocoles XMPP et SMTP (tout comme les adresses en @gmail, @hotmail, etc)… On ne va pas de gêner² :)

Ejabberd

Ejabberd, c’est un serveur XMPP. Il est plutôt facile à configurer et – bonne nouvelle – un tuto existe (backup ici) pour l’intégrer avec le LDAP d’IredMail.

Suivez-le, il est assez simple, et tout est bien expliqué, même pour l’éventuel séance de debugging.

Une fois que votre Ejabberd est prêt, vous pouvez commander à l’utiliser avec n’importe quel client compatible XMPP tel que Pidgin ou Xabber sur Android.

DNS

Eh oui, une fois n’est pas coutume, il va falloir faire un peu de configuration DNS.

Vous avez vu dans la partie 2, les records MX spécifiques au mail ainsi que les records TXT (pour le SPF ou le DKIM). Ici on va avoir besoin de records SRV pour annoncer votre serveur XMPP ainsi que ses ports d’écoute. XMPP comporte deux types de connections : C2S (Client to Client) et S2S (Server to Server), il va donc falloir deux records, la nomenclature est la suivante :

_service._proto.name TTL class SRV priority weight port target

Pas d’affolement ça va bien se passer, décomposons tranquillement :)

  • _service => défini le type de connection (S2S ou C2S)
  • _proto => tcp ou udp
  • name => votre domaine XMPP
  • TTL class SRV priority => ici rien de nouveau par rapport à un record « classique »
  • weight => permet d’ajouter un poids entre record avec une priorité égale (pourquoi pas..)
  • port => le port d’écoute de votre serveur correspondant au type de connexion
  • target => soit l’IP, soit le DNS de votre serveur XMPP

Voilà, rien de méchant. Pour un exemple pratique voici la configuration chez roflcopter.fr :

_xmpp-client._tcp.roflcopter.fr 120 IN SRV 0 100 5222 xmpp.roflcopter.fr
_xmpp-server._tcp.roflcopter.fr 120 IN SRV 0 100 5269 xmpp.roflcopter.fr

 

Plus d’info sur la configuration DNS spécifique à XMPP ici.

Jappix

Un client lourd c’est pratique sur son PC perso, par contre quand on est en déplacement ou que l’on a pas son PC sous la main, un client web peut dépanner.

Le client web XMPP le plus abouti à ce jour est Jappix ! Il propose une belle interface, il est plutôt réactif et facile à mettre en place. Vous pouvez le tester ici : https://jappix.com/ Si vous voulez le tester avec votre domaine, assurez vous que vous avez bien suivi la partie sur les DNS et que la configuration s’est bien propagée.

Il est possible (et même recommandé) d’en installer une instance chez vous. La doc d’installation est plutôt complète : https://github.com/jappix/jappix/wiki Vous retrouverez dans les différents points la configuration à appliquer sur votre serveur ejabberd.

 

Et voilà ! Vous avez maintenant de quoi chatter avec vos amis ;)

 

Enlarge your spamassassin

Si vous avez commencé à utiliser votre nouvelle messagerie et rendu votre mail plus ou moins publique un riche héritier africain a déjà dû vous contacter :)
Pour peu que ce soit bien écrit (aussi bien au niveau du contenu qu’au niveau du contenant), et que le mail utilisé ne soit pas encore publié dans une myriade de blacklist votre spamassassin n’y aura vu que du feu ! Résultat, le mail tombe comme un cheveu dans votre Inbox.

De rage, vous vous empressez de classer ce vilain mail dans le dossier Spam, en espérant que ça lui serve de leçon ! Le lendemain : rebelote ! Le margoulin réitère et son mail trône dans votre belle Inbox…
Mais il n’apprend donc jamais rien ce spamassasin ?
Eh bien non ! Un mail classé comme spam, n’aura que seul effet de le classer dans le dossier « spam ». Spamassassin n’en saura jamais rien et n’apprendra pas de ses erreurs…

Il existe cependant une solution : les filtres bayésiens. Grace à cela, spamassassin va se baser sur des « tokens », une occurrence de mots ou de courtes phrases identifiés comme pouvant faire parti du contenu d’un spam.

Et double cerises sur le gâteau, il existe un plugin pour Roundcube qui automatise l’apprentissage quand on classe un mail comme spam ET un tuto (backup ici) pour le mettre en place sur Iredmail !

Petit conseil, une fois le tuto suivi et l’apprentissage validé (voir fin du tuto), passez à la moulinette vos anciens mails de spam via la commande suivante :

sa-learn --showdots --spam /var/vmail/vmail1/<path_de_votre_maildir>/Maildir/.Junk/
.....................................................................................................................................................
Learned tokens from 67 message(s) (149 message(s) examined)

Les filtres bayésiens de reposent essentiellement sur des probas. Plus vous les nourrirez et plus ils seront efficace ! De plus, la base est partagée, donc tous vos utilisateurs participeront à l’élimination du spam sur votre serveur mail :)
Attention cependant de ne pas classer en spam n’importe quoi !

Pour poussez la lutte encore plus loin, vous pouvez aussi utiliser des services collaboratifs externes comme le combo Razor et Pyzor (backup ici). Ils s’installent assez facilement.

 

Voilà, maintenant vous avez votre propre service XMPP, les outils pour y accéder et votre spamassassin a gagné des muscles.

La suite au prochain épisode, au programme : Caldav / Carddav !

Configurer une IPv6 statique sur un serveur dédié Online

Voici un rapide tuto pour ceux qui veulent une configuration IPv6 simple, rapide et fonctionnelle pour leur serveur dédié chez Online. C’est à dire sans utiliser dibbler…

Depuis quelques temps Online annonce la migration l’infrastructure IPv6 vers leur nouveau range : 2001:bc8::/32. Enfin quand je dis annoncer … oui c’était marqué à la sauvette sur Twitter, on en parlait sur leur forum, voire peut-être même sur leur serveur IRC. Mais tous les clients d’Online ne suivent pas ces canaux de communications.

Aujourd’hui Online a annoncé la migration forcée des anciennes IP vers le nouveau range… drôle de surprise pour ceux qui n’étaient pas au courant…

Avant, toute IP failover en IPv4 été automatiquement associée avec une IPv6. Maintenant ce n’est plus le cas, il faut faire autrement… En suivant leur tuto et les réactions sur le forum, on s’aperçoit vite que dibbler c’est pas sec du tout (seg fault, instabilité et tout le toutim).  Moi tout ce que je veux c’est une IPv6 pour mes VM, rien de plus.

Heureusement, ya une méthode très simple et qui s’affranchit de dibbler.

Premier truc, il faut découper votre /48 et pour ça ya un tuto.

Ensuite pour chaque machine, j’ai décidé d’utiliser la première IP dispo, càd :
2001:bc8:</48_client>:</56_machine>:</64_VM>::1

Ca c’est dans le cas d’une VM. Si vous n’avez pas de VM appuyez sur #3, il faut simplement utiliser la première IP  du /56 :
2001:bc8:</48_client>:</56_machine>::1

N’utilisez pas directement votre /48, si vous n’avez qu’une seule machine, car il est associé à votre compte client et vous n’en aurez qu’un ! Il faut donc le découper intelligemment dès le début :)

Ensuite, rendez-vous dans le fichier /etc/network/interface, et rajoutez les lignes suivantes : 

iface eth0 inet6 static
address 2001:bc8:</48_client>:</56_machine>:</64_VM>::1
netmask 64
accept_ra 1
pre-up dhclient -cf /etc/dhcp/dhclient6.conf -pf /run/dhclient6.eth0.pid -6 -P eth0
pre-down dhclient -x -pf /run/dhclient6.eth0.pid

eth0 ou autre, adaptez selon le nom de votre interface externe.

Il faut ensuite créer le fichier /etc/dhcp/dhclient6.conf

vi /etc/dhcp/dhclient6.conf

interface "eth0" {
send dhcp6.client-id <copiez ici le duid associé au bloc de l'IP>
request;
}

Encore une fois adaptez selon le nom de l’interface réseau.

Si vous aviez une ancienne IPv6 associée, il faut la désactiver :

systcl -w net.ipv6.conf.eth0.autoconf=0
echo "net.ipv6.conf.eth0.autoconf=0" >> /etc/sysctl.conf

 

Un p’tit service networking restart ou un reboot et ça ira ben.

Votre interface doit maintenant porter la nouvelle IPv6 :

ifconfig eth0
eth0 Link encap:Ethernet HWaddr 52:54:00:00:0f:58
inet adr:x.x.x.x Bcast:x.x.x.x Masque:255.255.255.255
adr inet6: fe80::5054:ff:fe00:f58/64 Scope:Lien
adr inet6: 2001:bc8:</48_client>:</56_machine>:</64_VM>::1/64 Scope:Global

Et on vérifie qu’Online nous a bien filé la route :

route -6 | grep eth0
2001:bc8:</48_client>:</56_machine>:</64_VM> :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 fe80::c671:feff:fef1:bcff UGDAe 1024 0 0 eth0 <= YEAH \o/
ff00::/8 :: U 256 0 0 eth0

Et qu’on arrive à joindre l’extérieur (vérifiez votre ip6tables avant) :

ping6 wtf.roflcopter.fr

PING wtf.roflcopter.Fr(wtf.roflocpter.fr) 56 data bytes
64 bytes from wtf.roflocpter.fr: icmp_seq=1 ttl=63 time=0.250 ms
64 bytes from wtf.roflocpter.fr: icmp_seq=2 ttl=63 time=0.381 ms
64 bytes from wtf.roflocpter.fr: icmp_seq=3 ttl=63 time=0.411 ms
64 bytes from wtf.roflocpter.fr: icmp_seq=4 ttl=63 time=0.245 ms
64 bytes from wtf.roflocpter.fr: icmp_seq=5 ttl=63 time=0.296 ms

Et voilà tout fonctionne bien !

N’oubliez pas de mettre à jour votre ip6tables, sinon vous serez à poil sur le netv6 :)

Visite du radiotélescope de Nançay

banniere-patrimoine-2013

Le week-end du 14-15 septembre se déroulaient les journées du patrimoine et le CNRS était de la partie en ouvrant l’accès à plusieurs observatoires et équipements, dont le radiotélescope de Nançay (4ème plus gros radiotélescope au monde !)

L’occasion n’était pas à louper, depuis le temps que je rêvais d’en visiter un… Voici donc un court reportage couvrant ce que j’ai pu découvrir lors d’un après-midi.

Les images sont cliquables et je vous encourage à visiter les différents liens présent au fil de l’article afin d’étayer les différentes partie de l’article.

Continuer la lecture de Visite du radiotélescope de Nançay

A+ sous l’bus Google – Partie 2

Les articles qui vont suivre ne sont pas des tutos à par entière, disons que c’est plus une marche à suivre. Je vais essayer d’être le plus indicatif possible mais je vais sûrement zapper des choses. Si un truc n’est pas clair, faites le savoir dans les commentaires et j’essaierai de compléter l’article !

 

Le serveur mail

La première chose à faire c’est – sans surprise – installer un serveur de mail. Perso avant de me lancer dans ce projet j’avais une fois touché à Postfix/MySQL avec des virtual mailbox pour faire des simples redirections mails. Autant dire que je partais de loin…

Tout ce que je savais c’est qu’il faut :

  • un MTA,
  • un spamassassin : impossible de faire sans maintenant,
  • un clamav : histoire de faire le tri dans les facture.exe (ou pas),
  • et un dovecot pour l’accès IMAP/POP3.

Voici un schéma qui résume comment tout ça est embranché :

how-postfix-dovecot-amavis-clamav-and-spamassassin-work-postfix-the-bigpicture

  1. Un mail est reçu par Postfix,
  2. Après vérification de l’expéditeur (blacklist, authentification si nécessaire, greylisting,…) il est esnuite envoyé à Amavis pour une analyse de son contenu,
  3. SpamAssasin vérifie via ses filtres si on ne vous demande pas d’augmenter la taille de votre organe reproducteur,
  4. ClamAV jette un coup d’oeil aux pièces jointes,
  5. Le mail est renvoyé à Postfix…
  6. … qui se fait un plaisir de demander à Dovecot de le ranger au bon endroit
  7. Dovecot vérifie l’état du quota de l’utilisateur, et analyse les règles de filtrage de l’utilisateur afin de prendre une décision sur l’action à faire (stockage dans le bon dossier ou renvoi du mail),
  8. L’utilisateur s’authentifie auprès de Dovecot en IMAP ou POP3 afin d’accéder au mail.

Sans réelle connaissance et vu que le temps pressait (rapport à l’affaire Prism) j’ai donc décidé de partir sur une solution clé en main et d’apprendre sur le tas.

Continuer la lecture de A+ sous l’bus Google – Partie 2

A+ sous l’bus Google – Partie 1

Préambule

Ça faisait 9 ans que j’hébergeais mes mails chez Google et avant cela c’était chez Hotmail et encore avant… eh bien je n’avais tout simplement pas Internet, donc pas d’adresse email.

C’est au fur et à mesure que j’ai commencé à me « dé-google-iser », grâce à l’auto-hébergement que je pratique depuis quelques années. J’ai commencé par remplacer des services non critiques et depuis quelques mois il ne me restait plus que les gros morceaux : les mails, les contacts et les calendriers.

Je n’ai pas connu l’hébergement des mails à la maison,  je crois que c’est un peu pour ça que j’ai attendu aussi longtemps. Je voyais ça aussi haut qu’une montagne et je ne savais pas trop par où commencer, par contre j’avais un besoin bien défini.

Une chose est sûre, en 9 ans de Gmail  je ne me suis jamais posé la question en me connectant si tout allait bien fonctionner, si mes mails/contact/calendriers étaient toujours là… La force de Google c’est son système « plug’n play » disponible quasiment h24, la barre est haute….

  • Bon, je crois que c’est illusoire de vouloir créer  une solution avec une disponibilité aussi haute que Google, par contre il faut quelque chose d’assez résilient.
  • Côté intégration, encore une fois Google a réussi un sacré pari : mails, contacts, calendriers, chats, … tout ces services fonctionnent ensemble et sont inter-opérables. Il faudrait donc au moins quelque chose dans ce genre, une interface intégrant les mails, contacts, calendrier et pourquoi pas un système de chat. Retrouver ses contacts en auto-completion lors de la rédaction des mails, etc.
  • L’ergonomie :  je veux bien me passer de Google et de son interface plutôt ergonomique, mais pas question de pleurer du sang. Il faut une interface agréable à utiliser.
  • Authentification unique ! Un seul login et mot de passe pour s’authentifier auprès des services. C’est quand même plus propre, plus agréable à gérer et à utiliser au quotidien.
  • Utiliser des protocoles ouverts, idéalement : XMPP, Caldav, Carddav.

Partant de tout ça, j’ai commencer à débroussailler le net à la recherche de la meilleure solution…

C’est après quelques semaines de tests, de sueur, de rage et de joie que je pense avoir réussi à monter quelque chose qui tient la route. Dans les articles suivant on rentrera dans le vif du sujet :)