Aerogramme, serveur IMAP (email)

Hey, je suis actuellement en train de développer un serveur IMAP (MDA) du nom de Aerogramme. J’ai un financement NLnet pour ça et on prévoit de le déployer à terme en prod chez Deuxfleurs, ça fait parti de notre stratégie interne.

logo large de Aerogramme

Vous pouvez en apprendre plus en lisant ce PDF (en français, extrait d’un document que j’ai du rédiger dans un autre contexte) : Synthèse.pdf (122,7 Ko) ainsi que dans la section Design de la doc du logiciel.

En deux mots : Aerogramme est un remplaçant pour Dovecot dans une stack email, en distribué et qui chiffre les emails sur le disque dur à partir du mot de passe de l’utilisateur.

:warning: Aujourd’hui le logiciel est en « alpha ». Il n’est pas utilisable en production. Je vais faire une campagne de test avec des utilisateurs prochainement. On compte pas le mettre en production avant 9 mois chez Deuxfleurs et on aime quand c’est expérimental. Si vous voulez faire parti de la campagne, faites signe.

@ppom m’a fait remarquer qu’il y avait beaucoup de points communs avec le projet de @bohwaz présenté au camps CHATONS 2023. Je n’y étais pas, je base ma réaction sur le texte du libreto.

Réaction à la proposition Potimail de Bohwaz On met l'accent sur l'intéropérabilité (IMAP, CalDAV, CardDAV) avec les protocols email existants là où Bohwaz imagine du web (pour la gestion du chiffrement côté utilisateur). On imagine un scénario côté utilisateur avec Aerogramme en bridge, voire en WASM exécuté dans la navigateur mais c'est pas la priorité.

De la même manière sur les fonctionnalités, on vise la parité avec l’existant. Idéalement on aurait un système de configuration souple, comme kannader avec du WASM qui se hook un peu partout pour réaliser les features imaginées par Bohwaz. Les features que j’avais en tête/que je trouve sympa : éphémérisation des pièces jointes, système « d’invitation », etc. Hey.com et les échanges au sein du collectif sont inspirants sur le sujet, système de quota rendu visible (= matérialité du numérique, etc.). (je suis pas fan de la traduction en markdown par contre).

Pour moi, la condition de réalisation de ces features, c’est une bonne maîtrise de la stack email. J’ai écrit un parser d’email, on est en train d’écrire un serveur IMAP, et je connais l’auteur de kannader.

Le PGP n’est pas à l’ordre du jour dans Aerogramme, le protocole d’auth SRP n’est actuellement pas implémentée dans Aerogramme. De manière générale, l’accent sur la sécurité n’est pas mis aussi fort pour le moment que dans la proposition de Bohwaz, même si ça peut venir avec le temps. De manière générale, le point limitant à Deuxfleurs c’est que les serveurs sont à la maison : perquisition des serveurs = perquisition du domicile des gens = ça refroidit le militantisme. Sinon, on a une personne à Deuxfleurs qui est dans le board de Tor, qui dev Arti (un client Rust pour Tor) et qui pourrait être intéressée par parler de Tor+email du coup.

Aujourd’hui la question du webmail/client lourd est relativement impensée, surtout dans le cas où le déchiffrement est côté utilisateur, mais @ppom a fait montre d’un intérêt certain pour le sujet, donc on a potentiellement des synergies qui émergent là aussi. Impensé principalement parce qu’on a pas ces compétences en interne. Mais aussi parce que je suis + motivé par les questions d’obsolescences par les logiciel/services que par la sécurité, et du coup je vise des plateformes sur lesquelles on ne peut plus installer de logiciels (comme mon iPhone 4S), et donc on doit faire avec les clients emails existants.

Et du coup j’ai plus envie d’explorer les possibilités d’interopérabilité que de sécurité, par exemple en implémentant Exchange Active Sync, un protocole email réception push + envoi + calendrier + contact + note pour lequel tu as un client natif dans tous les iPhone et beaucoup d’Android OEM.

Et donc je préfère ça plutôt que de nouveaux protocoles - sur lequel il y a des brevets mais dont je suis d’avis d’adopter la position de VideoLAN (VLC) dessus : f*** ça n’a pas de valeur en droit français.

Je ne pense pas que Potimail « doive » se fondre dans Aerogramme ni l’inverse ; je ne veux pas qu’on force la coopération dans un sens ou dans un autre sous prétexte « d’efficacité d’allocation des ressources ». Par contre je suis disposé à discuter, échanger, et voir si/quelles synergies émergent, trouver une situation de coopération où tout le monde trouve son compte.

