Email et désespoir

9 juillet 2024 ⋅ Retour à l'accueil du blog

Aujourd'hui, j'ai perdu des heures à préparer et configurer un serveur chez DigitalOcean pour au final m'apercevoir qu'ils bloquent l'envoi d'emails (port 25 filtré dans le pare-feu), sans aucune possibilité de demander une exception. L'épisode m'a remotivé à poster ici une râlerie cathartique sur l'email en général. (Pardonnez le style très ampoulé, mais je ne veux pas tout réécrire.)

L'email est l'un des systèmes les plus fondamentaux d'Internet, aussi fondamental que le Web. Or ce système est complètement pourri à la racine, si profondément que mon rêve ultime est de posséder une baguette magique qui me permettrait de le remplacer entièrement.

D'une certaine manière, c'est déjà ce qui se produit : nous avons migré en masse nos communications vers une foultitude de réseaux sociaux et divers services de messagerie instantanée, parmi lesquels figurent au premier rang SMS, Facebook, 𝕏, Instagram, Snapchat, Slack, Discord, iMessage, WhatsApp, Bluesky, Signal, Mastodon, dont beaucoup sont malheureusement aux mains d'entreprises comme Meta et Google d'une taille démesurée auxquelles le contrôle d'une bonne partie des communications sur la Terre confère un pouvoir carrément dangereux. Pourtant, l'email demeure à ce jour incontournable, non seulement en tant que moyen de communication universel, mais sert aussi parce que les adresses email servent d'identifiants. La meilleure preuve que Facebook n'a pas supplanté l'email, c'est que si vous voulez modifier votre mot de passe sur Facebook, le lien de réinitialisation vous sera envoyé… par email.

Les boîtes de réception inondées

Le problème numéro 1 de l'email, « l'éléphant dans la pièce », c'est que nous avons tous des boîtes mail envahies au point de devenir ingérables.

D'abord, envahies de spam en copieuses quantités. En général, la plus grosse partie de ce spam est déplacée hors de notre vue dans un dossier d'indésirables par un filtre automatique, ce qui est certes rudement utile mais induit un nouveau problème : qui n'a jamais écrit « Bonjour Machin, est-ce que tu as bien vu l'email important de Truc, regarde bien dans tes spams » ?

D'autre part, les emails légitimes que nous recevons ne sont pas en quantités moins effrayantes. Parmi ceux-là, la fraction d'emails qui nous intéressent réellement, par lesquels nous nous sentons concernés, est souvent faible. En face, une fraction hallucinante d'emails qui ne nous concernent que peu, parce que certaines personnes™ n'ont pas intégré qu'il fait partie de la politesse numérique de respecter le temps des autres en modérant la quantité d'informations de faible importance qu'on leur envoie, surtout de manière sporadique (plutôt que, par exemple, regroupées en une newsletter hebdomadaire). Par exemple, je reçois des centaines d'emails aux titres ronflants comme « Groupe de schéma directeur vie étudiante », « Participez à l'enquête pour créer l'événement santé qui vous parle » ou encore « Consultation de la communauté normalienne pour le choix du nom de la nouvelle plateforme Internet » qui donnent follement envie de les ouvrir. Malheureusement, l'email permettant d'envoyer facilement et quasi-gratuitement un message à un nombre googologique de personnes à la fois, il suffit de quelques acteurs qui s'assoient sur cette politesse pour infester nos boîtes mail.

Personnellement, ce qui me sauve est d'organiser ma boîte mail en dossiers dans lesquels les messages entrants sont classifiés automatiquement. Je vais loin : j'ai actuellement 129 dossiers et 885 règles de filtrage réparties en 114 filtres. Évidemment, tout le monde n'a pas l'envie ou l'idée de faire autant d'efforts. Le principe même des filtres de messages semble peu connu du grand public.

Face à ce tsunami, je vois dans mon entourage beaucoup de personnes qui ont abandonné l'idée de ne pas avoir plus de 1000 emails non lus. En conséquence, il est essentiellement impossible en envoyant un email de s'assurer que le destinataire, même s'il fait un certain effort pour traiter ses emails, le lira dans un délai raisonnable : soit que l'email ait été marqué comme spam, soit qu'il soit noyé dans une pile d'emails à perte de vue, soit qu'on ait mal tapé l'adresse, les raisons sont nombreuses pour que le destinataire ne mette jamais les yeux sur notre message, ou ne le fasse qu'un mois après le rendez-vous que nous voulions urgemment fixer.

