Réflexion à voix haute sur l’e-mail de deuxième génération

Note : Ce texte n’est qu’une mise en ordre de mes pensées. Je n’y ai pas réfléchi très en profondeur, et il n’est pas nécessaire de considérer cela comme une bonne idée. Mieux vaut partir avec des attentes aussi basses que possible.

Les problèmes de l’e-mail

• Beaucoup de vieilles technologies sont encore utilisées, mais l’e-mail m’agace à chaque fois que je m’en sers.
• Du point de vue de l’utilisateur, l’e-mail fonctionne plutôt bien. Il arrive parfois qu’on reçoive trop d’e-mails, notamment du spam, mais l’e-mail est ancien, fiable, facile à comprendre et relativement simple à rechercher.
• En revanche, le backend de l’e-mail est un désastre.

Les problèmes du backend de l’e-mail

• Beaucoup de fonctionnalités de l’e-mail n’ont pas de spécification claire. Par exemple, lorsqu’on répond à un message, rien n’indique clairement s’il faut écrire la réponse en haut ou en bas du message.
• Il n’est pas clairement défini quel HTML peut être utilisé dans un e-mail. Microsoft Outlook abuse parfois du moteur de rendu HTML de Microsoft Word.
• La façon de chiffrer les e-mails n’est pas claire non plus. On a inventé OpenPGP, mais il a été très peu utilisé et présente de gros défauts.
• On n’a pas toujours pu vérifier l’authenticité des e-mails. C’est pour cela qu’on a inventé SPF, mais SPF n’a pas résolu tous les problèmes. On a donc inventé DKIM, mais DKIM non plus n’a pas tout résolu. On a ensuite inventé DMARC, mais comme DKIM lui-même présente de gros défauts, DMARC est aussi contourné.
• On a ajouté une autre couche appelée BIMI, qui dépend elle aussi de DMARC, lequel dépend de DKIM, et DKIM a des défauts.
• Même lorsqu’il y a DMARC, 68,2 % des enregistrements sont définis sur p=none. Cela signifie que, fondamentalement, DMARC ne fait rien.
• Avec tout ce qui précède et des politiques antispam agressives, l’auto-hébergement de l’e-mail devient très difficile.
• Enfin, il y a la gestion de la réputation IP. Certaines adresses IP sont plus « propres » que d’autres, surtout dans des systèmes mutualisés comme SendGrid ou AWS SES. Cela complique la création de comptes d’envoi en volume, et des e-mails légitimes finissent souvent classés comme spam.

Hypothèse sur l’e-mail de deuxième génération

• Créer un nouvel enregistrement DNS MX2. La plupart des services d’e-mail auraient des enregistrements MX2 et MX. Les anciens services n’auraient que MX.
• Si un vieux client e-mail âgé de 20 ans tente d’envoyer un message, il cherchera l’enregistrement MX et enverra le message. Un client moderne, lui, verra MX2 et enverra le message de cette façon.
• Les services d’e-mail qui implémentent MX2 publieraient une date d’entrée en vigueur et, après cette date, tous les messages envoyés via l’enregistrement MX seraient automatiquement classés comme spam.

Priorités pour l’e-mail de deuxième génération

1. Fournir une spécification HTML standardisée pour l’e-mail ainsi qu’une suite de tests de conformité.
2. Fournir des en-têtes pour les préférences liées aux fils de discussion ou d’autres préférences liées à l’e-mail.
3. Fournir, avec l’affichage HTML, une copie texte seule, sans HTML.
4. Tous les enregistrements MX2 devraient contenir une clé publique.
5. Générer un hash pour vérifier l’authenticité et l’intégrité de l’e-mail, le chiffrer, puis l’ajouter dans les en-têtes.
6. Supprimer SPF, DKIM et DMARC, et standardiser le tout autour d’un seul enregistrement MX2 afin de simplifier les piles e-mail auto-hébergées.
7. Authentifier les e-mails par domaine, et non par adresse IP.
8. Les clients qui implémentent MX2 pourraient choisir un nouveau schéma de chiffrement capable de remplacer OpenPGP.

Réflexions supplémentaires

• Il faut un moyen de partager des fichiers volumineux.
• Sans participation de Google et Microsoft, MX2 ne verra probablement jamais le jour.
• On pourrait aussi envisager de remplacer SMTP par HTTP avec une API REST standardisée et des corps JSON.
• Le simple fait d’utiliser HTML peut déjà faire débat. À l’origine, l’e-mail n’a pas été conçu pour HTML.
• Il y a peut-être une occasion d’appliquer rigoureusement un nouveau standard.

Avis de GN⁺