Il existe plein de solutions email, et si vous en avez d’autres à proposer/recommander, je vous recommande de plutôt faire un fil à part.

Peut-être que ça ne vous parlera pas, que vous trouverez ça peu utile, que ça s’inscrit dans des dérives de l’informatique que vous dénoncez (réinventer la roue, cargo cult, contraire à KISS et la philosophie UNIX, etc.). Je préférerais qu’on n’ait pas de discussion de ce genre sur ce fil, ni avoir le sentiment de devoir nous justifier quant à nos choix.

Merci pour votre lecture et bonne journée :slight_smile:

cc: @ppom qui m’a suggéré de laisser un message ici
cc: @n-peugnet qui est intéressé pour utiliser eml-codec
cc: @Maxime qui fait de l’email au Cloud de Girofle
cc: @bohwaz pour sa proposition Potimail

3 Likes

Pour avoir un peu creusé Aerogramme avant ce post, c’est pour moi vraiment ça le point fort et qui nous donne envie de nous y intéresser chez CLUB1, même si on est bien sûr encore trèèès loin de le mettre en application (on est plutôt move slow and try not to break things que l’inverse haha).

Après j’ai justement vu dans vos refs que c’est inspiré en partie de la manière de faire de Riseup (eux mêmes visiblement inspirés de Posteo) à partir d’un plugin Dovecot qui au final nous conviendrait plus car on a pas vraiment le cas d’usage du stockage S3 (qui est la grosse diff par rapport à ces deux source d’inspiration si j’ai bien compris).

Aerogramme leverages insights from research & other software:

Mais sinon oui, le coup d’utiliser eml-codec ça serait par rapport à ce ticket sur notre soft de newsletter. (Attention c’est un lien GitHub !)

1 Like

Hello @quentin merci du retour !

Pour info Potimail ne remplace pas le serveur de mail, ça remplace le MDA plutôt : le mail est délivré à Potimail, qui le stocke selon ses besoins.

J’avais déjà lu le site d’Aerogramme, ça a l’air chouette, mais pour moi ce sont des choses très différentes :slight_smile:

Les scénarios d’utilisation de Potimail sont multiples :

  • sur un serveur d’hébergement de mail en masse : Potimail reçoit tous les messages du serveur SMTP local ;
  • sur un serveur d’hébergement mixte : le serveur SMTP peut décider d’avoir certaines adresses mail qui sont gérées par Potimail, et d’autres non, il envoie à Potimail ce qui a été configuré ;
  • sur un hébergement mutualisé, ou en local : Potimail récupère les mails d’un ou plusieurs répertoires IMAP d’une boîte mail existante.

Dans tous les cas, une fois les mails remis à Potimail, il les stocke chiffrés, et ne peuvent être déchiffrés que côté client (modèle de Protonmail).

C’est la théorie, car Aerogramme est bien plus avancé que Potimail, sur lequel je n’ai pas pu avancer depuis cet été :frowning:

Aerogramme propose du chiffrement côté serveur, pas côté client, ce qui est très différent, et simplifie grandement les choses niveau code/design.

Par exemple dans Potimail comme le serveur ne peut pas déchiffrer les mails, il ne peut pas faire des recherches, ou te fournir les headers des 50 derniers mails uniquement, tout cela doit être géré côté client, ça pose de nombreux problèmes (d’où aussi le passage en Markdown, pour réduire drastiquement la taille des mails), auxquels je n’ai pas encore toutes les réponses.

Tous ces obstacles sont bien expliqués par ProtonMail, par exemple sur la recherche : Behind the scenes of Proton Mail’s message content search | Proton

Ce qui permet de ne pas passer trop de temps à identifier la bonne solution, il « suffit » de la coder. Ce qui représente quand même pas mal de taf ^^

Pour information, Aerogramme peut être utilisé côté client aussi, de sorte que le seul moment où les données sont en claires, c’est quand elles sont reçues depuis le serveur SMTP via LMTP : tes mails sont alors chiffrées avec la clé publique de l’utilisateur et mis dans sa file d’attente. À la prochaine connexion, cette file d’attente sera process. Actuellement, process = mettre ces emails dans le dossier INBOX.

Tu peux configurer ton serveur SMTP (à tout hasard Postfix) pour router que les emails que tu veux vers le LMTP d’Aerogramme et envoyer les autres ailleurs, genre vers un Dovecot.

