Unhosted

Aventures Unhosted

Une traduction approximative du Journal de bord officiel du No Cookie Crew

d’après Unhosted Adventures
by Michiel B. de Jong

9. L'envoi et la réception de courrier électronique à partir d'applications Web Unhosted

Unhosting e-mail

La tête d'affiche des applications web hébergées est sans doute GMail. Elle a été l'une des premières applications à utiliser AJAX à son plein potentiel, et a redéfini nos attentes sur ce qui peut et ne peut pas être fait à l'intérieur d'un navigateur. Cela signifie aussi qu'elle est l'une des applications web hébergées des plus difficile à remplacer.

L'idée d'e-mail non-hébergé (“unhosting”) est simple : prendre, essentiellement, l'application javascript côté client que par exemple GMail met dans votre navigateur, et rendre son “backend” échangeable, pour que l'utilisateur puisse connecter son propre “backend” lors de l'exécution.

Pour le stockage des e-mails, à la fois ceux reçus et ceux envoyés, nous allons utiliser remoteStorage. Pour envoyer les messages sortants et recevoir les messages entrants, nous allons utiliser Sockethub. Ce type de schéma doit commencer à vous être familier maintenant si vous avez suivi les épisodes précédents de ce manuel.

Que mettre sur le port 25

Au moment où j'écris ceci, cela fait trois mois que j'ai commencé à utiliser des applications web Unhosted dans la mesure de tout ce qui est possible. Durant tout ce temps, j'ai expérimenté différents serveurs de courrier entrant - la plupart étant basés sur le module simplesmtp de nodejs. Cela c'est plutôt bien passé, j'avais prévu de perdre au cours de cette période un petit pourcentage de mon courrier entrant, et également averti les gens de cette éventualité.

Les quantités de spam sont également encore gérable ; j'ai inscrit ce nom de domaine 6 mois plutôt, et seulement 50% des messages entrants sont du spam, et ce n'est pas encore trop fastidieux pour moi de cliquer directement sur eux.

Héberger des serveurs de messagerie n'est, néanmoins, pas très amusant. C'est pourquoi cette semaine, j'ai décidé de transférer mon nom de domaine chez Gandi et bénéficier de leur offre standard d'hébergement de courrier. Il vous est également possible d'utiliser GMail comme un serveur de courrier entrant et sortant, ce qui est en soi équivalent.

Pointer les enregistrements MX de votre domaine auprès d'un fournisseur d'hébergement de courriels résout une partie non-négligeable du problème d'ingénierie, et signifie qu'il ne nous est pas utile de faire tourner quoi que ce soit sur le port 25 (le port TCP standard du courrier électronique entrant). Au lieu de cela, notre serveur Sockethub ne se préoccupe que de récupérer le courriel depuis ce fournisseur d'hébergement de messageries, en utilisant POP3 ou IMAP.

Envoi de mail

L'externalisation de l'hébergement de messagerie de votre domaine IndieWeb vers un fournisseur d'hébergement standard résout également un autre problème : il vous donne un relais sortant de confiance. Au bon vieux temps, vous pouviez envoyer des e-mails directement depuis votre client de messagerie au serveur de réception de messagerie. De nos jours, c'est tout à fait impossible.

Premièrement, le serveur mail de réception distant risque probablement de bloquer simplement votre adresse IP en se basant sur le fait qu'elle est probablement classée comme appartenant à un bloc IP “résidentiel”. Deuxièmement, votre FAI est susceptible de ne même pas permettre à votre ordinateur de se connecter à un quelconque port 25 distant via TCP.

Mais même si tel n'était pas le cas, vous auriez à configurer toutes sortes de choses comme le “reverse DNS” correspondant à votre domaine de messagerie pour avoir au mois une chance de livrer un message électronique quelque part.

Des services tel que Mailgun et SendGrid règle ce problème. Ils sont spécialisés dans le relais d'emails sortants. Leurs principaux clients sont généralement des développeurs d'applications web hébergées qui ont besoin d'envoyer des messages de notification à leurs utilisateurs, mais si vous demandez gentiment, il y de grande chance pour qu'ils vous donnent aussi un compte pour votre courrier personnel sortant.

J'ai eu recours à SendGrid ces trois derniers mois (si vous avez reçu email de moi, vous avez sans doute remarqué l'en-tête “via sendgrid.me”), mais le transfert de mon courrier entrant chez Gandi me permet de bénéficier également d'un serveur relais sortant que je peux facilement utiliser.

Insérer Sockethub dans le schéma

Les applications web unhosted peuvent uniquement ouvrir les connexions http, depuis quelques années les connexions websocket, et depuis quelques semaines, les “PeerConnections”. Elles ne peuvent pas ouvrir des connexions SMTP, les connexions IMAP, ou les connexions POP3.

Sockethub joue ce rôle en établissant une connexion WebSocket du côté de l'application web unhosted avec une connexion SMTP, IMAP ou POP3 du côté serveur distant, et relaie la communication dans les deux sens. Il joue le rôle d'un hub entre WebSockets d'une part, et les sockets TCP de l'autre.

