session.email – Livre blanc technique

1. Introduction

session.email est un service d'e-mail temporaire axé sur la confidentialité, fonctionnant sur des principes de zero-log et zero-persistence, conçu exclusivement pour la réception d'e-mails entrants. Le système garantit que les communications des utilisateurs ne sont jamais stockées de manière permanente ; toutes les données sont traitées strictement en RAM avec des valeurs de TTL strictes.

Le service repose sur trois piliers principaux :

• Confidentialité : aucun journal (log), aucune E/S disque, aucune collecte de métadonnées.
• Architecture technique : gestion RAM basée sur Redis, streaming SSE, sandbox isolé côté client.
• Sécurité : isolation KVM, renforcement (hardening) d'OpenSMTPD, Fail2ban, clés PGP ECC.

Ce document détaille le fonctionnement, le modèle de sécurité et les garanties de confidentialité de session.email.

2. Infrastructure et environnement

2.1. Environnement physique et virtuel

• Fournisseur VPS : RackNerd
• Emplacement : États-Unis
• Virtualisation : KVM (isolation matérielle)
• Mémoire : 1 Go RAM + 1 Go swap
• Système d'exploitation : Debian 12
• Pare-feu : UFW – tous les ports inutilisés sont fermés, y compris le port 22 (SSH)
• SSH : port non standard, protection contre la force brute

3. Architecture logicielle

3.1. Composants principaux

• Caddy : proxy inverse HTTP/2 et HTTP/3 (QUIC).
• OpenSMTPD : exclusivement pour la réception (inbound) du trafic SMTP.
• Backend Go : traitement des messages, intégration Redis, streaming SSE.
• Redis : gestion des données en mémoire, suppression basée sur le TTL, aucune persistance.
• GoatCounter : analytique auto-hébergée, sans cookie et respectueuse de la vie privée ( analytics.session.email ).
• Fail2ban : protection configurée pour OpenSMTPD et les événements 404 de Caddy.

4. Flux de données (Data Flow)

[OpenSMTPD] → [Backend Go] → [Redis (RAM)] → [Flux SSE] → [Iframe isolé] → [Purify.js + Sanitizer]

4.1. Réception SMTP

• OpenSMTPD reçoit les e-mails entrants.
• Taille maximale du message : 25 Mo – les messages dépassant cette limite sont rejetés.
• Limitation de débit (rate limiting) par IP active pour prévenir les surcharges et abus.
• SMTP sortant complètement désactivé – le service n'envoie pas d'e-mails.

4.2. Traitement backend

Le backend Go est responsable du traitement des messages :

• Analyse des en-têtes et du corps, "nettoyage" du message.
• Le message est stocké en RAM via Redis avec un TTL strict.
• Le message est diffusé au navigateur du client via un canal SSE (Server-Sent Events).

4.3. Fonctionnement de Redis

• AOF (Append Only File) : désactivé (appendonly no).
• Instantané (Snapshot) RDB : activé, mais le système ne stocke pas les e-mails de manière permanente ; Redis fonctionne uniquement en RAM.
• Accès : uniquement sur 127.0.0.1:6379, protégé par mot de passe.
• IP rate ban : appliqué également au niveau de Redis.

4.4. Valeurs TTL

• Adresse gratuite : TTL de 15 minutes (protection contre la reconnexion côté client).
• Adresse premium : TTL de 1 heure.
• Cookie de session : 1 heure.

Toutes les données sont automatiquement supprimées à l'expiration du TTL ; il n'y a pas de données persistantes en attente de suppression manuelle.

5. Garanties de Zero-Persistence

Durant son fonctionnement, session.email :

• n'écrit pas d'e-mails sur le disque,
• ne crée pas de files d'attente de courrier (mail spool) ni de structures maildir,
• ne stocke pas de journaux (log files) des messages entrants,
• ne stocke pas de manière permanente les adresses IP, les agents utilisateurs ou les horodatages,
• ne réalise pas de profilage et ne constitue pas de bases de données d'utilisateurs.