À ce propos, lorsqu'on fait une faute de frappe sur une adresse mail, il n'y a aucune garantie qu'elle nous soit signalée. Le message typique « Mail delivery failed » peut arriver dans la minute, comme trois jours plus tard, comme tout simplement jamais. C'est la même chose avec les pièces jointes trop lourdes (sachant qu'il n'y a pas de moyen simple de savoir à l'avance quelle taille de pièces jointes va être acceptée par le serveur du destinataire).

Le HTML

Sur le plan technique, le format des emails est assez byzantin. Pour s'en convaincre, il suffit de regarder la quantité de code qu'il faut pour implémenter une bonne librairie de lecture des emails ou le nombre de RFC différentes qui le spécifient, et ce serait évidemment trop beau si les clients l'interprétaient tous de la même manière⁰. Mais la véritable plaie, en dehors du MIME qui forme le squelette du message, est le format du contenu lui-même, qui est ordinairement le HTML, c'est à dire le même langage que celui des pages Web. C'est catastrophique à de nombreux égards.

D'abord, si ce qu'on peut mettre dans un email est en théorie sensiblement la même chose que ce qu'on peut mettre sur une page Web, les clients d'email sont en pratique très différents des navigateurs Web, et nettement plus variés (ce qui n'est pas une mauvaise chose au vu de l'inquiétant monopole croissant de Google Chrome sur le Web). Autant le Web bénéficie d'efforts de standardisation titanesques (bien que ce soit un sujet épineux et très problématique en soi), autant les clients d'email interprètent le HTML et surtout les informations de style, le CSS, à des degrés divers et avec beaucoup de variations. Si l'on considère le degré de complexité inimaginable du Web, ce n'est guère surprenant. Je ne trouve pas très sain qu'il faille embarquer dans tout client email quelque chose d'aussi monstrueux qu'un moteur de rendu Web entier¹. De plus, un email qu'on reçoit n'est pas simplement fait pour être affiché, mais doit pouvoir être édité (à cause des citations), ce qui n'est pas un cas vraiment prévu par toutes ces spécifications du Web. Le résultat est que certains emails s'affichent mal sur certains clients, ce qui est la raison du lien « Si vous ne voyez pas correctement cet email, cliquez ici » que nous avons tous déjà vu dans des emails de marketing. Dès que la mise en forme devient relativement complexe, il devient essentiellement impossible de s'assurer qu'elle marche sur à peu près tous les clients sans aller tester chaque client, et bien sûr, on ne teste généralement que les plus utilisés, donc les clients moins utilisés se retrouvent défavorisés.

Il y aurait aussi beaucoup à dire sur la sécurité du rendu Web, ou plutôt l'absence de sécurité, étant donné que cette complexité d'implémentation crée bien sûr des vulnérabilités par fournées entières. Il y a des choses “intéressantes” qu'on peut faire avec le CSS, comme mettre du contenu qui change quand le mail est transféré. Franchement, ce qui m'étonne n'est pas cette vulnérabilité, c'est le fait que personne ne lui ait donné un nom plus tôt, car c'est pathétiquement évident. De même, je suis surpris de ne pas trouver un nom pour l'attaque évidente consistant à afficher du texte dans une police où les glyphes pour chaque lettre correspondent à une autre lettre, de sorte que le texte « abcdefghijkl » passerait un filtre spam mais serait rendu comme « Mot de passe » à l'écran du destinataire.

Mais ce qui est peut-être le plus inquiétant avec le HTML est l'atteinte à la vie privée, et plus exactement le fait qu'on peut s'en servir pour savoir si vous avez lu un email. Pour cela, les marketeurs insèrent dans l'email un pixel espion, c'est à dire une image qui n'est pas envoyée avec l'email mais doit être récupérée par le client à une URL donnée sur le site de l'entreprise (<img src="https://...">). En mettant une URL unique dans chaque email envoyé, les marketeurs sont informés lorsque vous ouvrez l'email, puisque cela génère une requête sur leur site.

J'aurais aimé rester dans l'ignorance et penser que cette technique ne serait utilisée que par les entreprises les moins recommandables. Pour en avoir le cœur net, j'ai lu le premier résultat d'une recherche « Email marketing guide » sur Qwant et Google (c'était le même, à savoir ceci, d'ailleurs ce site lui-même va assez loin dans le genre How I experience Web today). Je lis :

Measure your results. This should come as no surprise. As marketers, we measure everything. Being meticulous about every key metric will help you make small changes to your emails, yielding large results. We're going to touch on the exact KPIs to monitor in a bit (or you can jump ahead).

Intéressant. En sélectionnant au hasard des emails dans ma propre messagerie, je constate qu'une majorité des emails non-personnels que je reçois contiennent des pixels espions, y compris certains par des entreprises que j'aurais crues plus responsables. J'en ai vu envoyés par : GitHub (commentaire laissé sur une PR), la SNCF (message d'informations sur une réservation), Trainline (idem, et je suis déçu), IONOS (promotion), Typst (promotion, là aussi je suis déçu), Steinberg (activation d'un compte), Microsoft (réponse sur un forum), Stych (changement de mot de passe), la MGEN (nouveau numéro de Valeurs mutualistes), Famileo (nouvelle gazette), la RATP (fermeture d'une ligne de métro), Discord (mise à jour des CGU). Le seul email où je n'ai pas trouvé de pixel espion alors que je m'y attendais plus ou moins venait de GitLab.

