Interview : pourquoi FastMail veut remplacer l'IMAP

Stéphane Moussie |

Pendant que Google introduit dans Gmail de nouvelles fonctionnalités exclusives, un acteur beaucoup plus modeste s’échine à faire émerger un nouveau protocole ouvert pour l’email. Avec JMAP, FastMail propose un remplaçant moderne à l’IMAP universel mais vieillissant.

Un projet ambitieux pour un fournisseur d’email qui se démarque du lot par son histoire (acheté par Opera en 2010, FastMail a été racheté par ses employés trois ans plus tard), son modèle économique exclusivement payant et sa bonne réputation. Entretien avec le CEO de FastMail, Bron Gondwana.

MacGeneration : Le nouveau « mode confidentiel » de Gmail est-il interopérable ? Qu’est-ce qui se passe quand un utilisateur de Gmail envoie un email autodestructible à un utilisateur de FastMail ou d’un autre fournisseur de mails ?

Bron Gondwana : La fonction n’est pas interopérable. Même s’ils présentent les messages du « mode confidentiel » comme des emails standards, sous le capot ce n’en est pas. Envoyer un email en « mode confidentiel » vers un autre service que Gmail implique un lien hypertexte vers le contenu hébergé directement par Google, lien qui cessera de fonctionner au bout d’un moment et qui peut être annulé.

C’est un type de messagerie utile, mais ce n’est pas de l’email comme les gens l’entendent. Est-ce que les gens préfèrent que ce type de messages soit mélangé avec leurs emails ou bien séparé ? C’est une question intéressante. Personnellement, je trouve qu’il est plus facile de raisonner quand mes emails sont ma mémoire et que celle-ci n’est pas altérée [Bron Gondwana a publié récemment deux billets de blog sur le sujet, Email is your electronic memory & Email doesn’t disappear, ndr].

Est-ce que vous prévoyez de proposer des fonctions similaires à celles introduites dernièrement dans Gmail ?

Snooze [la mise en attente, ndr], absolument. Je suis déçu que cela nous ait pris autant de temps, mais nous étions concentrés sur la transition de nos serveurs vers la version actuelle de JMAP.

Nudge [signalement automatique d’un message en attente de réponse, ndr] et les autres fonctions liées au « cycle de vie des messages » font partie de nos plans aussi. Par exemple, il serait utile de dire « rappelle-moi ce message si je n’ai pas de réponse dans les trois jours ».

Les réponses intelligentes sont un peu plus délicates. Je vois l’intérêt, mais c’est plus complexe techniquement que les autres. Cela dit, « l’apprentissage automatique avancé » n’est pas nécessaire dans la plupart des cas. Un peu d’heuristique de base peut conduire étonnamment loin quand vous implémentez des services « intelligents ».

Un gestionnaire de droits intégré, j’en doute. S’il y avait des normes pour dire « ne pas afficher le bouton Transférer sur ce message », nous adapterions probablement notre interface et présenterions une information. Mais notre vision de l’email est que vous avez des droits sur votre copie. Les tentatives de verrouillage conduisent simplement les gens à prendre des captures d’écran, à prendre des photos avec un autre appareil ou bien encore à retaper eux-mêmes l’information. Ces restrictions n’arrêtent pas la circulation de l’information, elles font juste perdre du temps aux gens.

La plupart des nouveautés de Gmail sont propriétaires. Est-ce vous pensez que c’est préjudiciable pour l’email en général ?

Absolument. Je comprends pourquoi Gmail va de l’avant et crée ses propres fonctionnalités. Tout le monde fait ça. Parvenir à un consensus prend beaucoup plus de temps, et ces nouvelles fonctionnalités sont réclamées par les utilisateurs.

Pour notre part, nous avons créé un protocole propriétaire autour de JSON en 2010 pour permettre à notre web app, constituée d’une seule page, de communiquer avec notre serveur. Nous l’avons créé de zéro car il n’y avait aucun standard ouvert adapté. Nous nous sommes ensuite rendu compte que beaucoup d’autres sociétés fabriquaient leurs propres protocoles JSON propriétaires, de Nylas à Google en passant par Microsoft.

