Aerogramme, serveur IMAP (email)

Tech
3

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 ^^

4

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:

5

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:

6

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

7

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 « J'aime »
8

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

9

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

10

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

1 « J'aime »
11

C’est ça :slight_smile:

12

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

13

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 « J'aime »
14

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.

15

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 « J'aime »
16

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:

17

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

18

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.

19

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.

20

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.

21

Thinderbird / K-9 mail va supporter EAS (Exchange)

22

Arf oui, j’avais pas compris ton propos initial.