Les e-mails c’est bien, mangez-en !

Article écrit par Eddie Barraco

Les mails, c’est compliqué.

Tous ceux qui ont un jour mis la main à la pâte pour mettre en place leur solution le savent.

Les mails, en gros, ça ressemble à ça :

+---------+  SMTP  +---+   +---+               +----------------+ |Other MTA| <----> |MTA| --|MDA|-> Storage <-- |POP3/IMAP server| +---------+        +---+   +---+               +----------------+                      ^                                 ^                      |     SMTP    +---+               |                      +-------------|MUA|---------------+                                    +---+ 

Pour rappel :

• MTA (Mail Transfer Agent): Serveur servant de relais aux mails
• MDA (Mail Delivery Agent): Programme qui livre les mails dans les boites mails
• MUA (Mail User Agent): Le client pour accéder aux mails
• SMTP (Simple Mail Transfer Protocol): Protocole de transfert des mails
• POP3 (Post Office Protocol): Protocole pour récupérer les mails
• IMAP (Internet Message Access Protocol): Protocol pour accéder aux mails

Rien que ça, c’est compliqué. Et pourtant c’est loin d’être fini. Si on veut vraiment rentrer dans les détails il faut parler des différents outils annexes. La gestion des mailboxes avec des outils admin comme postfixadmin. La détection des spams avec des joyeusetés comme SpamAssassin. Le fait que chacun de ces outils communique avec les autres comme cela lui chante. Des fois c’est par socket, des fois c’est par fichier, des fois c’est par API. C’est la galère à configurer et on ne peut pas vraiment conteneuriser les différents composants de manière élégante.

En bref, les mails, c’est compliqué.

Pourtant les mails ont beaucoup de vertus. Si si, je vous jure ! Laissez-moi vous montrer.

Pas si compliqué que ça

Pour nuancer mon introduction, rappelons ce qu’est un mail concrètement.

La RFC 5322 – Internet Message Format définit la syntaxe des messages textuels qui sont envoyés entre les utilisateurs d’ordinateurs. Le premier exemple proposé est celui-ci :

---- From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example>  This is a message just to say hello. So, "Hello". ---- 

Derrière il y a bien sûr quelques autres RFC pour permettre de s’envoyer du contenu additionnels comme des fichiers binaires. Mais ce n’est pas vraiment le propos ici. Un mail, c’est un fichier qui contient du texte. Les méta-informations sont dans des headers sous la forme Mon-Header: Foo Bar. Et c’est marre !

Envoyer un mail peut se résumer à ça !

~$ cat | msmtp contact@synbioz.com From: contact@eddiebarraco.fr Subject: J'aime trop ce que vous faites !  Super votre dernier article sur les mails ! Vous avez changé ma vision du monde. Merci ^D 

Alors petite parenthèse, laissez le HTML aux commerciaux. Utilisez du texte brut. Voyez cette page pour plus d’informations.

On peut écrire un mail avec n’importe quel éditeur et l’afficher avec n’importe quelle interface. Ça ne pèse presque rien et on peut le chiffrer, le compresser.

Un découpage par responsabilité

Vous vous rappelez du schéma ? Si si, celui tout en haut de cette page ! Eh bien moi non. Enfin, je sais où le trouver quand j’en ai besoin.

Ils sont fous ces développeurs de l’ancien temps. Pourquoi ils n’ont pas fait plus simple ?

Parce que si les mails c’était plus simple, ça aurait disparu depuis longtemps. Comment je le sais ? Parce que ça s’est déjà produit. Remémorons-nous certains de nos vieux démons.

Quand l’outil devient trop gros, trop lourd ; quand il devient coûteux de le maintenir ; quand la dernière techno ou le dernier framework qui casse la baraque vient de sortir : tu jettes ton outil et tu en prends un autre, un mieux.

C’est terrible, c’est affreux, mais c’est comme ça.

Mais c’est horrible ! Comment on fait pour qu’un outil perdure ?

On le laisse un peu tranquille ! On essaie de ne pas ajouter la petite fonctionnalité qui va bien. On garde quelque chose de simple.

Ça d’accord. Mais surtout, on sépare les responsabilités. On crée plusieurs outils qui travaillent ensemble. On sépare le système en briques qui s’imbriquent. Ainsi, on peut interchanger ces briques dès qu’elles vieillissent ou pourrissent. On peut construire de nouvelles briques avec des matériaux plus récents. On peut retirer des petites briques sans que toute la structure ne s’effondre.

Et on peut aller encore plus loin ! On peut avoir plusieurs briques qui font la même chose (il a viré de la cafetière). On évitera de construire un château-fort de Lego qui peut s’effondrer au moindre défaut. Surtout quand on ne s’appelle pas Google et qu’on n’a pas les ressources pour étendre son application à l’infini.