Certes, je peux comprendre que cela se justifie dans certains cas. Je veux bien croire que quand la RATP avertit de travaux qui conduisent à fermer une ligne très fréquentée du métro parisien pendant toute une semaine, elle veuille avoir une idée de la proportion d'usagers qui ont ouvert son email pour s'assurer que la majorité ont compris le message. C'est bien plus discutable dans le cas d'une promotion, où le but est de tester des techniques qui rendent les messages plus alléchants (or, justement, je ne veux pas de toutes ces promotions, comme l'immense majorité des gens, même si je ne vais pas m'étendre sur le sujet de la publicité car il faudrait des pages entières). Mais ce que je trouve le pire, c'est que cette collecte d'information se fait à l'insu de l'utilisateur. C'est très différent d'un accusé de réception qu'il faut confirmer explicitement avant de lire l'email. Avec les pixels espions, la plupart des gens n'ont absolument pas conscience de cette collecte d'information. Est-ce que tout ceci est vraiment normal ?

On peut se demander : à qui toute cette complexité profite-elle ? Je crois que c'est essentiellement à deux catégories (non cartésiennes), qui d'ailleurs peuvent se recouper, à savoir ceux qui envoient des emails de marketing alléchants, et les spammeurs. Les premiers font un usage immodéré de la mise en forme qui est certes utile, par exemple pour créer une cohérence entre un site Web et les emails qu'il envoie, mais va souvent dans l'excès d'effet visuel (ci-contre, un exemple que je trouve typique), et sert largement à espionner les utilisateurs (n'ayons pas peur du mot puisque, encore une fois, la plupart n'ont pas idée de cette technique). Quant aux spammeurs, il se servent du HTML pour déjouer les filtres anti-spam, qui doivent faire preuve d'une rude sophistication pour ne pas se laisser berner, par exemple, par du texte invisible, en taille de police zéro, qui sert à au filtre anti-spam autre chose que ce que voit le destinataire (chercher « zero font phishing »).

Où est le bénéfice pour l'utilisateur ? Il me semble bien faible.

Les utilisateurs se servent aussi de la mise en forme… souvent mal : pour des raisons que je ne comprends absolument pas (se donner un style ?), il est courant de changer la police dans laquelle on envoie ses messages (voire, encore bien pire, mais c'est beaucoup plus rare, de mettre tout le texte en bleu foncé ou en violet, ou de changer la couleur de fond²). Pour moi, c'est un mystère. Quel sens y a-t-il à changer la police de ses propres messages, alors que ce qu'on passe le plus de temps à lire, ce sont les messages des autres, qu'on aimerait bien voir dans la police qui nous convient le mieux ? Le pire, ce sont les copier-coller entre messages, qui donnent de joyeux mélanges de polices pénibles à corriger. La même chose s'applique à la taille du texte. Cela devrait évidemment être à celui qui reçoit le mail de choisir la police et la taille qui lui conviennent pour le lire. Il n'y a strictement aucune raison que l'expéditeur ait son mot là-dessus (sauf bien sûr s'il faut, par exemple, marquer une information importante en rouge, ce qui est différent).