Image FastMail.

FastMail croit fermement aux standards ouverts et à l’interopérabilité. L’email est le premier réseau social fédéré, et en dépit de tous ses défauts, il s’agit toujours du protocole de messagerie le plus utilisé à des fins professionnelles dans le monde.

Il est nécessaire d’avoir une spécification standard pour éviter la fragmentation dans les technologies qui font « mieux que l’IMAP », de sorte que les développeurs qui sont nouveaux dans l’email puissent commencer à réaliser quelque chose sans avoir à passer une année à comprendre et réimplémenter tout IMAP et MIME. Nous sommes partis du protocole que nous avions déjà validé et déployé en interne, et l’avons rendu plus générique et plus compatible avec les autres fournisseurs de mails. Ainsi est né JMAP.

Cette fragmentation liée aux technologies propriétaires, elle concerne seulement les développeurs ? C’est peut-être exagéré, mais pensez-vous qu’un jour les services d’email ne seront plus interopérables ou nécessiteront d’utiliser une poignée d’apps officielles ?

Le problème général est le suivant : si vous avez N implémentations serveurs différentes et M implémentations clients différentes et que chaque serveur implémente le même protocole, alors tout le monde doit implémenter un protocole, ce qui donne N+M implémentations, et le coût de la création d’un nouveau client équivaut juste à l’implémentation d’un protocole.

Si chaque serveur a un protocole différent, alors vous devez créer N*(M+1) implémentations, et chaque nouveau client a le choix : implémenter N protocoles et être interopérable, ou implémenter (< N) protocoles [et ne pas prendre en charge tous les services, ndr]. Nous voyons déjà ça avec IMAP ; certains clients implémentent seulement la version de Gmail de l’IMAP, parce qu’elle est juste assez différente pour permettre d’implémenter des fonctionnalités qui ne sont pas possibles en IMAP standard.

Cette situation, c’est ce qui se passe dans la messagerie instantanée, avec par exemple Pidgin qui, malgré sa prise en charge de 12 protocoles différents, n’est pas compatible avec beaucoup de services populaires (Facebook, messages privés Twitter, Signal, WhatsApp…). Même un client qui prend en charge de nombreux protocoles de messagerie ne peut pas tout faire. Je serais très déçu si l’email empruntait la même voie.

Vous avez présenté publiquement JMAP fin 2014. Où en est le projet aujourd’hui ?

Nous avons commencé par donner des conférences et discuter avec de gros fournisseurs de mails pour valider nos pistes, puis nous avons déposé un projet de spécifications à l’IETF [l’organisation qui élabore les standards d’internet, ndr] début 2017. JMAP est en cours de développement sous la conduite d’un groupe de travail de l’IETF.

Les spécifications pour le mail sont presque terminées. Nous avons aussi un projet de spécifications pour le calendrier et les contacts qui est disponible en ligne, mais pas encore déposé à l’IETF.

Nous prévoyons de faire passer les spécifications pour le mail au statut de « Proposition de normalisation », ce qui signifie publier un RFC et des implémentations interopérables, d’ici fin 2018. Je suis l’un des responsables du groupe de travail JMAP.

Mais nous n’oublions pas non plus les standards existants. L’IETF a mis en place un groupe de travail baptisé EXTRA qui est chargé de maintenir le protocole IMAP et ses extensions. Je suis l’un des directeurs d’EXTRA. Les deux groupes travaillent étroitement ensemble et ont l’intention de garder les standards synchronisés afin que le modèle de données requis pour fournir un serveur de messagerie fonctionne avec les deux protocoles.

Est-ce que Google et les autres grosses entreprises, Apple, Microsoft, etc. ont exprimé leur intérêt pour JMAP ? Dans le cas contraire, est-ce possible de bâtir un standard sans eux ?

