Stocker ses e-mails dans son bucket S3 : ce qui y arrive, et comment

Un message arrive pour vous et, une seconde plus tard environ, un nouvel objet apparaît dans un bucket de votre propre compte cloud. Cet objet est la partie intéressante de l’e-mail BYOS (bring your own storage) : ce qu’il contient, la façon dont il a été écrit, et ce que vous pouvez en faire — des choses qu’aucun hébergeur de messagerie ne vous laisserait faire sur ses disques.

Qu’est-ce qui atterrit réellement dans votre bucket ?

Des blobs chiffrés, plus l’index qui en fait une boîte aux lettres. Chaque message est compressé avec zstd, chiffré avec une clé propre à la boîte à l’aide de age (le format de chiffrement de fichiers fondé sur X25519), puis écrit sous un préfixe blobs/ avec un nom dérivé d’une empreinte de son contenu. Des octets identiques reçoivent le même nom. Rien dans la clé de l’objet n’indique ce qu’il contient : ni l’objet du message, ni l’expéditeur, ni l’adresse à laquelle il était destiné.

L’index est la partie qu’on oublie en imaginant ce montage. Une boîte aux lettres n’est pas un tas de blobs : quelque chose doit savoir quel blob est quel message, à quelle conversation il appartient, lesquels sont non lus, lesquels sont étiquetés. Cette structure est écrite dans le même stockage et chiffrée de la même façon. C’est pourquoi « mon courrier est dans mon bucket » est une affirmation plus forte qu’elle n’en a l’air : l’archive n’est pas seulement récupérable, elle se décrit elle-même à quiconque détient la clé.

Une question à poser à tout prestataire qui fait cette offre, avant de lui confier un domaine : la disposition sur le stockage est-elle documentée ? Des octets que vous ne pouvez lire qu’avec le logiciel d’un seul éditeur sont une forme de propriété plus faible qu’il n’y paraît.

Comment un message passe-t-il de l’expéditeur à votre stockage ?

Cinq étapes, et l’ordre des deux dernières est ce qui compte.

Notre hôte MX répond à la connexion SMTP et contrôle le message : SPF, DKIM et DMARC sur le courrier entrant, réputation de l’expéditeur et listes de blocage, puis analyse du spam et de l’hameçonnage. Le filtrage doit lire du texte en clair : tout se passe donc ici, avant le moindre chiffrement au repos. Un service qui filtre votre spam a vu votre courrier ; quiconque affirme les deux décrit une chose impossible.

Ensuite l’adresse du destinataire est résolue en boîte aux lettres, le message est compressé et chiffré avec la clé de cette boîte, et l’objet est écrit dans votre stockage — un PUT vers S3 ou vers un point d’accès compatible S3, vers R2, vers un serveur WebDAV, ou un commit dans un dépôt Git.

Ce n’est qu’après la réussite de cette écriture que le point d’entrée répond 250 OK. Ce point d’entrée est sans état et ne tient aucune file à lui : cela ressemble à une limite, c’est en réalité la garantie de fiabilité — il ne peut pas accuser réception d’un message qu’il n’a pas stocké. Quand votre stockage est en panne, le message attend encore dans la file du serveur expéditeur, c’est-à-dire à l’endroit le plus durable où il pourrait se trouver.

Que pouvez-vous faire de ce bucket qu’aucun hébergeur ne permettrait ?

Tout ce que l’API de stockage propose, puisque le bucket est le vôtre et que le service de messagerie n’est qu’un client muni d’une clé.

Le versionnage des objets transforme « quelque chose a supprimé un an de courrier » en restauration plutôt qu’en incident. Les règles de cycle de vie réduisent la facture d’une archive que personne ne relit. Une réplication interrégionale ou un rclone sync nocturne pose une seconde copie chez un second opérateur dans un second pays, au même rythme que le reste de vos sauvegardes. Object Lock satisfait une obligation de conservation dont votre hébergeur de messagerie n’a jamais entendu parler. Les journaux d’accès au bucket enregistrent chaque lecture, y compris les nôtres. Le chiffrement côté serveur avec votre propre clé KMS enveloppe notre texte chiffré dans une seconde couche dont vous pouvez révoquer la clé unilatéralement.

