E-mail résistant aux quanta : comment nous utilisons des boîtes aux lettres SQLite chiffrées pour protéger votre e-mail

Avant-propos

Jusqu’à ce que nous lancions Prise en charge IMAP, nous utilisions MongoDB pour nos besoins de stockage de données persistantes.

Cette technologie est incroyable et nous l’utilisons encore aujourd’hui – mais pour avoir un cryptage au repos avec MongoDB, vous devez utiliser un fournisseur qui propose MongoDB Enterprise, comme Digital Ocean ou Mongo Atlas – ou payer pour une licence d’entreprise (et ensuite devoir travailler avec la latence de l’équipe de vente).

Notre équipe Transférer un e-mail recherchait une solution de stockage chiffrée, évolutive, fiable et conviviale pour les développeurs, destinée aux boîtes aux lettres IMAP. En tant que développeurs open source, l'utilisation d'une technologie nécessitant le paiement d'une licence pour bénéficier de la fonctionnalité de chiffrement au repos était incompatible avec nos principes. Nous avons donc expérimenté, recherché et développé une nouvelle solution de A à Z pour répondre à ces besoins.

Au lieu d'utiliser une base de données partagée pour stocker vos boîtes mail, nous les stockons et les chiffrons individuellement avec votre mot de passe (que vous seul possédez). Notre service de messagerie est tellement sécurisé que si vous oubliez votre mot de passe, vous perdez votre boîte mail (et devez alors la récupérer avec des sauvegardes hors ligne ou recommencer).

Continuez à lire pendant que nous plongeons en profondeur ci-dessous avec un comparaison des fournisseurs de services de messagerie, comment fonctionne notre service, notre pile technologique et plus encore.

Comparaison des fournisseurs de services de messagerie

Nous sommes le seul fournisseur de services de messagerie 100 % open source et axé sur la confidentialité qui stocke des boîtes aux lettres SQLite cryptées individuellement, offre un nombre illimité de domaines, d'alias et d'utilisateurs, et prend en charge les messages sortants SMTP, IMAP et POP3 :

Contrairement à d'autres fournisseurs de messagerie, avec Forward Email, vous n'avez pas besoin de payer pour l'espace de stockage par domaine ou par alias. L'espace de stockage est partagé sur l'ensemble de votre compte. Si vous possédez plusieurs noms de domaine personnalisés et plusieurs alias pour chacun d'eux, nous sommes la solution idéale. Notez que vous pouvez toujours appliquer des limites de stockage par domaine ou par alias si vous le souhaitez.

Lire la comparaison des services de messagerie

Comment ça marche ?

1. À l'aide de votre client de messagerie tel qu'Apple Mail, Thunderbird, Gmail ou Outlook, vous vous connectez à nos serveurs sécurisés IMAP en utilisant votre nom d'utilisateur et votre mot de passe :

• Votre nom d'utilisateur est votre alias complet avec votre domaine, par exemple hello@example.com.
• Votre mot de passe est généré aléatoirement et ne s'affiche que pendant 30 secondes lorsque vous cliquez sur Générer un mot de passe depuis Mon compte Domaines Alias.

2. Une fois connecté, votre client de messagerie enverra Commandes du protocole IMAP à notre serveur IMAP pour synchroniser votre boîte mail. Cela inclut la rédaction et le stockage de brouillons d'e-mails, ainsi que d'autres actions que vous pourriez effectuer (par exemple, marquer un e-mail comme important ou comme spam).

3. Les serveurs d'échange de courrier (communément appelés serveurs « MX ») reçoivent les nouveaux e-mails entrants et les stockent dans votre boîte mail. Votre client de messagerie est alors averti et synchronise votre boîte mail. Nos serveurs d'échange de courrier peuvent transférer vos e-mails à un ou plusieurs destinataires (y compris webhooks), les stocker pour vous dans votre espace de stockage IMAP chiffré, ou les deux !

4. En coulisses, notre conception de stockage de courrier électronique sécurisé fonctionne de deux manières pour garder vos boîtes aux lettres cryptées et accessibles uniquement par vous :