Nous avons discuté avec des ingénieurs de beaucoup de grosses entreprises, et avons pris en compte leurs retours pour concevoir JMAP. Nous ne pouvons pas parler des feuilles de route spécifiques à leurs produits.

C’est tout à fait possible de bâtir un nouveau standard sans les grandes entreprises, mais ce n’est pas conseillé. Ce qui est bien avec JMAP, c’est que même si personne ne l’utilise, il nous permettra toujours de fournir un super service à nos clients.

JMAP est très économe en bande passante, parcimonieux avec la batterie des terminaux mobiles, immédiat grâce à l’intégration des notifications push, facile à intégrer pour les nouveaux clients, et optimisé sur le serveur avec de bons modèles de données. Tout le monde y gagne !

Nous nous attendons donc à ce qu’une fois le standard JMAP publié, d’autres fournisseurs de mail le prennent en charge en raison de ses avantages. Nous nous sommes assurés durant sa conception qu’il soit facile à intégrer pour les gros fournisseurs.

La tendance de fond dans les messageries électroniques ces dernières années est une meilleure protection des données, notamment par l’adoption du chiffrement de bout en bout. Dans le sillon de Telegram, iMessage ou encore ProtonMail, des messageries aussi populaires que WhatsApp et Facebook Messenger s’y sont mises. En 2016, vous expliquiez dans un billet de blog pourquoi FastMail ne prenait pas en charge PGP, le protocole le plus populaire pour chiffrer des emails (pas de recherche possible, ni de consultation de mails en cas de perte de la clé, ni d’anti-spam basé sur le contenu, entre autres raisons invoquées). Est-ce que c’est toujours votre position aujourd’hui ? De nouveaux projets open source, comme Pretty Easy Privacy et OpenPGP.js, ne rendent-ils pas les choses plus simples ?

Si, ils facilitent les choses, mais ils ne changent pas l’aspect fondamental qui est que notre rôle est de vous fournir un protocole permettant de transférer les messages chiffrés, ce que nous faisons déjà [rien n’empêche en effet de chiffrer son courrier FastMail avec un client tiers, ndr].

Nous pourrions envisager une option où vous stockeriez vos clés sur nos serveurs et où nous chiffrerions vos mails à votre place, mais l’intersection est minuscule entre l’ensemble des personnes qui veulent réellement du chiffrement de bout en bout en dépit des inconvénients associés, et l’ensemble des personnes qui nous feraient confiance pour stocker leurs clés. Ce serait juste une fonctionnalité développée pour cocher une nouvelle case « sécurité », or nous ne voulons pas développer des fonctions de « sécurité » qui n’apportent pas de vrais bénéfices dans ce domaine.

Application FastMail sur iPad.

ProtonMail a une approche intéressante, et il y a quelques avantages à leur marque de confidentialité absolue. Mais je me demande vraiment combien de leurs clients ont perdu leurs mails à la suite de la perte de leur clé. Et bien sûr, ProtonMail ne peut pas offrir les mêmes fonctions de recherche et de calendrier que nous, parce que le serveur doit connaître le contenu des emails.

Notre positionnement, c’est un équilibre pragmatique entre la confidentialité, la disponibilité et l’intégrité. Cela signifie que nous avons un moyen de vous redonner accès à vos emails si vous avez perdu vos informations de connexion, ce qui arrive très souvent. Nous proposons également des fonctionnalités qui nécessitent que le serveur indexe et inspecte vos emails afin de mieux vous servir.

C’est un ensemble de choix de sécurité entre un serveur qui sait beaucoup de choses sur vous (par exemple Google qui inclut dans Gmail des infos personnelles qu’il a apprises ailleurs) et un serveur qui ne sait rien de vous (c’est l’approche de Tutanota et ProtonMail consistant à ne pas faire confiance au serveur et à l’utiliser uniquement comme intermédiaire pour transférer les données chiffrées).