Pour le courrier sortant, l'application web unhosted envoie une “activité” avec le verbe «envoyer» à Sockethub, met le message dans le champ objet de “l'activité”, les différents types de destinataires dans le champ cible, et le champ “From: adresse” dans le champ acteur.

Alors Sockethub transforme cette “activité” en un message SMTP (en utilisant Nodemailer), et le transmet au serveur relais spécifié par vos soins. Le serveur relais sert alors principalement à se conformer à toutes les règles anti-spam obligatoires, et à mettre en attente le message dans le cas où le serveur de réception se trouve temporairement indisponible ou inaccessible.

Pour le courrier électronique entrant, vous indiquez à Sockethub de récupérer le courrier depuis votre serveur de messagerie, et de le mettre sur votre compte RemoteStorage. Au moment de la rédaction de cet article, cette partie n'est pas encore implémentée : J'utilise encore un script séparé qui gère cette étape.

Principales caractéristiques d'un message électronique

Le système de messagerie est super vieux, du moins à l'échelle de l'histoire d'Internet, et il a de nombreuses caractéristiques et options différentes. Au début, j'ai pris en charge l'envoi des messages e-mail de mon adresse e-mail vers l'adresse e-mail du destinataire avec seulement le corps-de-texte et le sujet.

Cependant après quelques plaintes de plusieurs de mes amis, j'ai réalisé que je devais vraiment ajouter un “En-réponse-à” et les “Références” des en-têtes lorsque je répondait à une discussion. Je n'avais pas réalisé que c'était si important, mais si vous ne le faites pas, alors les clients de messagerie des autres personnes vont démarrer une nouvelle discussion à chaque fois que vous allez répondre. La valeur de ces champs d'en-tête devrait être le “Message-ID” du message auquel vous répondez.

L'ajout du nom de l'expéditeur et du destinataire est également utile ; depuis que j'utilise comme adresse e-mail 'anything@michielbdejong.com', je me retrouve enregistrer au sein des carnets d'adresses des gens comme étant l'utilisateur “anything” (“n'importe quoi”). Avouons-le, c'est moche. La manière la plus appropriée consiste à préciser plutôt “Michiel de Jong B. anything@michielbdejong.com” par exemple. Et faire de même pour les adresses des destinataires.

La dernière option que j'ai ajouté à mon application d'envoi d'emails est le support de plusieurs “To: adresses” ainsi que plusieurs “Cc: adresses”. Il semble que SendGrid n'implémente pas les “Cci:”, et personnellement je n'ai jamais utiliser cette fonction, du coup je ne l'ai pas intégré, du moins pour les e-mails sortants.

Pour les messages entrants, j'utilise une autre application. C'est un peu contraignant parce que je dois couper-coller chaque message auquel je réponds, mais puisque c'est un-travail-en-cours, je fais avec. Je stocke les e-mails entrants sur mon RemoteStorage dans les modules “messages” (que l'on pourrait, à un moment donné, renommer en “boîte de réception” ou en autre-chose), et pour garder le contrôle sur la surcharge de synchronisation, je m'organise avec deux strates de dossiers : une strate pour le Mégaseconde, et une pour le Kiloseconde.

Cela signifie qu'à chaque clic de bouton je peux récupérer tous les e-mails du Kiloseconde en cours (environ 17 minutes), ce qui correspond rarement à plus de deux ou trois messages.

En plus de cela, à chaque Megasecond (environ 11 jours), mon e-mail est archivé dans un dossier différent. Les messages sont enregistrés avec des noms de fichiers ayant une précision à la milliseconde, c'est-à-dire que si vous m'envoyez un e-mail maintenant, il sera alors stocké sur mon RemoteStorage dans un dossier portant un nom ressemblant à quelque chose comme: messages/1360/680/123456.json. À chaque fois que je reçois un e-mail ne-contenant-que-du-html (“html-only”), ou un e-mail contenant des pièces jointes, je dois me connecter à mon VPS via la connexion webshell, pour pouvoir consulter ce contenu supplémentaire.

Je vous détaille tout cela pour préciser que, malgré le fait que nous ayons ce groupe de travail, et que j'ai été amené à utiliser cette application comme mon client de messagerie depuis quelques mois, celui-ci est loin d'être “exploitable” pour les utilisateurs finaux, il reste encore un bon bout de chemin à parcourir avant de pouvoir dire que nous avons “résolu” le défi d'écrire un client de messagerie unhosted.

Filtrage anti-spam

Si vous hébergez votre propre serveur, il est recommandé de faire tourner sur celui-ci un logiciel du genre filtre anti-spam. Afin de tenir un discours rigoureux, nous pourrions avancer que cette fonction correspond à une tâche de niveau applicatif et que celle-ci devrait donc être traitées directement par l'application web unhosted qui agit ici comme client de messagerie, mais étant donné que le filtrage anti-spam est de nos jours une partie intégrante des plate-formes e-mail, je pense que nous pouvons justifier le fait de confier cette tâche au serveur.

Quoi qu'il en soit, si vous externalisez votre hébergement de messagerie vers un fournisseur d'hébergement, ils prendront soin du filtrage anti-spam pour vous.