L’approche de la fédération permet une richesse dans les implémentations et une robustesse inégalable avec une approche monolithique. Chaque bloc fait quelque chose de très simple. Et Monsieur tout le monde peut le maintenir.

Un système parfaitement fédéré

Je veux t’envoyer un message. Tu es chez qui déjà ? Google, Outlook ? Tu utilises quoi comme client ? Ah non, en fait, je m’en fiche. Donne-moi juste ton adresse.

À ce jour, les projets mettant en avant l’interopérabilité fleurissent de partout. ActivityPub, entre autres, permet aujourd’hui de faire communiquer des plateformes de vidéos, des réseaux sociaux comme Pleroma ou Mastodon, des plateformes de musique et bien d’autres pépites du Fediverse. Chaque nœud, peu importe sa nature, peut communiquer avec l’ensemble des autres. Un système d’adressage très simple permet d’identifier une ressource : joueur.du.balcon@peertube.de.g4m3r. Hé mais attendez une petite seconde. Ça me rappelle bien quelque chose…

Bon, malgré cela, force est de constater que l’on continue d’utiliser plusieurs outils de communication (Messager, QuelleApp, que sais-je ?).

Pourtant on oublie vite que cela fait déjà bien longtemps qu’on n’a plus besoin d’être sur le même service pour se parler. L’envoi de mail fonctionne sur n’importe quelle implémentation qui répond aux normes et aux protocoles.

Il y a une infinité de clients existants. Vous trouverez toujours chaussure à votre pied. Que vous soyez un ermite coincé dans un terminal ou Joe le rigolo qui consulte ses mails sur Yahoo.

Les mailing lists

C’est bien gentil de s’envoyer des noms d’oiseaux, mais comment on fait quand on veut insulter tout un groupe de personnes ?

Bon déjà on peut envoyer un mail à plusieurs personnes. Ça j’espère ne pas vous l’apprendre. Mais on peut faire encore mieux ! On peut envoyer des mails à des gens qu’on ne connait pas. On utilise pour cela des mailing lists.

Une mailing list est juste un intermédiaire automatique qui reçoit des mails et les fait suivre à une liste d’autres adresses. On peut s’y inscrire en envoyant simplement un mail ou en passant par des interfaces web.

Finalement :

• Il n’y a techniquement aucune différence entre une mailing list et un groupe Facebook par exemple. N’importe qui peut poster un message et toute une communauté reçoit ledit message. N’importe qui peut y répondre (laisser un commentaire) et les réponses sont redistribuées aux autres personnes.
• Il n’y a techniquement aucune différence entre une mailing list et un salon de discussion Messenger par exemple. N’importe qui peut poster un message et toute une communauté reçoit ledit message. N’importe qui peut filer la discussion à l’infini.

Ce que j’essaie d’expliquer, c’est que le concept est si basique, si trivial, qu’on peut en faire ce qu’on veut.

Thread infini

Vous aussi, vous avez des groupes d’amis qui papotent des nuits entières sur Messenger ? Vous vous réveillez le matin et vous constatez avec effroi que jamais, jamais vous n’arriverez à lier les deux bouts. Les sujets s’entrecroisent et parfois les gens répondent à plusieurs messages, en même temps. Vous ne savez plus où donner de la tête !

Certains services de chat ont bien tenté de trouver des solutions. Sur Slack notamment, il est possible d’ouvrir un fil de discussion sur un message. Un nouveau chat vide fait son apparition et on peut s’empresser de lui faire sa peau à son tour. Cependant que se passe-t-il lorsqu’on veut thread une fois de plus ? Ahem…

Pour revenir à notre sujet de base, les mails. Ceux-ci peuvent être en réponse à un autre mail via un simple en-tête. Et non, ce n’est pas le sujet du mail qui définit son parent.

In-Reply-To: <20200115143316.o7qzvulcfzbrk6vb@green-medusa.misterbanal.net> 

Du coup, c’est la threadception. On peut se permettre de diverger dans tous les sens.

3752   + Dec 13 EXX FX ( 27K)     ┌*> 3753 r + Dec 10 EXX FX ( 21K)   ┌─>Je trouve que les gens sont trop durs en général 3754   + Dec 06 EXX FX ( 21K) ┌*┴─> 3755 r + Dec 06 EXX FX ( 17K) Votre candidature poste de Développeur Full Stack 

ou plus complexe