• Lorsque vous recevez un nouveau courrier de la part d'un expéditeur, nos serveurs d'échange de courrier écrivent dans une boîte aux lettres individuelle, temporaire et cryptée pour vous.

  

• Lorsque vous vous connectez à notre serveur IMAP avec votre client de messagerie, votre mot de passe est chiffré en mémoire et utilisé pour lire et écrire dans votre boîte aux lettres. Ce mot de passe est indispensable pour la lecture et l'écriture dans votre boîte aux lettres. N'oubliez pas que, puisque vous êtes le seul à disposer de ce mot de passe, vous seul pouvez y accéder en lecture et en écriture. Lors de votre prochaine tentative de consultation ou de synchronisation, vos nouveaux messages seront transférés depuis cette boîte aux lettres temporaire et stockés dans votre fichier de boîte aux lettres actuel avec le mot de passe que vous avez fourni. Notez que cette boîte aux lettres temporaire est purgée et supprimée par la suite, de sorte que seule votre boîte aux lettres protégée par mot de passe conserve les messages.

• Si vous êtes connecté en IMAP (par exemple, via un client de messagerie comme Apple Mail ou Thunderbird), nous n'avons pas besoin d'écrire sur le disque dur temporaire. Votre mot de passe IMAP chiffré en mémoire est récupéré et utilisé. En temps réel, lorsqu'un message tente de vous parvenir, nous envoyons une requête WebSocket à tous les serveurs IMAP pour leur demander s'ils ont une session active pour vous (c'est la phase de récupération), puis nous transmettons ensuite ce mot de passe chiffré en mémoire. Nous n'avons donc pas besoin d'écrire dans une boîte aux lettres temporaire ; nous pouvons écrire dans votre boîte aux lettres chiffrée actuelle avec votre mot de passe chiffré.

  

5. Les Sauvegardes de vos boîtes mail cryptées sont créés quotidiennement. Vous pouvez également demander une nouvelle sauvegarde à tout moment ou télécharger la dernière sauvegarde depuis Mon Compte Domaines Alias. Si vous décidez de changer de service de messagerie, vous pouvez facilement migrer, télécharger, exporter et purger vos boîtes aux lettres et vos sauvegardes à tout moment.

Technologies

Bases de données

Nous avons exploré d’autres couches de stockage de base de données possibles, mais aucune n’a satisfait nos exigences autant que SQLite :

Base de données	Chiffrement au repos	Sandboxed Boîtes aux lettres	Licence	Used Everywhere
SQLite ⭐	✅ Oui avec SQLite3MultipleCiphers	✅	✅ Domaine public	✅
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Base de données relationnelle	❌ AGPL et SSPL-1.0	❌
rqlite	❌ Network only	❌ Base de données relationnelle	✅ MIT	❌
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	✅ LGPL-3.0-only	❌
PostgreSQL	✅ Yes	❌ Base de données relationnelle	✅ PostgreSQL (similaire à BSD ou MIT)	❌
MariaDB	✅ For InnoDB only	❌ Base de données relationnelle	✅ GPLv2 et BUSL-1.1	❌
CockroachDB	❌ Enterprise-only feature	❌ Base de données relationnelle	❌ BUSL-1.1 et autres	❌

Voici un article de blog comparant plusieurs options de stockage de bases de données SQLite dans le tableau ci-dessus.

Sécurité

Nous utilisons en permanence les chiffrements chiffrement au repos (AES-256), cryptage en transit (TLS), DNS sur HTTPS (« DoH ») avec Tangerine et Squelet (ChaCha20-Poly1305) pour les boîtes aux lettres. Nous utilisons également l'authentification à deux facteurs par jeton (contrairement aux SMS, suspectés par attaques de l'homme du milieu), la rotation des clés SSH avec accès root désactivé, l'accès exclusif aux serveurs via des adresses IP restreintes, et bien plus encore.

En cas de attaque de la servante maléfique ou d'employé malveillant d'un fournisseur tiers, votre boîte aux lettres ne peut être ouverte qu'avec votre mot de passe généré. Soyez rassuré, nous ne dépendons d'aucun fournisseur tiers autre que nos fournisseurs de serveurs certifiés SOC de type 2 : Cloudflare, DataPacket, Digital Ocean et Vultr.