Il existe aussi les emails envoyés au format « texte brut », c'est à dire, au lieu du HTML, un simple fichier de texte sans aucune mise en forme. Ce format est particulièrement répandu dans les milieux geeks, par exemple sur les de diffusion des projets de logiciels libres (dont certaines rejettent purement et simplement les messages en HTML, je crois comprendre que c'est le cas sur la LKML par exemple). À l'évidence, il est, cette fois, trop restrictif : autant les images distantes du HTML sont une perversion dans les emails, autant la mise en forme en italique ou en gras est essentielle dans la communication de tous les jours. Cela ne me pose personnellement aucun problème de lire et écrire avec les substituts comme *emphase*, _emphase_, /emphase/ et **emphase appuyée** qui sont couramment utilisés pour marquer cette mise en forme (je réponds généralement en texte brut à une personne qui m'écrit en texte brut, et je commence la conversation en texte brut ou non en fonction de la personne), mais il faut bien admettre que l'utilisateur de base non-geek apprécie moyennement.

Les pratiques de réponse variables

En parlant de texte brut, l'email est traversé par des guéguerres assez fatigantes entre les partisans du top posting et ceux du bottom posting. En règle générale, les clients email insèrent, dans la réponse à un message, une citation complète de l'original, et la question est de savoir s'il faut le faire à la fin (top posting) ou au début (bottom posting). Le top posting est de loin le plus courant, mais le bottom posting se pratique beaucoup, là aussi, dans les milieux geek (souvent par les mêmes qui sont partisans du texte brut, on peut le considérer comme un test de geekitude), où il est associé à la pratique consistant à répondre point par point au message d'origine, comme cet exemple inventé :

> The attached test file demonstrates a bug in the handling of signaling
> NaNs under the -ffast-math option.

This is intended behavior, see section 8.5.4 of the documentation.

> Curiously, it did not reproduce on an x86 machine.

Have you double-checked the compiler version? This may be caused by the change
that enabled -frounding-math on more configurations in v3.4.

Pour moi, le débat entre top posting et bottom posting est stérile parce qu'il n'y a pas de bonne option. C'est assez idiot, au fond, d'inclure tout le message auquel on répond³, mais beaucoup s'attendent à pouvoir voir les messages précédents en bas du mail, surtout si leur client mail n'offre pas de vue en conversation (avec tous les messages en une seule fenêtre). D'un autre côté, les réponses point par point, utilisées avec modération, sont aussi véritablement utiles quand la discussion porte sur plusieurs points indépendants. La vraie solution (mais personne n'en parle⁴) serait de ne simplement jamais inclure de citation sauf si on veut répondre à une partie spécifiquement, et dans ce cas de ne citer que la partie à laquelle on répond. Cette option n'étant jamais suivie, le résultat est souvent un joyeux mélange entre les deux styles qui rend la conversation difficile à suivre, sans compter les clients qui ne savent pas mettre en forme une citation correctement et qui copient juste le message d'origine sans l'indenter. Cela pourrit aussi la vie quand on veut, par exemple, permettre les réponses par mail sur un forum (c'est du vécu) : on ne sait jamais quelles parties conserver et quelles citations supprimer, vu que les clients et les utilisateurs ont des pratiques très hétéroclites.

Dans le même ordre d'idée, il y a les clients qui répondent avec Re: et ceux qui répondent avec Rép: (ou dans d'autres langues), il y a Fwd: et Tr:, il y a … (was: …) qui est pratiqué par certains mais n'est pas compris par tout le monde. Avec, bien sûr, les conversations dont le sujet devient Re: Rép: RE: Rép: Re: … parce que les clients s'y perdent.

On peut aussi penser à ceux qui mettent une image comme signature de tous leurs emails, ce qui alourdit chaque réponse dans une conversation avec des images redondantes (que les clients ne suppriment pas toujours des citations).

Le threading

Le threading est l'un de ces sujets qu'il suffit de mentionner sur Internet pour déclencher instantanément une guerre ouverte entre deux camps qui ne peuvent pas s'entendre. Je risque donc de me faire des ennemis en donnant mon avis, mais je vais le faire tout de même.

Si vous ne savez pas de quoi il s'agit, on dit que l'email permet le threading car une conversation email est arborescente : lorsque vous répondez, vous ne répondez pas à la conversation générale, vous répondez à un email en particulier, et les réponses forment un arbre qui grossit au fur et à mesure de la conversation (illustration ci-contre). On retrouve la même chose, par exemple, sur Mastodon, ou Twitter ou Facebook. Lorsqu'il n'y a pas de threading, la conversation est simplement chronologique, ce qui est le cas sur toutes les applications de messagerie instantanée.