6. Sécurité côté client

6.1. Iframe isolé

Les e-mails sont affichés dans un iframe isolé et en mode sandbox, ce qui sépare le contenu du message du document principal.

6.2. Nettoyage et protection contre le suivi

• Utilisation de purify.js pour assainir (sanitiser) le contenu HTML.
• Logique de nettoyage personnalisée pour filtrer les pixels de suivi et les éléments suspects.
• Option de vue HTML vers texte brut pour une sécurité maximale.

Cette approche réduit le risque d'attaques XSS, CSRF, chargement de ressources distantes et autres attaques côté client.

7. Fonction PGP Premium

Pour les utilisateurs premium, session.email fournit un chiffrement PGP lié à la session et exclusif à la mémoire.

• Algorithme : ECC, Curve25519.
• Bibliothèque : openpgp.min.js.
• Génération de clés : chaque session reçoit une paire de clés unique.

const { privateKey, publicKey } = await openpgp.generateKey({
    type: 'ecc',
    curve: 'curve25519',
    userIDs: [{ name: 'Session User' }],
});

La clé privée réside uniquement en RAM, n'est jamais écrite sur le disque, et est automatiquement permutée et supprimée à la fin de la session. L'utilisateur reçoit une clé publique qui peut être utilisée pour chiffrer les messages qui lui sont adressés.

8. Analytique (GoatCounter)

session.email utilise uniquement des analytiques minimales et respectueuses de la vie privée :

• Outil : GoatCounter.
• Emplacement : VPS propre, sous le domaine analytics.session.email.
• Données collectées : statistiques de pages vues uniquement.
• Exclusions : aucun cookie de suivi, aucun fingerprinting, aucun partage de données avec des tiers.

9. Système de paiement (Paddle)

Les paiements pour les fonctionnalités premium sont traités via le système Paddle.

• Les webhooks de Paddle sont utilisés pour vérifier le statut des transactions.
• Le serveur session.email ne stocke pas les données de paiement de manière permanente.
• Paddle peut utiliser ses propres cookies à des fins de sécurité et de gestion des transactions.
• Le serveur ne voit que l'adresse e-mail nécessaire à la transaction, qui n'est pas non plus stockée à long terme.

10. Modèle de sécurité

10.1. Modèle de menaces

• Attaques par force brute / SSH : port SSH non standard, UFW, Fail2ban.
• Inondation SMTP (flood) : limitation de débit IP dans OpenSMTPD, taille maximale de message de 25 Mo.
• Attaque Redis : accès localhost uniquement, protégé par mot de passe, derrière un pare-feu.
• Attaques XSS / HTML : iframe isolé, purify.js, logique de nettoyage.
• Fuite de suivi / métadonnées : filtrage des pixels de suivi, option HTML vers texte brut.
• Forensique disque : aucune écriture sur disque, aucune file d'attente de courrier, aucun journal.

10.2. Minimisation de la surface d'attaque

• Aucun SMTP sortant.
• Aucun compte utilisateur, mot de passe ou base de données persistante.
• Aucune API pour l'extraction massive de données.
• Toutes les données résident en RAM avec TTL et suppression automatique.

11. Tableau récapitulatif

12. Conclusion

session.email est un service d'e-mail jetable qui :

• ne stocke pas les données de manière permanente,
• ne journalise pas,
• n'écrit pas sur le disque,
• ne collecte pas de métadonnées,
• n'autorise pas les e-mails sortants,
• fonctionne exclusivement en RAM avec des TTL stricts,
• fournit un chiffrement PGP pour les utilisateurs premium,
• fonctionne sur une architecture moderne et sécurisée (KVM, Caddy, OpenSMTPD, Redis),
• emploie des méthodes strictes de sandboxing et de nettoyage côté client.

Le système adhère aux principes de confidentialité par conception (privacy-by-design) et de minimisation des données, fournissant des garanties techniquement uniques et solides pour l'anonymat et la sécurité des données des utilisateurs.