Notre objectif est d'avoir le moins de point de défaillance unique possible.

Boîtes aux lettres

tldr; Nos serveurs IMAP utilisent des bases de données SQLite cryptées individuellement pour chacune de vos boîtes aux lettres.

Base de données intégrée SQLite est un langage extrêmement populaire – elle est actuellement en cours d'exécution sur votre téléphone et votre ordinateur – et utilisé par presque toutes les principales technologies.

Par exemple, sur nos serveurs chiffrés, il existe une boîte aux lettres de base de données SQLite pour linux@example.com, info@example.com, hello@example.com, etc. – une pour chaque fichier de base de données .sqlite. Nous ne nommons pas les fichiers de base de données avec l'adresse e-mail ; nous utilisons plutôt l'ObjectID BSON et les UUID uniques générés, qui ne divulguent ni l'identité du destinataire ni l'adresse e-mail à laquelle la boîte aux lettres est associée (par exemple, 353a03f21e534321f5d6e267.sqlite).

Chacune de ces bases de données est chiffrée à l'aide de votre mot de passe (que vous seul possédez) (Squelet (ChaCha20-Poly1305). Vos boîtes aux lettres sont ainsi chiffrées individuellement, autonomes (bac à sable et portables.

Nous avons peaufiné SQLite avec le PRAGMA suivant :