Mon point de vue personnel est que le threading est supérieur à la conversation chronologique lorsqu'il s'agit de commentaires comme sur un réseau social, et qu'il n'y a pas spécialement de problème à ce qu'ils dévient du sujet d'origine. En revanche, je trouve qu'il est beaucoup plus difficile avec le threading d'arriver à une conclusion dans une discussion, et de se concentrer sur un sujet, donc il me semble que pour l'usage majoritairement personnel de l'email, le threading est malvenu (mieux vaut une conversation chronologique, avec usage raisonné de citations s'il faut répondre à un point précis).

Ce qui n'arrange pas les choses, c'est que pour simplifier la vue qu'ont leurs utilisateurs, certains clients comme GMail ignorent la structure arborescente et font comme s'il n'y avait pas de threading… ce qui ne facilite pas la vie de ceux dont le client mail prend en compte le threading, qui voient des réponses à une partie de la conversation apparaître dans une branche différente. Finalement, ce mélange est pire que si tout le monde était d'accord sur un mode de fonctionnement.

La sécurité déprimante

La sécurité des emails est complètement nulle.

Ce qu'ignorent 99% des Internautes, c'est qu'il est parfaitement possible, et même très facile, d'envoyer un email à n'importe qui en se faisant passer pour n'importe qui. Cela vient des protocoles email, qui ont été développés dans les tous premiers temps d'Internet, quand le réseau était structuré différemment — les messages circulaient de proche en proche — et alors que la question de la sécurité ne se posait pas encore.

Cas particulier : on peut très bien envoyer un email à l'adresse foo@bar.com qui semble provenir de cette même adresse foo@bar.com. Les spammeurs s'en servent pour faire croire qu'ils ont pris le contrôle de votre boîte mail.

Certes, il y a des protections, les extensions SPF, DKIM et DMARC, qui permettent essentiellement de vérifier qu'un email provient bien de l'adresse dont il prétend provenir. Mais comme ces extensions ne sont pas utilisées partout, il faut continuer d'accepter des emails qui ne sont pas authentifiés. Souvent, l'absence de SPF/DKIM/DMARC est juste considérée comme un critère pour classifier comme spam. Il y a aussi des difficultés liées aux emails transférés et aux mailing lists (je ne vais pas rentrer dans les détails, je ne les connais pas bien). Et il est dommage que les clients mail n'affichent quasiment jamais si le message passe la vérification de la signature DKIM.

À côté de cela, le PGP ou le S/MIME offrent une sécurité beaucoup plus forte : ils permettent non seulement de vérifier que l'email provient de la bonne adresse, mais aussi que cette adresse appartient à la bonne personne (en recoupant la signature avec d'autres sources, comme un site Web ou des commits Git), et aussi de chiffrer le contenu pour se prémunir contre l'écoute passive si le message venait à circuler en clair sur le réseau⁵. Sauf que PGP et S/MIME ne sont essentiellement pas déployés, en dehors des milieux de geeks old-school.

Il est intéressant de constater que, bien que l'email soit un vecteur d'arnaques beaucoup plus important que le Web, les efforts massifs pour sécuriser le Web avec HTTPS ont eu une contrepartie nettement plus limitée du côté de l'email.

La centralisation qui guette

Je passe à type complètement différent de critique. Malgré son fonctionnement technique théoriquement décentralisé, l'email souffre lui aussi d'une centralisation progressive aux mains de quelques méga-entreprises.

Comme nous sommes inondés par le spam, chaque serveur qui reçoit des emails consulte généralement des DNSBL (DNS Black Lists), c'est-à-dire des listes d'adresses IP considérées comme spammeuses dont il faut rejeter les emails. Le problème, c'est que cela donne aussi à GMail, Hotmail (Microsoft) et autres un contrôle absolu sur l'email. S'ils jugent que votre serveur n'est pas digne de confiance, vos emails ne seront jamais expédiés à leurs utilisateurs. Vu leurs parts de marché, autant dire que votre serveur est inutilisable. Or, ils peuvent être très tâtillons et arbitraires dans leur confiance.