Ce bout de PDF t’en dira plus sur les 2 modes de déploiement/usage d’Aerogramme : Mode transparent et mode chiffré de bout en bout (109,0 Ko).

Notre modèle de donnée permet d’implémenter ce « client-side searching » décrit dans le billet que tu cites. Et pour le coder, je suis assez confiant que tantivy ferait l’affaire. Je t’invite aussi à creuser sur notre modèle de donnée : Mutation log | Aerogramme . Et je suis assez convaincu que Aerogramme peut donc être aussi déployé avec un modèle de sécurité similaire à ProtonMail (même si en effet, ça n’est pas ma priorité pour le moment).

En gros on stocke un « append only-log » chiffré dans Garage de toutes les opérations faites sur la mailbox (ajout d’un email, ajout de flag, suppression, etc.). Ce log est récupéré par Aerogramme (qui tourne soit sur le serveur « en mode transparent », soit chez les clients « en mode bout-en-bout ») qui reconstruit l’état de la mailbox, et peut construire à ce moment là tous les index qu’il veut. Pour pas reconstruire tous les index depuis le log à chaque fois, régulièrement, des checkpoints de ces index sont également persistés sur Garage, également chiffrés.

Une des limitations de Aerogramme sera probablement sa consommation de RAM : ces structures de données de recherche/indexation doivent être récupérées en entière depuis Garage, déchiffrées, partiellement ou complètement reconstruites et maintenues en RAM tout le temps de la session de l’utilisateur. La consommation de ressource sera beaucoup plus importante que Dovecot, tout comme la consommation de RAM de Garage est beaucoup plus importante que NFS.

Donc je reste persuadé que le scope est largement overlapping. Mais comme je dis, je ne souhaite pas forcer la collaboration. Si c’est pas ta vision/ça correspond pas à ce que tu veux, je serai très content en tout cas d’échanger à l’avenir avec toi sur nos visions des emails et partager nos galères communes avec ces bonnes vieilles stack emails :slight_smile:

Ce que je comprends pas c’est que tu me renvoie vers des trucs en rust, sauf que moi je parle d’un client web en JS, donc je vois pas le rapport :wink:

Tu pourrais compiler Aerogramme comme une lib WASM, bind les API fetch/xhr de ton browser pour faire les E/S vers Garage (qui expose que des API HTTPS) et exposer des fonctions de manipulations de la MailboxView à ton javascript.

Tu pourrais ensuite utiliser cette lib comme base d’un webmail. Il suffisait de demander :person_shrugging:

Pour référence : Compiling from Rust to WebAssembly - WebAssembly | MDN

Pour moi c’est un peu usine à gaz que de passer par ça, j’ai des doutes sur les perfs, sans compter qu’il est alors impossible d’inspecter le code côté client, niveau sécu c’est pas super transparent du coup.

1 Like

Bon courage dans ton développement de Potimail, merci pour la discussion qui a permis d’identifier les envies et les attentes.

@bohwaz Est-ce qu’il y a un site web de potimail ou une doc qui expliquerait le design que vous avez choisi ?

Ya un début de spécifications là si je dis pas de bêtises : KD2 / Potimail · GitLab

1 Like

C’est ça :slight_smile:

Est-ce qu’un support du protocole JMAP a été envisagé ?

Peut-être à terme, mais JMAP selon moi est équivalent en terme de fonctionnalités à un IMAP avec plein d’extensions. Donc selon moi, autant d’abord implémenter ces extensions, en adaptant le modèle de donnée interne, et ensuite seulement implémenter le protocole par dessus.

Ensuite, je ne cache pas le fait que je sois perplexe vis à vis de JMAP : ils se comparent toujours à IMAP, jamais à EAS. Pourtant EAS est dans tous les téléphones, Android comme iOS, depuis 2012 voire avant. Est-ce qu’il vaut mieux déployer le protocole qui couvre 99% des terminaux, ou celui qui a péniblement deux applications, ltt.rs et swiftmail ?