Pretty Good Privacy (PGP pour : “Assez Bonne Intimité”)

La semaine dernière, Eben Moglen et Bdale Garbee ont effectué une présentation au FOSDEM sur le sujet de la FreedomBox 1.0. Comme nous l'avons mentionné la semaine dernière, le concept général de l'utilisation d'une FreedomBox, c'est-à-dire d'un plug-server ou de tout autre type de matériel toujours branché, vous permettant de faire tourner du logiciel libre chez vous, est une pièce centrale du casse-tête que nous tentons de résoudre à l'aide des applications web unhosted.

Au cours de la présentation, Bdale a clairement indiqué que PGP allait jouer un rôle central dans la manière dont la FreedomBox pourra apporter la liberté à ses utilisateurs. Et je sens que cela prend totalement sens. PGP est un système éprouvé pour le “cryptage bout-à-bout” (“end-to-end encryption”) des messages électroniques que s'envoient les gens. D'elle-même, les plate-formes de messagerie ne prennent pas vraiment en charge le cryptage et la protection des “écoutes”.

En outre, la migration grandissante des utilisateurs abandonnant les clients de messagerie de type logiciel-de-bureau comme Thunderbird et Outlook, vers des services de messagerie Web comme Gmail, rend le cryptage “bout-à-bout” (“end-to-end encryption”) impossible.

Mais avec sockethub, et à condition que vous exécutiez votre serveur sockethub depuis chez vous, ou du moins au sein de votre réseau de confiance local, il est alors possible de mettre en œuvre un cryptage “bout-à-bout” (“end-to-end encryption”) de manière totalement transparente pour que les applications web Unhosted puissent envoyer et recevoir les e-mails.

Jusqu'à présent, j'ai ajouté “PGP clearsigning” à Sockethub, en utilisant le paquet “gpg” de nodejs. C'est encore un prototype récent, et notamment en ce qui concerne la génération et le stockage des clés qui va nécessiter encore pas mal de travail, mais je pense qu'il est nécessaire pour nous de l'inclure comme un élément essentiel de notre plate-forme.

Lorsque les destinataires d'un e-mail ne sont pas tous en possession d'une clé PGP, le message doit être envoyé en-clair (“cleartext”), et PGP ne peut être utilisé que pour signer le message, de manière à ce que les destinataires puissent vérifier depuis quel ordinateur (ou dans le cas présent, depuis quel serveur sockethub), il a été envoyé.

Lorsque l'expéditeur connaît les clés PGP de tous les destinataires, le message peut être chiffré avant d'être signé et envoyé, pour le protéger contre des tiers qui lisent le contenu des messages. Ils seront bien sûr toujours en mesure de détecter le fait qu'un message a été envoyé à un certain moment, et de déterminer de manière approximative la longueur de celui-ci, mais nous bénéficions quand même ici d'une nette amélioration de ce qui a prévalu jusqu'à aujourd'hui par défaut, où des sociétés commerciales et des gouvernements d'états de divers pays avaient un accès complet leur permettant d'explorer pratiquement tout que nous faisions en ligne.

Recherche dans la boîte de réception

Une caractéristique que de nombreux utilisateurs actuels de Gmail ont pris d'affection, est la fonction de recherche dans la boîte de réception. Pour l'instant, j'utilise grep pour effectuer des recherches dans mes e-mails au sein du système de fichiers de mon serveur, et malgré le fait que celui-ci ne soit pas aussi bon que la fonction de recherche de Gmail, celui-ci fonctionne plutôt bien dans l'ensemble.

Dans un futur proche, il est possible que nous souhaitions pouvoir créer des index de recherche basés sur des mots clés ou tout du moins basés sur le couple destinataire/bénéficiaire, et rendre ainsi la recherche plus facile.

Et comme de plus en plus de personnes vont (un jour!) commencer à rejoindre le No Cookie Crew, en utilisant leur propre adaptation “maison” des application de messagerie Unhosted, et en soumettant un va-et-vient d'améliorations pour celles-ci, nous verrons alors probablement apparaître la prise en charge du tri par sujet à l'aide des balises et/ou des dossiers de messagerie, ainsi que, soyons optimistes, de belles intégrations avec des applications de carnets d'adresses Unhosted.

Le principal message qu'il faut, je pense, ici retenir est que, cela fonctionne, mais le chemin à parcourir est encore long avant que la plupart d'entre vous qui lisez ces lignes soyez prêt à utiliser votre propre application e-mail unhosted.

Mais l'utilisation conjointe d'une messagerie e-mail et de PGP est une partie essentielle pour une décentralisation de la liberté en ligne, et il est important que quelques-uns d'entre nous traversent ces douloureuses expériences de sorte que, comme Eben le note dans l'interview du FOSDEM, “au moment où vous saurez que vous avez besoin d'une FreedomBox, nous en auront une à portée de main pour vous.”. Le No Cookie Crew est à la recherche de membres, pionniers et courageux, pour permettre que cela soit aussi une réalité pour les applications Web Unhosted. :)

Commentaires bienvenus!

Suivant: Lier des choses ensemble sur le world wide web_ (traduction encours)