Aujourd'hui, la difficulté principale d'héberger un serveur mail n'est pas technique, elle est dans le fait de conserver sa réputation pour GMail, Hotmail et les différentes DNSBL, et parfois passer par leurs procédures volontairement rendues compliquées pour obtenir un déblocage. J'ai personnellement eu un serveur mail nouvellement installé bloqué par Hotmail dès le premier message, et j'ai dû refuser plusieurs fois d'accepter la réponse automatisée « désolés, nous ne pouvons pas répondre favorablement à votre demande » du support pour qu'ils acceptent enfin les emails de ce serveur.

Donc, de système décentralisé qu'il était, l'email est de fait devenu un système centralisé aux mains de quelques acteurs, d'une part les gros hébergeurs comme GMail et Hotmail, et d'autre part, les fournisseurs d'emails en masse, comme SendGrid, SendLayer, MailChimp, etc., qui vendent essentiellement un service de maintien de réputation, à prix d'or.

Je mentionne aussi que la configuration d'un compte email sur un client local (comme Evolution, Thunderbird ou Outlook, par opposition à un webmail) est beaucoup plus compliquée qu'elle ne devrait l'être, par exemple parce que les serveurs IMAP et SMTP sont potentiellement différents et qu'il faut entrer les deux, ou qu'on ne sait jamais si l'identifiant de connexion est l'adresse mail ou autre chose. Cela pousse les gens à utiliser plutôt un webmail, et donc rend plus difficile de changer d'hébergeur parce qu'il faut s'habituer à une nouvelle interface.

Je renvoie à des articles de blog plus développés : par Carlos Fenollosa, par David Bushell, par Maarten van Gompel.

Une expérience de pensée : réinventons l'email

Après avoir décrit tous ses travers, je vais rêver un peu (beaucoup) et essayer d'imaginer une alternative fictive à l'email et d'expliquer en quoi elle résoudrait ses travers sans tomber dans de nouveaux travers. Appelons cette alternative le « bemail » (pour better email).

D'abord, je considère que par défaut, toute communication personnelle sur Internet devrait se faire entre des personnes qui ont la certitude de l'identité de l'autre⁶. C'est plus ou moins le contraire de l'anonymat, donc je parlerai d'« onymat », même si le dictionnaire ne connaît pas ce mot. Mais cela va plus loin que simplement donner son nom : il faut aussi que l'autre puisse vérifier que je suis la personne que je prétends être, autrement dit il faut s'assurer qu'on ne peut pas se faire passer pour moi, alors que, comme je l'ai expliqué, c'est possible et même très facile avec l'email.

Il y a une première condition nécessaire, c'est que lorsque je reçois un bemail, je peux vérifier — et mon client bemail vérifie toujours — qu'il a bien été envoyé par l'adresse qui prétend communiquer avec moi. En d'autres termes, dans le monde du bemail, une sorte d'équivalent du DKIM est systématique et obligatoire. Le chiffrement est également obligatoire, donc une sorte de PGP.

Mais il faut aussi qu'on puisse vérifier que cette adresse bemail est associée à la personne physique Jean Abou Samra, ce qui est beaucoup plus délicat. Pour cela, il n'y a pas trente-six solutions. Il faut que l'État y mette du sien et s'occupe de fournir un moyen fiable de vérifier l'identité d'une personne. C'est aussi absolument nécessaire pour numériser toutes les démarches sensibles, et c'est pour cela que l'État français commence, justement, à se bouger en créant France Identité (avec 15 ans de retard à mon avis, mais mieux vaut tard que jamais⁷). Dans ce monde idéal, pour créer une adresse bemail dans le cas le plus courant, il faut s'identifier avec l'équivalent pour son pays de France Identité⁸. Cette adresse est associée à une preuve cryptographique de l'identité de la personne à laquelle elle appartient, et cette identité est vérifiable lorsque j'envoie un bemail avec.

(Pour les détails cryptographiques : l'hébergeur pourrait créer une paire clé publique – clé privée et une signature de la clé publique par la clé privée stockée dans la carte d'identité, et on pourrait à la réception vérifier d'une part que la signature du bemail est correcte grâce à la clé publique, d'autre part vérifier que la signature de la clé publique est correcte grâce à la clé publique fournie par France Identité. Le point que je veux souligner, c'est que l'État n'a pas besoin de stocker de base de données sensible qui pourrait fuiter — on sait ce qui arrive quand il le fait — car il n'a besoin de stocker et servir que des clés publiques.)