• La tentative de résoudre la complexité et les problèmes de sécurité du système d’e-mail est très intéressante. En particulier, proposer une nouvelle manière de garantir l’authenticité et l’intégrité des e-mails pourrait être utile.
• Cependant, introduire un nouveau standard est extrêmement difficile. La participation d’acteurs majeurs comme Google et Microsoft est en particulier indispensable.
• La controverse autour de l’utilisation de HTML demeure. Il pourrait être nécessaire d’envisager un autre langage de balisage pour résoudre les problèmes de sécurité.
• Appliquer strictement un nouveau standard serait idéal, mais cela pourrait être difficile dans la pratique. Des mécanismes supplémentaires seraient nécessaires pour éviter la dérive du standard et les erreurs d’implémentation.
• La centralisation du système d’e-mail pourrait faciliter l’introduction d’un nouveau standard, mais elle risquerait aussi d’accroître la dépendance envers certaines entreprises.

[cometkim]

Au moins en ce qui concerne l’amélioration du rendu, Google et Microsoft ont déjà investi... tous deux ont participé au projet AMP Email et l’ont soutenu.

[coremaker]

Créer un standard de données comme JSON, c’est une bonne chose.
Mais comme il faudrait aussi discuter en parallèle des spécifications de rendu, cela ne semble pas simple.

La raison pour laquelle HTML avait été choisi aussi,
n’était-elle pas de profiter gratuitement des spécifications de rendu HTML+CSS ?

[ldmsys]

Comme cela a déjà été évoqué plus haut avec le cas extrême de Shop Mail, à titre personnel je suis très sceptique à l'idée de classer ouvertement comme « deprecated » un protocole qui fonctionne déjà bien, puis de ne rendre compatibles que de nouvelles normes de protocole, incompatibles avec l'existant.

[unsure4000]

4. Tous les enregistrements MX2 doivent inclure une clé publique.
   Je trouve cela un peu étrange, car j’ai l’impression que les fournisseurs de services utiliseront non pas la clé publique fournie par l’utilisateur, mais une clé publique qu’ils auront eux-mêmes créée...

[iolothebard]

C’est pour ça qu’on a créé un e-mail merdique… (Hein ? Non, ce n’est pas ça… )

[xguru]

Le système d’e-mail est pratique et agréable, mais j’ai vraiment l’impression qu’il faut des améliorations progressives du protocole.
L’utiliser encore de cette façon dans plusieurs décennies, c’est un peu…

[GN⁺]

Avis Hacker News

Résumé d’une sélection de commentaires de Hacker News

• Complexité et interopérabilité du système de messagerie électronique

  • D’après l’expérience d’exploitation de services d’email sur Internet, le système d’email est complexe, mais il est universellement adopté et offre une excellente interopérabilité.
  • L’introduction d’un nouveau système se heurte à la difficulté de devoir rivaliser avec les énormes investissements en R&D du système existant.
  • Pour proposer un nouveau système d’email, il serait préférable de le faire via des organismes comme l’IETF ou la M3AAWG.

• Ambiguïtés et problèmes de l’email

  • Les en-têtes d’email peuvent semer la confusion à cause de valeurs dupliquées ou contradictoires.
  • Il existe divers problèmes, par exemple lorsque des en-têtes censés n’utiliser que l’ASCII contiennent des valeurs sur 8 bits.
  • La manière de gérer les fils de discussion dans les emails n’est pas non plus standardisée, ce qui pose problème.

• Le problème de la centralisation de l’email

  • La centralisation de l’email n’est pas souhaitable. Les entreprises risquent d’agir dans leur propre intérêt plutôt que dans celui de l’humanité.
  • L’auto-hébergement de l’email n’est pas difficile, et il est aussi possible de l’héberger facilement via un fournisseur de confiance.

• Les problèmes des emails HTML

  • Les emails HTML peuvent favoriser des problèmes comme le phishing et les arnaques.
  • Si l’on devait repenser l’email, certains estiment qu’il vaudrait mieux exclure le HTML et utiliser un format comme Markdown.

• La nécessité de préserver l’asynchronie de l’email

  • L’email doit rester asynchrone, car c’est la dernière ligne de défense technique contre le travail 24 h/24.
  • C’est aussi pour cette raison que les gens n’adoptent pas de meilleurs systèmes.

• La difficulté d’exploiter des serveurs mail

  • L’exploitation d’un serveur mail devient de plus en plus difficile, car il faut satisfaire aux exigences des grands fournisseurs.
  • Les petits serveurs sont progressivement évincés par les grands fournisseurs ou par les expéditeurs de spam.

• La définition d’un email légitime

  • La définition d’un email légitime est subjective. Le spam détériore Internet, et il faut trouver un moyen d’y associer un coût pour l’endiguer.

• La nécessité d’améliorer le système d’email

  • Même en repensant le système d’email, il serait souhaitable de conserver le système actuel tout en l’améliorant.
  • Il est nécessaire d’introduire des systèmes de chiffrement modernes ainsi qu’un système d’authentification de l’expéditeur.

• Checklist anti-spam

  • Quelques ajustements d’implémentation sont nécessaires pour lutter contre le spam.
  • Les forwarders de mail et les serveurs SMTP devraient transférer les messages aussi vite que possible, et le filtrage anti-spam devrait idéalement rejeter les messages au niveau SMTP.

Checklist d’idées anti-spam