FastMail est dans une position intermédiaire où vous devez faire confiance à nos serveurs, parce qu’ils font beaucoup pour améliorer votre expérience, mais nous ne collaborons pas avec des tierces parties ni ne transmettons vos données. Nous sommes garants de votre vie privée, et nous continuons à améliorer nos procédures de sorte que quand notre équipe technique résout des problèmes pour vous, elle ne puisse pas voir accidentellement vos données si elle n’en pas besoin.

Ce qui est intéressant de noter, c’est que si vous envoyez un email de FastMail à Gmail, il est transféré de nos serveurs via un lien chiffré — et il y a tellement de gens qui envoient des emails entre ces deux services que vous êtes fondus dans la masse et relativement peu sensible à une analyse de trafic visant à découvrir avec qui vous échangez.

Si vous avez votre serveur privé et que vous envoyez un email à un journaliste qui a lui aussi un serveur privé, votre conversation est peut-être chiffrée de bout en bout, mais le trafic révèle avec qui vous discutez. La confidentialité ne dépend pas à 100 % du chiffrement de bout en bout !

avatar pakal | 

j’utilise Fastmail depuis plusieurs années et malgré l’application ios un peu lente je suis extrêmement satisfait

avatar creatix | 

@pakal

Pareil, c’est un fournisseur de messagerie sérieux, je suis chez eux depuis plusieurs années et je n’ai pas constaté de panne. Les prix sont raisonnables, juste dommage d’avoir les serveurs aux États Unis

avatar PierreBondurant | 

Vraiment intéressant cet article.
Ça me rappelle quand on avait essayé avec des potes d’intégrer PGP à nos messageries emails et on avait laissé tomber aux bouts de quelques mois, trop compliqués pour nous!

avatar Brice21 | 

@PierreBondurant

Mailfence.com te permet en quelques secondes de créer vos clés et échanger des e-mails encrypted end-to-end.

avatar PierreBondurant | 

@Brice21

Bon a savoir, merci. J’essayerais à l’occasion

avatar occam | 

Les concepts de durabilité et d’immutabilité du mail sont pertinents, mais tels que formulés par Gondwana, assez carbonifères, pour ne pas dire cénozoïques.

Bron insiste sur la sécurité, et il a raison. Mais il en est à sa 4e (en fait : |||| ) saison, et la seule certitude, c’est qu’il y aura invariablement des victimes, horriblement mutilées, au-dessus de l’Øresund.

Enfin, on peut espérer qu’il n’y ait pas de bataille de JMAP.
Et si JMAP arrive à quai, FastMail pourra établir son QG à l’Hôtel du Nord, au 110.
(Si Gondwana nous a bien démontré une chose, c'est qu'il est vital de ne pas perdre son Nord.)

avatar C1rc3@0rc | 

@occam

Les concepts de durabilité et d’immutabilité du mail sont pertinents... que s'ils sont interoperables et intrinsequement chiffrés.

Le chiffrement ne sert pas qu'a masquer le contenu pour les personnes illegitimes c'est aussi le seul moyen durable d'etablir que le contenu n'est pas altéré par un tiers.

Des qu'il est question de serveur central - et qui plus est - est en charge du chiffrement, ça veut dire que les données sont a considerées comme corrompues et publiques.

Le seul remplaçant pour le protocole mail aujourd'hui sera un protocole P2P qui sera chiffré de bout-en-bout et qui ne sera pas lisible a aucun moment par les intermediaires.
Un systeme P2P ne veut pas dire qu'on ne peut pas mettre des serveurs pour accellerer le traffic, mais ces serveurs n'ont pas plus de droits ou de possibilités que n'importe quel autres noeud du reseau.

L'argument qui est que l'utilisateur perdra definitivement ses données s'il perd la cle, ne peut en aucun cas etre une justification a la conservation des cle par un tiers. La securite est une culture, le jour ou les gens seront eduqués et comprendront que s'ils perdent leur cle il perdent leurs données, ils feront en sorte de ne pas pouvoir perdre leurs cles...