PRAGMA	But
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. Référence better-sqlite3-multiple-ciphers sous Projects pour plus d'informations.
key="****************"	Il s'agit de votre mot de passe déchiffré, stocké en mémoire, transmis à notre serveur via la connexion IMAP de votre client de messagerie. De nouvelles instances de base de données sont créées et fermées à chaque session de lecture et d'écriture (afin de garantir le sandboxing et l'isolation).
journal_model=WAL	Journal d'écriture anticipée ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Empêche les erreurs de verrouillage en écriture while other writes are taking place.
synchronous=NORMAL	Augmente la durabilité des transactions without data corruption risk.
foreign_keys=ON	Oblige à ce que les références de clés étrangères (par exemple, une relation d'une table à une autre) soient appliquées. By default this is not turned on in SQLite, mais pour la validation et l'intégrité des données, il doit être activé.
encoding='UTF-8'	Default encoding à utiliser pour garantir la santé mentale du développeur.

Toutes les autres valeurs par défaut proviennent de SQLite comme spécifié dans documentation officielle de PRAGMA.

Concurrence

tldr; Nous utilisons WebSocket pour les lectures et écritures simultanées dans vos boîtes aux lettres SQLite chiffrées.

lit

Votre client de messagerie sur votre téléphone peut résoudre imap.forwardemail.net en l'une de nos adresses IP Digital Ocean – et votre client de bureau peut résoudre une IP distincte à partir d'un fournisseur complètement différent.

Quel que soit le serveur IMAP auquel votre client de messagerie se connecte, nous souhaitons que la connexion lise votre base de données en temps réel avec une précision de 100 %. Cela se fait via WebSockets.

Écrit

L'écriture dans votre base de données est un peu différente, car SQLite est une base de données intégrée et votre boîte aux lettres réside dans un seul fichier par défaut.

Nous avons exploré des options telles que litestream, rqlite et dqlite ci-dessous – mais aucune d’entre elles ne répondait à nos exigences.

Pour effectuer des écritures avec la journalisation anticipée (« WAL ») activée, nous devons nous assurer qu'un seul serveur (« principal ») est responsable de ces opérations. WAL accélère considérablement la concurrence et autorise un auteur et plusieurs lecteurs.

Le serveur principal s'exécute sur les serveurs de données avec les volumes montés contenant les boîtes aux lettres chiffrées. Du point de vue de la distribution, on peut considérer tous les serveurs IMAP individuels derrière imap.forwardemail.net comme des serveurs secondaires (« Secondaire »).

Nous réalisons une communication bidirectionnelle avec WebSockets :

• Les serveurs principaux utilisent une instance du serveur WebSocketServer de ws.
• Les serveurs secondaires utilisent une instance du client WebSocket de ws, encapsulée avec websocket-comme-promis et reconnexion-websocket. Ces deux encapsuleurs garantissent que WebSocket se reconnecte et peut envoyer et recevoir des données pour des écritures de base de données spécifiques.

Sauvegardes

tldr; Des sauvegardes de vos boîtes aux lettres chiffrées sont effectuées quotidiennement. Vous pouvez également demander instantanément une nouvelle sauvegarde ou télécharger la dernière sauvegarde à tout moment depuis Mon compte Domaines Alias.

Pour les sauvegardes, nous exécutons simplement la commande SQLite VACUUM INTO chaque jour lors du traitement des commandes IMAP, qui exploite votre mot de passe chiffré via une connexion IMAP en mémoire. Les sauvegardes sont conservées si aucune sauvegarde existante n'est détectée ou si le hachage SHA-256 du fichier a changé par rapport à la sauvegarde la plus récente.

Notez que nous utilisons la commande VACUUM INTO plutôt que la commande intégrée backup, car si une page est modifiée pendant une opération backup, elle doit être relancée. La commande VACUUM INTO prend un instantané. Consultez les commentaires sur GitHub et Hacker News pour plus d'informations.

De plus, nous utilisons VACUUM INTO par opposition à backup, car la commande backup laisserait la base de données non chiffrée pendant une brève période jusqu'à ce que rekey soit invoqué (voir ce GitHub commentaire pour plus d'informations).

Le secondaire demandera au primaire via la connexion WebSocket d'exécuter la sauvegarde – et le primaire recevra alors la commande pour le faire et ensuite :

1. Connectez-vous à votre boîte aux lettres chiffrée.
2. Obtenez un verrou en écriture.
3. Exécutez un point de contrôle WAL via wal_checkpoint(PASSIVE).
4. Exécutez la commande SQLite VACUUM INTO.
5. Assurez-vous que le fichier copié peut être ouvert avec le mot de passe chiffré (protection/protection contre les erreurs).
6. Téléchargez-le sur Cloudflare R2 pour le stockage (ou chez votre fournisseur si spécifié).

N'oubliez pas que vos boîtes aux lettres sont chiffrées - et bien que nous ayons mis en place des restrictions IP et d'autres mesures d'authentification pour la communication WebSocket - en cas d'acteur malveillant, vous pouvez être assuré qu'à moins que la charge utile WebSocket ne contienne votre mot de passe IMAP, elle ne peut pas ouvrir votre base de données.

Une seule sauvegarde est actuellement stockée par boîte aux lettres, mais à l'avenir, nous pourrions proposer une récupération à un moment donné (« PITR »).

Rechercher

Nos serveurs IMAP prennent en charge la commande SEARCH avec des requêtes complexes, des expressions régulières, etc.

Les performances de recherche rapides sont dues à FTS5 et sqlite-regex.

Nous stockons les valeurs Date dans les boîtes aux lettres SQLite sous forme de chaînes ISO 8601 via Date.prototype.toISOString (avec le fuseau horaire UTC pour que les comparaisons d'égalité fonctionnent correctement).

Les index sont également stockés pour toutes les propriétés qui figurent dans les requêtes de recherche.

Projets

Voici un tableau décrivant les projets que nous utilisons dans notre code source et notre processus de développement (classés par ordre alphabétique) :

Projet	But
Ansible	Plateforme d'automatisation DevOps pour la maintenance, la mise à l'échelle et la gestion de l'ensemble de notre flotte de serveurs en toute simplicité.
Bree	Planificateur de tâches pour Node.js et JavaScript avec cron, dates, ms, later et support convivial.
Cabin	Bibliothèque de journalisation JavaScript et Node.js conviviale pour les développeurs, avec la sécurité et la confidentialité à l'esprit.
Lad	Framework Node.js qui alimente toute notre architecture et notre conception technique avec MVC et plus encore.
MongoDB	Solution de base de données NoSQL que nous utilisons pour stocker toutes les autres données en dehors des boîtes aux lettres (par exemple, votre compte, vos paramètres, vos domaines et vos configurations d'alias).
Mongoose	Modélisation de documents objets MongoDB (« ODM ») que nous utilisons sur l'ensemble de notre pile. Nous avons développé des outils d'aide spécifiques qui nous permettent de continuer à utiliser Mongoose avec SQLite.
Node.js	Node.js est l'environnement d'exécution JavaScript open source et multiplateforme qui exécute tous nos processus serveur.
Nodemailer	Package Node.js pour l'envoi d'e-mails, la création de connexions et bien plus encore. Nous sommes sponsors officiels de ce projet.
Redis	Base de données en mémoire pour la mise en cache, les canaux de publication/abonnement et les requêtes DNS sur HTTPS.
SQLite3MultipleCiphers	Extension de chiffrement pour SQLite permettant de chiffrer des fichiers de base de données entiers (y compris le journal d'écriture anticipée ("WAL"), le journal, la restauration, …).
SQLiteStudio	Éditeur Visual SQLite (que vous pouvez également utiliser) pour tester, télécharger et afficher les boîtes aux lettres de développement.
SQLite	Couche de base de données intégrée pour un stockage IMAP évolutif, autonome, rapide et résilient.
Spam Scanner	Outil anti-spam, de filtrage des e-mails et de prévention du phishing Node.js (notre alternative à Spam Assassin et rspamd).
Tangerine	Requêtes DNS sur HTTPS avec Node.js et mise en cache à l'aide de Redis – ce qui garantit la cohérence globale et bien plus encore.
Thunderbird	Notre équipe de développement utilise ceci (et le recommande également) comme client de messagerie préféré à utiliser avec Forward Email.
UTM	Notre équipe de développement utilise ces machines virtuelles créées pour iOS et macOS afin de tester différents clients de messagerie (en parallèle) avec nos serveurs IMAP et SMTP.
Ubuntu	Système d'exploitation serveur moderne et open source basé sur Linux qui alimente toute notre infrastructure.
WildDuck	Bibliothèque de serveur IMAP – voir ses notes sur attachment de-duplication et IMAP protocol support.
better-sqlite3-multiple-ciphers	Bibliothèque API rapide et simple pour Node.js pour interagir avec SQLite3 par programmation.
email-templates	Cadre de messagerie convivial pour les développeurs pour créer, prévisualiser et envoyer des e-mails personnalisés (par exemple, des notifications de compte et plus encore).
json-sql-enhanced	Générateur de requêtes SQL utilisant une syntaxe de type Mongo. Cela permet à notre équipe de développement de gagner du temps, car nous pouvons continuer à écrire en style Mongo sur l'ensemble de la pile, avec une approche indépendante de la base de données. Cela permet également d'éviter les attaques par injection SQL grâce à l'utilisation de paramètres de requête.
knex-schema-inspector	Utilitaire SQL permettant d'extraire des informations sur les schémas de bases de données existants. Cela nous permet de valider facilement la validité de tous les index, tables, colonnes, contraintes, etc., et de les comparer à 1:1. Nous avons même développé des assistants automatisés pour ajouter de nouvelles colonnes et index en cas de modification des schémas de bases de données (avec des alertes d'erreur extrêmement détaillées).
knex	Générateur de requêtes SQL que nous utilisons uniquement pour les migrations de bases de données et la validation de schéma via knex-schema-inspector.
mandarin	Traduction automatique de phrases i18n avec prise en charge de Markdown à l'aide de Google Cloud Translation API.
mx-connect	Package Node.js pour résoudre et établir des connexions avec les serveurs MX et gérer les erreurs.
pm2	Gestionnaire de processus de production Node.js avec équilibreur de charge intégré (fine-tuned pour les performances).
smtp-server	Bibliothèque de serveur SMTP – nous l'utilisons pour notre échange de courrier (« MX ») et nos serveurs SMTP sortants.
ImapTest	Outil utile pour tester les serveurs IMAP par rapport aux benchmarks et à la compatibilité du protocole IMAP avec les spécifications RFC. Ce projet a été créé par l'équipe [Dovecot](https://en.wikipedia.org/wiki/Dovecot_\(software\) (un serveur IMAP et POP3 open source actif depuis juillet 2002). Nous avons testé notre serveur IMAP de manière approfondie avec cet outil.

Vous pouvez trouver d'autres projets que nous utilisons dans notre code source sur GitHub.

Fournisseurs

Fournisseur	But
Cloudflare	Fournisseur DNS, contrôles de santé, équilibreurs de charge et stockage de sauvegarde à l'aide de Cloudflare R2.
Digital Ocean	Hébergement de serveurs dédiés et bases de données gérées.
Vultr	Hébergement de serveur dédié.
DataPacket	Hébergement de serveur dédié.

Pensées

Principes

Forward Email est conçu selon ces principes :

1. Soyez toujours à l'écoute des développeurs, axé sur la sécurité et la confidentialité, et transparent.
2. Adhérez aux valeurs MVC, Unix, KISS, DRY, YAGNI, Facteur douze, Le rasoir d'Occam et alimentation pour chiens.
3. Ciblez les développeurs à la recherche de solutions improvisées et de solutions ramen-rentable.

Expériences

tldr; En fin de compte, l'utilisation d'un stockage d'objets compatible S3 et/ou de tables virtuelles n'est pas techniquement possible pour des raisons de performances et est sujette à des erreurs en raison de limitations de mémoire.

Nous avons réalisé quelques expériences menant à notre solution SQLite finale, comme indiqué ci-dessus.

L’une d’entre elles consistait à essayer d’utiliser rclone et SQLite avec une couche de stockage compatible S3.

Cette expérience nous a permis de mieux comprendre et de découvrir des cas limites entourant l'utilisation de rclone, SQLite et VFS :

• Si vous activez l'indicateur --vfs-cache-mode writes avec rclone, les lectures seront autorisées, mais les écritures seront mises en cache.
• Si vous disposez de plusieurs serveurs IMAP répartis dans le monde entier, le cache sera désactivé sur chacun d'eux, sauf si vous disposez d'un seul enregistreur et de plusieurs écouteurs (par exemple, une approche pub/sub).
• C'est extrêmement complexe, et toute complexité supplémentaire entraînera davantage de points de défaillance uniques.
• Les fournisseurs de stockage compatibles S3 ne prennent pas en charge les modifications partielles de fichiers ; toute modification du fichier .sqlite entraînera donc une modification complète et un nouveau téléchargement de la base de données.
• D'autres solutions, comme rsync, existent, mais elles ne prennent pas en charge l'écriture anticipée (« WAL »). Nous avons donc finalement testé Litestream. Heureusement, notre système de chiffrement chiffre déjà les fichiers WAL ; nous n'avons donc pas besoin de compter sur Litestream pour cela. Cependant, nous n'étions pas encore sûrs de Litestream pour une utilisation en production et vous trouverez ci-dessous quelques remarques à ce sujet.
• L'utilisation de l'option --vfs-cache-mode writes (la seule façon d'utiliser SQLite par rapport à rclone pour les écritures) tentera de copier l'intégralité de la base de données en mémoire. La gestion d'une boîte aux lettres de 10 Go est acceptable. Cependant, la gestion de plusieurs boîtes aux lettres avec un espace de stockage extrêmement important entraînera des limitations de mémoire pour les serveurs IMAP, ainsi que des erreurs ENOMEM, des erreurs de segmentation et une corruption des données. * Si vous tentez d'utiliser SQLite Tables virtuelles (par exemple, s3db) pour que les données soient stockées sur une couche de stockage compatible S3, vous rencontrerez plusieurs problèmes supplémentaires :
• Les lectures et écritures seront extrêmement lentes, car les points de terminaison de l'API S3 devront être atteints avec les méthodes HTTP .sqlite0, .sqlite1, .sqlite2 et .sqlite3.
• Les tests de développement ont montré que dépasser 500 000 à plus d'un million d'enregistrements sur la fibre optique reste limité par le débit d'écriture et de lecture des fournisseurs compatibles S3. Par exemple, nos développeurs ont exécuté des boucles .sqlite4 pour exécuter à la fois des instructions SQL séquentielles .sqlite5 et des instructions d'écriture massive de grandes quantités de données. Dans les deux cas, les performances étaient extrêmement lentes. * Les tables virtuelles ne peuvent pas contenir d'index, d'instructions .sqlite6 et .sqlite7 .sqlite8, ce qui entraîne des retards de 1 à 2 minutes, voire plus, selon la quantité de données.
• Les objets étaient stockés non chiffrés et aucun chiffrement natif n'était disponible.
• Nous avons également envisagé d'utiliser .sqlite9, dont le concept et la technique sont similaires à ceux du point précédent (il présente donc les mêmes problèmes). Une possibilité serait d'utiliser une version personnalisée rsync0, encapsulée dans un chiffrement tel que rsync1 (que nous utilisons actuellement dans notre solution ci-dessus), via rsync2.
• Une autre approche possible serait d'utiliser rsync3, mais cette solution est limitée à 32 Go et nécessiterait des tâches complexes de construction et de développement.
• Les instructions rsync4 sont obligatoires (ce qui exclut totalement l'utilisation de tables virtuelles). Nous avons besoin des instructions rsync5 pour que notre hook avec rsync6 fonctionne correctement, ce qui garantit que les données ne sont pas corrompues et que les lignes récupérées peuvent être converties en documents valides conformément à nos définitions de schéma rsync7 (qui incluent les contraintes, le type de variable et la validation arbitraire des données).
• Presque tous les projets compatibles S3 liés à SQLite dans la communauté open source sont en Python (et non en JavaScript, que nous utilisons pour 100 % de notre pile).
• Les bibliothèques de compression telles que rsync8 (voir rsync9) semblent prometteuses, mais __PROTECTED_LINK_189__0. Au lieu de cela, la compression côté application sur des types de données tels que __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5 et __PROTECTED_LINK_189__6 sera une approche plus propre et plus simple (et plus facile à migrer, car nous pourrions stocker un indicateur ou une colonne __PROTECTED_LINK_189__7, voire utiliser __PROTECTED_LINK_189__8, __PROTECTED_LINK_189__9 pour la compression ou __PROTECTED_LINK_190__0 pour l'absence de compression comme métadonnées de base de données).
• Heureusement, la déduplication des pièces jointes est déjà implémentée sur notre serveur IMAP. Ainsi, chaque message contenant la même pièce jointe n'en conservera pas une copie ; une seule pièce jointe est stockée pour plusieurs messages et threads dans une boîte aux lettres (et une référence étrangère est ensuite utilisée).
• Le projet Litestream, une solution de réplication et de sauvegarde SQLite, est très prometteur et nous l'utiliserons probablement à l'avenir. * Sans vouloir discréditer les auteurs – car nous apprécions leur travail et leurs contributions à l'open source depuis plus de dix ans maintenant –, il ressort de l'utilisation réelle qu'il existe __PROTECTED_LINK_190__1 et __PROTECTED_LINK_190__2.
• La restauration des sauvegardes doit être simple et rapide. Utiliser une solution comme MongoDB avec __PROTECTED_LINK_190__3 et __PROTECTED_LINK_190__4 est non seulement fastidieux, mais aussi chronophage et complexe à configurer.
• Les bases de données SQLite simplifient les choses (il s'agit d'un fichier unique).
• Nous souhaitions concevoir une solution permettant aux utilisateurs de prendre leur boîte aux lettres et de la quitter à tout moment.
• De simples commandes Node.js pour __PROTECTED_LINK_190__5 effacent définitivement le contenu du disque dur.
• De même, nous pouvons utiliser une API compatible S3 avec HTTP __PROTECTED_LINK_190__6 pour supprimer facilement les snapshots et les sauvegardes pour les utilisateurs.
• SQLite était la solution la plus simple, la plus rapide et la plus économique.

Manque d'alternatives

À notre connaissance, aucun autre service de messagerie n’est conçu de cette manière et n’est pas open source.

Nous pensons que cela pourrait être dû au fait que les services de messagerie existants disposent d'une technologie héritée en production avec code spaghetti 🍝.

La plupart, sinon la totalité, des fournisseurs de services de messagerie existants sont soit à code source fermé, soit annoncés comme étant à code source ouvert, mais en réalité, seul leur interface est à code source ouvert.

La partie la plus sensible du courrier électronique (l'interaction réelle entre le stockage/IMAP/SMTP) se fait entièrement sur le back-end (serveur) et pas sur le front-end (client).

Essayez le transfert d'e-mails

Inscrivez-vous dès aujourd'hui sur https://forwardemail.net! 🚀