J’utilise Alpine donc. Je suis, vous vous en doutez, très satisfait de ce logiciel d’une stabilité à toute épreuve qui gère mes boites mail fournies de centaines de milliers de mails (1997 – 2012) comme si elles en contenaient 12. Mais Alpine souffre d’un problème millénaire: sa -non- gestion des RFC 2015/3156 i.e. les messages multipart/signed et multipart/encrypted. En effet, Alpine, comme nombre d’autres MUA ne respectant pas cette RFC, signe ou chiffre via PGP/GPG dans le corps du message, par le biais d’outils tiers tels que pinepgp ou pine-pgp-filters.

Bien que ce fonctionnement ne soit pas fondamentalement gênant, il m’est pénible de sauvegarder un message que l’on m’aurait envoyé chiffré afin de visualiser son contenu via gpg -d. Cela m’empêche, en outre, de simplement pouvoir [r]épondre à un mail chiffré.

Il existe quelques solutions faiblement efficaces, ou encore des usines à gaz dont j’ai abandonné le packaging tellement elles me semblaient bancales, mais globalement, rien de simplement satisfaisant.

J’ai donc décidé d’orienter ma recherche autour d’un filtre procmail, mon MDA.

Pas de solution prémachée, mais quelques boûts à traffiquer un minimum afin d’obtenir le résultat suivant: lorsque l’on reçoit un email de type multipart/encrypted, on déplie l’attachement (le contenu crypté donc) et l’incrustons dans le corps du message. C’est pas propre-propre, mais ça fait son taf.

Pour ce faire, j’ai utilisé les recettes de monsieur pi, et surtout cet exemple d’utilisation de MIME::Parser. Ainsi, j’ai modifié le script en question, le résultat est disponible ici, et placé la règle suivante dans mon ~/.procmailrc:

:0
* ^Content-Type:.*multipart/encrypted
{
        :0c:
        $HOME/mail/pgp_backup
        :0fw
        | $HOME/bin/mimedecode.pl
}

J’attendrai d’avoir beaucoup plus d’alcool dans le sang pour m’attaquer à mail/topal…

Alpine a des avantages, mais aussi beaucoup d’inconvénients, et l’un d’entre eux, c’est la manière dont il “gère” la validité des certificats TLS/SSL.

Jusqu’à présent, la flemme m’avait poussé à renseigner mes accès IMAP de cette façon :

$ grep novalidate .pinerc
inbox-path={mon.serveur.imap/ssl/novalidate-cert}inbox

De façon à ne plus voir le fameux warning me signifiant que le certificat du serveur IMAP auquel je souhaite me connecter n’est pas valide, blah blah blah. Et puis cette fois j’ai voulu faire les choses bien. En fouillant un peu, je suis tombé sur cette excellente documentation qui explique le pourquoi du comment, mais surtout le “comment”.

Voici donc en résumé la marche à suivre.

Vous aurez besoin, pour satisfaire alpine :

• Du root-certificate duquel est issu votre certificat serveur
• Du certificat serveur en question

J’utilise depuis quelques temps les services de CACert plutôt que d’auto-signer mes certificats. C’est peut-être dérisoire, mais je trouve ça plus sérieux.

La première étape consiste en la découverte du répertoire par défaut ou OpenSSL cherche les certificats. On obtient cette information avec la commande suivante :

$ openssl version -d
OPENSSLDIR: "/etc/openssl"

Pour moi, donc, ce sera /etc/openssl.

Là ou ça devient rigolo, c’est qu’aucune directive de configuration du .pinerc ne permet de définir un nom de fichier correspondant aux certificats. Non. À l’Université de Washington, ils préfèrent chercher ces derniers sous forme de hash, c’est tellement plus convivial. Heureusement, dans la documentation précédemment citée, Paul Heinlein a déblayé le terrain et nous explique qu’on obtient ce hash à l’aide de la commande openssl x509 -in certificat.pem -hash -noout.

Ainsi, il “suffit” de copier votre certificat racine et le certificat serveur avec leurs noms sous la forme du hash obtenu… suffixé par “.0″. Demandez pas.

Ce qui nous donne :

$ openssl x509 -in cacert-root.pem  -hash -noout
5ed36f99
$ openssl x509 -in cert_serveur.pem  -hash -noout
aaf089ef8

Puis

$ sudo cp cacert-root.pem /etc/openssl/certs/5ed36f99.0
$ sudo cp cert_serveur.pem  /etc/openssl/certs/aaf089ef8.0

Bin croyez-le ou non: ça marche.