avatar phil3 | 

Est-ce qu'ils gèrent les tags ?

C'est LA fonction qui me manque. On trouve des solutions sur Mac mais qui ne se retrouve pas sur l'iPhone.

avatar phil3 | 

Est-ce qu'ils gèrent les tags ?

C'est LA fonction qui me manque. On trouve des solutions sur Mac mais qui ne se retrouve pas sur l'iPhone.

avatar Brice21 | 

@phil3

Mailfence.com gère les tags.

avatar getnuts | 

Est-ce qu'ils gèrent les tags ?

C'est LA fonction qui me manque. On trouve des solutions sur Mac mais qui ne se retrouve pas sur l'iPhone.

avatar C1rc3@0rc | 

@getnuts/phil3

«
Est-ce qu'ils gèrent les tags ?

C'est LA fonction qui me manque. On trouve des solutions sur Mac mais qui ne se retrouve pas sur l'iPhone.
»

Le tag est une donnee de gestion, elle doit pas resider dans le protocle, mais au niveau du logiciel de gestion.
On peut par contre souhaiter que le protocole integre un niveau de priorité et des meta-informations du moment qu'elles ne compromettent pas la securité des données. Donc on peut pas avoir des tag de description de contenu dans le protocole...

avatar phil3 | 

@C1rc3@0rc

Pourquoi ne pourrait-on pas l'avoir dans le protocole ? Il suffit de prévoir un champ spécifique pour les tags, remplis par le logiciel client et actualisé sur le serveur, comme c'est le cas pour l'information lu/non lu. Dans ce cas, ça permet de synchroniser entre les machines.

C'est d'ailleurs ce que Google a fait avec les labels.

avatar Brice21 | 

@phil3

Mailfence.com procède ainsi. Il est aussi possible de rédiger et datacher une note en plus de tags, associé à un email.

avatar phil3 | 

@Brice21

Merci pour cette info. Mais les tags sont exploitables à partir de quel logiciel client sur Mac ? Et sur iPhone ?

avatar Brice21 | 

@phil3

Safari. Mailfence est un webmail, comme Gmail.

avatar marc_os | 

Et il n'est toujours pas question d'annuler l'envoi d'un message quand on s'est rendu compte d'une erreur immédiatement après l'envoi...
Ça n'intéresse personne ?
Je suis le seul à qui il est arrivé de me dire « zut, zut, zut, je me suis trompé de destinataire » ou « j'ai oublié la pièce jointe » ?
Cette possibilité existe (existait?) il me semble sur les messageries d'entreprise passant par MS-Exchange, mais je ne l'ai jamais vue nulle part ailleurs ! :/

avatar C1rc3@0rc | 

@marc_os

«Et il n'est toujours pas question d'annuler l'envoi d'un message quand on s'est rendu compte d'une erreur immédiatement après l'envoi...»

Cette fonction n'est pas tres difficile a realiser mais elle pose beaucoup de probleme sur la nature du message, sa validité et la securité.

Basiquement le processus c'est d'envoyer une information au destinataire (le logiciel) lui ordonnant d'effacer le message designé (reference)

Cela peut se faire si le message n'a pas ete lu, mais dans le cas ou il a deja ete lu?

Ensuite comment garantir la validité d'un message s'il peut etre effacé arbitrairement par son expediteur? Donc le message perd sa valeur (legale par exemple)

En terme de securité cela implique qu'un tiers distant puisse effacer des données locales...

On pourrait aussi imaginer une fonction "anti-etourdis" ou le message a envoyer dispose d'un delai avant envoi (dans un systeme P2P) ou avant reception (dans un systeme a serveur central).
La on a un probleme sur la rapidite de delivrance de la donnée.
Il est plus logique de réaliser la fonction au niveau du logiciel que du protocole. On pourrait avoir par exemple une demande de "review" intervenant 15 minutes apres la redaction ou le message est presenté sous sa forme "reçue" et demandant explicitement de valider l'envoi...