Deux de ces leviers ont des bords tranchants. Les transitions vers les classes froides rendent la récupération lente : pointez-les vers une réplique, pas vers les blobs que votre webmail est en train de lire. Et Object Lock en mode conformité signifie que personne ne supprime un objet avant sa date de rétention — vous compris, y compris la version de vous qui a mal réglé cette durée. Ce mode est une décision, pas une case à cocher.

L’autre liberté, c’est l’emplacement. Vous choisissez la région, et séparément vous choisissez qui l’exploite. La région n’est pas la juridiction : une région européenne exploitée par une société de droit américain reste atteignable au titre du CLOUD Act, en vigueur depuis 2018. Choisir les deux, délibérément, est l’essentiel de la raison pour laquelle on veut ce montage.

Le coût, lui, ne se comporte pas comme les pages tarifaires vous ont appris à l’attendre. Le courrier, ce sont des milliers de petits objets : les frais par requête et la sortie de données dominent, pas le tarif au gigaoctet. R2 ne facture aucune sortie du tout.

Qu’est-ce qui reste chez le service de routage ?

Les parties qui doivent vivre sur l’internet public et — par défaut — les clés.

Nous gardons les enregistrements MX, le TLS en bordure, la signature DKIM et l’alignement DMARC de votre courrier sortant, le travail de réputation d’adresse IP, l’analyse du spam et de l’hameçonnage, et le client webmail. Vos identifiants de bucket restent scellés dans notre base, parce que la livraison en a besoin.

La garde des clés est l’astérisque honnête. Sur l’offre par défaut, la garde côté serveur, nous détenons les clés par boîte : c’est ce qui permet d’afficher et de chercher la boîte dans un navigateur ; votre fournisseur de stockage ne voit que du texte chiffré, mais nous pouvons déchiffrer. L’offre de garde côté appareil, en bêta, génère les clés dans votre navigateur et efface notre copie — à partir de là, le service peut écrire dans votre stockage sans pouvoir lire ce qu’il y a écrit. Les deux conceptions se défendent. Une seule signifie « personne d’autre que moi », et la différence mérite d’être connue avant d’être citée dans un document de politique de sécurité.

Comment cela échoue-t-il ?

De trois façons, dans l’ordre où elles arrivent vraiment.

Les identifiants. Vous faites tourner une clé d’accès un mardi et vous oubliez que le chemin du courrier consomme ce bucket. La livraison commence à échouer et, comme le point d’entrée retient son 250 OK, rien n’est perdu immédiatement : vous récupérez du retard et des avis de non-remise, pas un trou dans votre archive. Faites tourner les clés comme pour n’importe quel autre client : ajoutez la nouvelle à la boîte d’abord, révoquez l’ancienne ensuite.

La politique d’accès. Une politique de bucket qui s’avère publique expose du texte chiffré et non des messages, ce qui est la différence entre une gêne et une catastrophe — mais le nombre d’objets, leurs tailles et leurs horodatages restent un jeu de données d’analyse de trafic, et une boîte que vous avez délibérément laissée en clair au repos expose exactement ce que vous imaginez. Une règle de cycle de vie avec action d’expiration supprime du courrier à l’heure dite et ne demande pas deux fois. Une politique de clé KMS qui oublie celui qui écrit arrête net la livraison.

Vous. La garde transfère la responsabilité en même temps que le pouvoir. Supprimer le bucket supprime le courrier, et aucun ticket au support ne restaure une sauvegarde que nous n’avons jamais eue. Ce n’est pas un manque du produit. C’est la chose que vous avez achetée.

Le test que j’appliquerais à tout prestataire qui propose cela : pouvez-vous révoquer ses identifiants de stockage en dix secondes, et votre archive reste-t-elle lisible ensuite ? Si oui, votre courrier est à vous. Si la réponse passe par un outil d’export, c’est un compte que vous possédez.