Mais en réalité, toutes les idées sont ici, et on a une room matrix (#aerogramme:deuxfleurs.fr), et les choix seront faits comme Garage je pense : en priorisant les besoins des utilisateur-ices et en fonction du temps & des sous :slight_smile:

Pour info, actuellement je fais des tests de performances, et je cherche aussi des gens pour tester Aerogramme en condition réelles sur un déploiement de test (tout est expliqué sur le lien : comment se créer un compte, etc.). Les CHATONS sont les bienvenues : vous pouvez tester Aerogramme sans vous prendre la tête, et moi je vois ce qui marche pas actuellement ^^

Ah et btw, il y a un enregistrement de ma présentation au FOSDEM.

2 Likes

Merci pour cette réponse.
Du coup, je découvre z-push déjà packagé dans YunoHost (je l’avais loupé lorsque j’ai fait mon tour des apps ^^)…

Je vais creuser notamment sur l’affirmation que IMAP nécessite parfois 200 commandes pour des choses simples et que jmap s’en sort mieux.

J’ai assisté à la présentation de Ricardo Signes au FOSDEM, et je l’avais déjà vu avant en ligne. Je connais bien Fastmail, j’ai même eu une boite chez eux un temps. Benoit Tellier présentait aussi au FOSDEM Apache James, on a rapidement échangé puisque je cite la doc d’Apache James dans mes slides.

Maintenant, moi je viens du monde de la recherche. Et quand tu avances que ton protocole est meilleur, j’attends que tu publies une évaluation. Et puis comme ça on discute autour après. À ma connaissance, il n’y a pas d’évaluation de JMAP face à IMAP qui existe.

Le talk de Benoit Tellier au Capitole du Libre ne présente aucune évaluation, il dit juste que JMAP est un « protocole vert » avec tout ce que ça pose comme problème.

Et non, ce spot de Fastmail n’est pas une évaluation, c’est une publicité. Rien qu’en le voyant, on peut déjà faire des critiques : ils comparent Apple iOS Mail à leur client Fastmail. Je sais que le client Apple iOS ne supporte pas toutes les extensions d’IMAP, et je sais qu’on peut construire cette vue IMAP en une seule requête. Donc cette vidéo est juste problématique. Et franchement, toute la communication de Fastmail est comme ça.

Un autre argument de JMAP, c’est que c’est plus facile de construire des clients. Apparemment, cette facilité de développement n’a pas mené pourtant à un écosystème très fleurissant.

Enfin, un dernier argument, c’est que le protocole IMAP serait « cracra », et que le HTTPS + JSON serait « top of the line ». HTTP, HTTP2, HTTP3, TLS, et JSON sont loin d’être des protocoles faciles à implémenter - pour anecdote, l’autre jour, je me suis retrouvé avec une incompatibilité entre le Google Load Balancer et un webservice Python, où les deux s’attendaient l’un l’autre.

NLnet, avec des gens comme emersion, comme duesee, etc. sont en train de bootstrap une communauté « modern email », où tu aurais les protocoles exposés comme des frameworks, comme on connait avec HTTP (genre express, fastapi, sinatra, ror, symfony, etc.).

Je sais plus qui disait à la room « modern email » : Knowledge is disappearing. Je pense que c’est probablement l’analyse la plus juste. Quels savoirs il nous reste autour des emails, et est-ce que notre volonté de corriger ce qui est perçu comme obsolète ne serait pas, d’une part un manque de compréhension, d’autre part le reflet d’une société qui pense l’innovation bien plus que la maintenance ?

Punaise, un jour je vais faire un article / talk « debunking JMAP » je sens x)

3 Likes

Merci pour ton apport (qui m’aide à déterminer si ça vaut le coup qu’on porte le sujet dans yunohost ou pas).
Ce que j’ai regardé sur le sujet c’est ça:

Cypht 2.0 (qui sort dans quelques semaines) va supporter JMAP et on a une assez grande communauté pour corriger tous les bogues rapportés en lien avec JMAP

https://www.cypht.org/install-2x.html
https://openhub.net/p/cypht

Disons que IMAP est mal adapté au webmail (HTTP) car il est conçu pour une connexion longue, où tu refait ton authentification à chaque fois. Sauf que JMAP ne spécifie rien sur l’auth, donc chaque provider peut fournir un système d’auth différent, ce qui rend la compatibilité entre clients et serveurs impossible, c’est un peu bête… Ou alors j’ai mal pigé. Mais perso c’est ce qui m’avais un peu stoppé dans mon intérêt pour JMAP : ça prétend effectivement être une version web d’IMAP (et ça on en aurait bien besoin), mais en réalité ben ça ne règle pas grand chose et c’est plus complexe à implémenter qu’IMAP.

Pas forcément. delta.chat est un contre-exemple parfait dans lequel imap est employé par le logiciel de l’utilisateure final comme un instant messagerie, chiffré de bout en bout.

oui c’est exactement ce que je dis : c’est fait pour les sessions ouvertes longtemps, ce que fait Delta chat, il reste connecté en permanence au serveur IMAP. Ça n’est pas adapté au HTTP où la connexion ne dure que quelques millisecondes.