En fait il faut faire une bonne separation entre ce qui releve du protocole et du logiciel de gestion du message.
Pour qu'un protocole soit efficace et securisé il doit faire le minimum de choses et toujours dans son périmètre d'action.
Ici on demande au protocole de garantir:
- que le contenu ne sera accessible qu'aux personnes legitime
- que le contenu ne sera pas altéré ni dans le transfert ni dans le temps
- que le contenu puisse etre certifié
- que le contenu sera delivré au bon destinataire
- que le contenu sera consultable n'importe quand, avec n'importe quelle machine a n'iporte quelle epoque du moment que l'utilisateur dispose de la cle de chiffrement...

Toutes les autres fonctions doivent etre realisees au niveau du logiciel de gestion.

avatar xDave | 

Il y a un moyen très simple et qu'Eudora* pratiquait en son temps...
Mettre les mails en Queue au lien de faire un SEND direct.
ça serait simple et efficace.

ça permet d'avoir une "latitude de réflexe" … d'ailleurs, même pas moyen de faire un stop de l'envoi en cours sur MAlL, c'est complètement stupide. Oui on est en ADSL/4G (RTC is dead) mais envoyer une PJ prend suffisamment de temps pour pouvoir cliquer sur "annuler" et ce n'est même pas possible actuellement.

* Ah Eudora avait quelques bonnes idées, comme une fenêtre avec listing des boites mails dans lesquelles on vient de recevoir quelque chose au lieu de jouer à a devinette dans une arbo de dizaines de dossiers (avec des non-lus).

avatar Adrienhb | 

Gmail le fait très bien.

avatar Bruno de Malaisie | 

@marc_os

Airmail fait cela très bien.

avatar marc_os | 

On ne peut pas dire que l'interface de FastMail respecte les canons de macOS !

avatar oomu | 

bof.

je citerai l'obligatoire xkcd ( y a ptet encore 1 ou 2 geeks ne l'ayant pas lu) : https://xkcd.com/927/

mais surtout plutôt que de succomber à JSON (sans m'en expliquer les qualités hormis une convergence vers les technos de base du web), pourquoi ne pas être resté dans le cadre de imap qui est:
- basé fichier
- extensible
- beaucoup plus fonctionnel que les gens l'imaginent
- possèdent plusieurs implémentations de sécurité dont du bout à bout que presque personne n'a tenté d'amener aux utilisateurs de manière fiable et facile. (alors qu'Apple le fait avec imessage).

mais bon, un énième standard par une entité qui n'a pas d'intérêt économique à lui voir échapper, pourquoi pas hein, j'aime quand le monde répète sans cesse ce qui a déjà été fait.

j'attendrai donc les promesses de publication de RFC et de travail continu au sein de l'IETF.

-
" à réaliser quelque chose sans avoir à passer une année à comprendre et réimplémenter tout IMAP et MIME. "

Quel que soit le nom du bidule, les développeurs devront passe une année à comprendre les certificats, les clés privées/publics, le chiffrage et ses enjeux, les types et encodages et l'internationalisation/unicode.

Ce n'est pas parce que le protocole en dessous est tout pourri : ce sont des réalités de l'informatique que vous êtes obligé de digérer dans un monde riche, contradictoire et complexe.

avatar Brice21 | 

@oomu

Mailfence.com utilise l’IMAP et offre l’encryption end-to-end sans possibilités aux intermédiaires de décrypter le message, y compris nous mêmes!

avatar Adrienhb | 

Bon je vais faire hurler, mais je m'y retrouvais très bien avec pop. Certes il y avait un peu de gymnastique mais j'aime bien avoir mes mails en local sur mon disque dur et pouvoir y répondre tranquillement sans avoir besoin d'une connexion. Ou alors je n'ai toujours rien compris à l'imap, ce qui n'est pas impossible.

Pages

CONNEXION UTILISATEUR