La quantité d'arnaques par bemail serait réduite pratiquement à zéro puisqu'on pourrait toujours identifier l'auteur de ces arnaques. Ce n'est pas en contradiction avec le fait que les messages sont chiffrés et ne sont lisibles par personne d'autre que l'expéditeur et le destinataire (ni par les hébergeurs de bemail, ni par l'État) : si le destinataire le décide, il peut divulguer le message, le signaler comme arnaque à un service de police, et la signature cryptographique garantit alors de retrouver l'identité de l'expéditeur.

Cet onymat aurait d'autres conséquences intéressantes. Par exemple, plutôt que la pratique totalement ridicule et pourtant incroyablement répandue consistant à « signer » un document administratif numérique en copiant-collant une photo de sa signature dessus, on pourrait signer en envoyant simplement par bemail une formule-type comme « Par la présente, je signe le contrat ci-joint », et le bemail lui-même serait une signature vérifiable. De même, on se passerait de fournir des photocopies de carte d'identité.

Ensuite, le bemail est immunisé contre les risques de centralisation dont souffre l'email… et pour cela, paradoxalement, il faut introduire un élément de centralisation. Je veux dire que le stockage des bemails est géré par des fournisseurs de bemail (qui ressemblent à GMail, Hotmail, Proton, etc., avec idéalement moins de monopole), mais les adresses bemail, elles, ne dépendent pas du fournisseur. Concrètement, alors qu'une adresse email ressemble à nom.prénom@gmail.com (en prenant l'exemple de GMail), une adresse bemail ressemble (mettons) à nom.prénom@fr, sans le nom du fournisseur. Il faut donc un système central qui sache associer chaque adresse bemail à un fournisseur. C'est une sorte d'équivalent du DNS, le système mondial qui associe l'adresse d'un site Web au serveur qui l'héberge pour que vous puissiez taper wikipedia.org dans votre navigateur plutôt que 2a02:ec80:600:ed1a::1. Ce système central n'est pas bien compliqué, il se contente de stocker une grande table et de répondre aux requêtes sur cette table. Il pourrait être opéré par l'État, mais plus vraisemblablement une association dans le genre de l'ICANN et de l'Afnic. Sa raison d'être est de permettre de changer facilement de fournisseur bemail. On peut migrer d'un fournisseur à un autre sans avoir à demander à toutes ses connaissances de noter la nouvelle adresse, ce qui évite le problème de vendor lock-in de l'email. (Il faudrait un moyen de distinguer les homonymes, mettons avec un numéro.)

On peut imaginer, par-dessus ceci, un système qui ressemble au plus addressing pratiqué par certaines personnes pour réduire les emails non sollicités. Concrètement, pour envoyer un bemail à quelqu'un, l'adresse serait nom.prénom+code@fr, avec un code qu'il devrait nous donner à l'avance et qui servirait à éviter que n'importe qui puisse écrire à n'importe qui (de même que nous échangeons aujourd'hui les adresses mail, on donnerait ces codes à nos connaissances). Pour les sites Web qui demandent une inscription, il y aurait à chaque fois un nouveau code dédié uniquement au site et qui n'accepterait de bemails que de ce domaine, ce qui permettrait d'éviter que le site ne revende l'adresse bemail à d'autres entreprises pour qu'elles y envoient de la publicité. Et il devrait idéalement être possible, voire normal, de s'inscrire sur un site Web en préservant son anonymat complètement, alors qu'aujourd'hui la plupart ont notre adresse mail (et peuvent donc recouper avec d'autres sites pour obtenir des informations sur nous), ce qui se ferait en enlevant la partie nom.prénom. Bien sûr, il y aurait beaucoup de détails sur lesquels réfléchir, ce que je ne vais pas faire, mais il me semble que rien de ceci ne pose de difficulté fondamentale, et le spam serait grandement diminué, tout en protégeant la vie privée sur le Web.

J'ai décrit comment on parviendrait à un onymat par défaut. Mais bien sûr, il serait dystopique qu'un employé ne puisse pas signaler anonymement un harcèlement, qu'un citoyen ne puisse pas écrire anonymement à son député, qu'un étudiant ne puisse pas faire un retour anonyme à un professeur, qu'un lanceur d'alerte ne puisse pas se protéger, ou qu'un geek ne puisse pas participer sous pseudo au développement d'un logiciel libre⁹, bref, que l'onymat soit obligatoire en toutes circonstances. Pour permettre l'anonymat sans faire revenir le spam, il y a une solution très simple : avoir un type d'adresses bemail qui, au contraire des adresses personnelles habituelles, seraient payantes. Le prix n'a pas besoin d'être élevé (pour fixer les idées, mettons 10€ pour acheter une adresse, valable indéfiniment), et il ne faut surtout pas qu'il soit un obstacle significatif y compris pour les plus pauvres. Il doit juste être assez élevé pour qu'il ne soit pas rentable d'envoyer du spam. En effet, de même que pour les adresses personnelles normales, il serait possible de prouver qu'un message donné a été envoyé par une adresse anonyme donnée, et en le signalant, de faire bloquer cette adresse (je répète qu'il n'y a pas de contradiction avec la confidentialité des bemails, encryptés de bout en bout sans que l'État ou une entité quelconque puisse les consulter, c'est choix du destinataire de divulguer le bemail qui fait la différence). À partir du moment où l'adresse serait bloquée, le spammeur serait obligé d'en acheter une nouvelle, donc de re-payer 10€, et ainsi de suite, l'idée étant qu'en moyenne, le spammeur va gagner moins de 10€ avant qu'une adresse qu'il exploite soit bloquée, donc perdre de l'argent, donc arrêter de spammer. Bien sûr, s'il y avait autant de spam qu'avec l'email aujourd'hui, les services auxquels on signale les spams seraient saturés en un clin d'œil, mais comme le spam ne serait plus rentable en général, il se réduirait à pas grand-chose et la quantité restante serait gérable. Il faudrait par contre pouvoir payer les 10€ de manière anonyme, mais cela peut passer par un tiers de confiance (les services de paiement anonyme existent déjà).

Les bemails ne sont faits ni de HTML, ni de texte brut, mais d'un format intermédiaire, qui autorise une mise en forme simple et volontairement limitée :

• Italique,
• Gras,
• Souligné,
• Barré,
• Exposants et indices,
• Liens,
• Couleur du texte,
• Un niveau de taille de police plus petite (comme <small> en HTML), essentiellement pour les informations du type « Truc est une marque déposée de Machin »,
• Police monospace pour le code,
• Citations (avec l'identifiant du message dont elles sont extraites, si ce sont des citations d'un message précédent de la conversation),
• Tableaux,
• Listes à puces et listes numérotées,
• Images uniquement intégrées au message, en PNG, JPEG et éventuellement d'autres formats d'images matricielles comme WebP, AVIF ou JPEG-XL.

C'est tout. En particulier il n'est pas possible en bemail :

• De changer la couleur du fond du texte.
• De sélectionner une police précise : on a juste le choix entre « normal » et « monospace », et le destinataire choisit sa police normale et sa police monospace, chaque client bemail ayant ses polices par défaut).
• De mettre la police dans une taille arbitraire.
• De demander à ce qu'une image soit chargée d'une URL donnée quand le destinataire reçoit le bemail. Cas particulier : d'insérer un pixel espion.
• D'insérer des images vectorielles, et en particulier, du SVG.

Il faut dire un mot sur le dernier point. D'abord, la spécification du SVG est invraisemblablement compliquée, elle fait presque mille pages, et malgré cela laisse beaucoup de cas mal définis, et les interpréteurs SVG ont des degrés de conformité à la spécification très inégaux (même les monstres de complexité que sont les moteurs de rendu Web), donc cela rejoint les arguments sur la complexité du HTML. Bêtement, il n'y a pas d'autre format d'images vectorielles que le SVG qui soit vraiment standard et courant.

Bien sûr, il y aura toujours des malins pour faire de la mise en forme avec des images matricielles, et ce n'est pas forcément une mauvaise chose (par exemple les formules mathématiques avec des fractions pourraient être insérées comme ça). En revanche, une image matricielle ne peut pas contenir de liens, alors que le but de tout marketeur et à plus forte raison de tout spammeur est de vous faire cliquer sur un lien, donc on peut espérer que leur usage resterait raisonnable (?).

Il n'y aurait pas de citation automatique des messages précédent entier, mais des citations de parties spécifiques pourraient être ajoutées pour répondre à un point précis.

Je le répète, il y aurait énormément de détails à tirer au clair, et je ne vais pas le faire, parce que je ne suis pas en train d'écrire une spécification. De toute façon… tout ceci est une utopie puisque l'email ne va pas changer de sitôt. Ne vous moquez pas, je suis juste un jeune idéaliste naïf qui caresse le rêve irréaliste de changer le monde.

Commentaires