3408     Mar 08 SXXXXXXX DXXXXX ( 11K) ┌─> 3409     Mar 10 LXX DXXXX       (2.4K) │           ┌─>Recap? 3410     Mar 09 DXXXX M         ( 38K) │         ┌─> 3411     Mar 09 Mailing Chatons (9.9K) │       ┌─> 3412  s  Mar 09 SVNET Brique In ( 12K) │       ├─> 3413  s  Mar 09 SVNET Brique In ( 11K) │     ┌─> 3414     Mar 09 BXXXXXXX MXXXX- ( 35K) │   ┌─>Bon, j'avoue que j'ai décoché 3415     Mar 09 JXXXXX AXXXX    ( 25K) │ ┌─>Vous suivez toujours ? 3416     Mar 09 Mailing Chatons (985K) │ │ ┌─> 3417     Mar 09 MXXXXXXX        ( 17K) │ ├─> 3418   F Mar 09 To chatons@fram (9.6K) │ │   ┌─> 3419 r   Mar 09 Super Linuxien  ( 20K) │ │ ┌─>Mac, n'importe quoi... 3419 r   Mar 09 gestionnaire@le ( 20K) │ │ ├─>J'avoue 3420     Mar 08 Henri Fontaine  ( 25K) ├─┴─>Et si on passait sous Mac ? 3421     Mar 05 MXXXXXXX        (1.1K) [chatons] Matériel et logistique 

Quoi t’appelles ça pratique ?

Cette possibilité a une prérogative : encore faut-il savoir s’en servir ! Quand vous répondez à un message, citez ce à quoi vous faites référence. On ne doit pas avoir besoin de remonter toute la chaine pour comprendre de quoi vous parlez.

En clair, les communications forment un arbre où chaque sous-discussion suit une organisation. Le sujet peut évoluer et malgré tout, on comprend toujours d’où on part.

Enfin, ça c’est quand on utilise les bons outils. Avançons !

Et du coup ?

Bon on récapitule le tout. Un mail c’est du texte, c’est simple, C’est un message qui s’inscrit dans une chaine d’autres messages. Ça notifie des choses qu’on rate. Ça nous permet d’échanger entre nous tout en restant structuré.

C’est une architecture décomposée en responsabilités. Il y a une infinité de possibilités pour recevoir, envoyer, transporter ou consulter un mail. C’est une logique décentralisée, libre et anarchique.

Bref, ça fait le café, et même la vaisselle !

Mais alors, c’est quoi le hic ? Pourquoi on ne base pas toutes nos communications dessus ? Pourquoi on a encore des douzaines d’applications de communication ?

Le vrai problème des mails

Il y a un souci majeur avec les mails. Et le pire, c’est que c’est même pas la faute des mails. Ce souci, ce sont les clients mails…

• La plupart des clients ne permettent pas de bien rendre les fils de discussion.
• La plupart des clients ne permettent pas de chiffrer les messages.
• La plupart des clients poussent l’utilisateur à top poster.
• La plupart des clients s’interconnectent mal (appliquer un patch git reçu par mail depuis Gmail…)
• La plupart des clients ne sont pas conçus pour gérer plusieurs boites mails en même temps.

J’utilise majoritairement Neomutt, dérivé de Mutt et dont le dicton est :

«All mail clients suck. This one just sucks less.»

— Michael Elkins, circa 1995

Ça promet… Pour avoir accès à toutes les possibilités qu’offrent les mails, il n’y a pas d’autres choix que de faire sa propre popote. Je vous présente ici ma stack. Attention les yeux !

• msmtp : client SMTP, il envoie les mails.
• offlineimap : Synchronisation des mails en local. Utile pour notmuch.
• notmuch : Indexation des mails, permet des recherches ultra-rapides dans l’ensemble des mails. There is not much mails…
• vim/neovim : Pour taper du texte, quoi de mieux finalement ?
• neomutt : UI finale. Il ne fait finalement rien lui-même. Il me permet de parcourir les boites, faire interface pour interroger notmuch, lancer vim pour composer, passer les mails à msmtp pour les envoyer. Un outil, pour tous les contrôler !

Oui, tout ça. Je sais. Par contre, j’ai la possibilité de changer un de ces outils en le remplaçant par un autre au besoin. Chacun d’eux est au moins un des meilleurs de sa catégorie. Et puis, quand je n’ai pas besoin de sortir l’artillerie lourde, j’ai toujours aerc sous la main.

On me dit dans l’oreillette que Thunderbird propose une assez bonne gestion des threads également. Après un court essai, et un tout petit peu de point and click dans les menus, on a effectivement un bon rendu de l’arbre des discussions. Avec les modules de calendrier, de contacts, et de chiffrage avec Enigmail, Thunderbird reste dans mon top trois des outils malgré son coût en ressources et son manque d’interopérabilité.

Les mails peuvent être utilisés d’une infinité de façons différentes, et ça dépend surtout du contexte. Imaginez un simple client mail qui, au lieu de vous afficher la boite d’entrée (inbox), vous liste les mails en les groupant par contact. Ça ce serait de l’innovation ! Ça c’est vendeur !

Ça ressemble drôlement à n’importe quel autre client de communication n’est-ce pas ? Finalement, tout ça, c’est juste une question d’interface. Il n’empêche que le mail, de par sa simplicité, reste un des moyens de communication les plus versatiles.