session.email – Whitepaper técnico

1. Introducción

session.email es un servicio de correo electrónico temporal centrado en la privacidad, que opera bajo principios de zero-log y zero-persistence, diseñado exclusivamente para recibir correos electrónicos. El sistema garantiza que las comunicaciones de los usuarios nunca se almacenen de forma permanente; todos los datos se procesan estrictamente en la RAM con valores de TTL rigurosos.

El servicio se basa en tres pilares principales:

• Privacidad: sin registros (logs), sin I/O de disco, sin recopilación de metadatos.
• Arquitectura técnica: gestión de RAM basada en Redis, streaming SSE, sandbox aislado del lado del cliente.
• Seguridad: aislamiento KVM, hardening de OpenSMTPD, Fail2ban, claves PGP ECC.

Este documento detalla el funcionamiento, el modelo de seguridad y las garantías de privacidad de session.email.

2. Infraestructura y entorno

2.1. Entorno físico y virtual

• Proveedor VPS: RackNerd
• Ubicación: EE. UU.
• Virtualización: KVM (aislamiento de hardware)
• Memoria: 1 GB RAM + 1 GB swap
• Sistema operativo: Debian 12
• Firewall: UFW – todos los puertos no utilizados están cerrados, incluido el puerto 22 (SSH)
• SSH: puerto no estándar, con protección contra fuerza bruta

3. Arquitectura de software

3.1. Componentes principales

• Caddy: proxy inverso HTTP/2 y HTTP/3 (QUIC).
• OpenSMTPD: exclusivamente para la recepción (inbound) de tráfico SMTP.
• Backend en Go: procesamiento de mensajes, integración con Redis, streaming SSE.
• Redis: gestión de datos en memoria, eliminación basada en TTL, sin persistencia.
• GoatCounter: analítica propia, alojada en el VPS, sin cookies y respetuosa con la privacidad ( analytics.session.email ).
• Fail2ban: protección configurada para eventos de OpenSMTPD y errores 404 de Caddy.

4. Flujo de datos (Data Flow)

[OpenSMTPD] → [Go Backend] → [Redis (RAM)] → [SSE Stream] → [Iframe aislado] → [Purify.js + Sanitizer]

4.1. Recepción SMTP

• OpenSMTPD recibe los correos entrantes.
• Tamaño máximo del mensaje: 25 MB – los mensajes que excedan este límite son rechazados.
• Limitación de tasa (rate limiting) por IP activa para prevenir sobrecargas y abusos.
• SMTP de salida completamente deshabilitado – el servicio no envía correos electrónicos.

4.2. Procesamiento del backend

El backend en Go es responsable del procesamiento de los mensajes:

• Análisis de encabezados y cuerpo, "limpieza" del mensaje.
• El mensaje se almacena en la RAM a través de Redis con un TTL estricto.
• El mensaje se transmite al navegador del cliente a través de un canal SSE (Server-Sent Events).

4.3. Funcionamiento de Redis

• AOF (Append Only File): deshabilitado (appendonly no).
• Snapshot RDB: habilitado, pero el sistema no almacena correos de forma permanente; Redis opera únicamente en la RAM.
• Acceso: solo en 127.0.0.1:6379, protegido por contraseña.
• IP rate ban: aplicado también a nivel de Redis.

4.4. Valores TTL

• Dirección gratuita: TTL de 15 minutos (protección contra reconexión en el lado del cliente).
• Dirección premium: TTL de 1 hora.
• Cookie de sesión: 1 hora.

Todos los datos se eliminan automáticamente al expirar el TTL; no existen datos persistentes en espera de ser eliminados manualmente.

5. Garantías de Zero-Persistence

Durante su funcionamiento, session.email:

• no escribe correos en el disco,
• no crea colas de correo (mail spool) ni estructuras maildir,
• no almacena archivos de registro (log files) de los mensajes entrantes,
• no almacena permanentemente direcciones IP, agentes de usuario ni marcas de tiempo,
• no realiza perfiles ni construye bases de datos de usuarios.

6. Seguridad del lado del cliente

6.1. Iframe aislado

Los correos se muestran dentro de un iframe aislado y en modo sandbox, que separa el contenido del mensaje del documento principal.

6.2. Sanitización y protección contra rastreo

• Uso de purify.js para sanitizar el contenido HTML.
• Lógica de sanitización propia para filtrar píxeles de seguimiento y elementos sospechosos.
• Opción de vista HTML a texto plano para una seguridad máxima.

Este enfoque reduce el riesgo de ataques XSS, CSRF, carga de recursos remotos y otros ataques del lado del cliente.

7. Función PGP Premium

Para los usuarios premium, session.email ofrece cifrado PGP vinculado a la sesión y exclusivo en memoria.

• Algoritmo: ECC, Curve25519.
• Biblioteca: openpgp.min.js.
• Generación de claves: cada sesión recibe un par de claves único.

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

La clave privada reside únicamente en la RAM, nunca se escribe en el disco y se rota y elimina automáticamente al finalizar la sesión. El usuario obtiene una clave pública que permite cifrar los mensajes dirigidos a él.

8. Analítica (GoatCounter)

session.email utiliza solo analíticas mínimas y respetuosas con la privacidad:

• Herramienta: GoatCounter.
• Ubicación: VPS propio, bajo el dominio analytics.session.email.
• Datos recopilados: solo estadísticas de visitas a páginas (pageviews).
• Exclusiones: sin cookies de seguimiento, sin fingerprinting, sin intercambio de datos con terceros.

9. Sistema de pagos (Paddle)

Los pagos por funciones premium se procesan a través del sistema Paddle.

• Se utilizan webhooks de Paddle para verificar el estado de las transacciones.
• El servidor de session.email no almacena datos de pago de forma permanente.
• Paddle puede utilizar sus propias cookies para fines de seguridad y gestión de transacciones.
• El servidor solo ve la dirección de correo electrónico necesaria para la transacción, que tampoco se almacena a largo plazo.

10. Modelo de seguridad

10.1. Modelo de amenazas

• Ataques de fuerza bruta / SSH: puerto SSH no estándar, UFW, Fail2ban.
• Inundación SMTP (flood): límite de tasa de IP en OpenSMTPD, tamaño máximo de mensaje de 25 MB.
• Ataque a Redis: acceso solo a localhost, protegido con contraseña, detrás de un firewall.
• Ataques XSS / HTML: iframe aislado, purify.js, lógica de sanitización.
• Fuga de rastreo / metadatos: filtrado de píxeles de seguimiento, opción de HTML a texto plano.
• Forense de disco: sin escritura en disco, sin colas de correo, sin registros.

10.2. Minimización de la superficie de ataque

• Sin SMTP de salida.
• Sin cuentas de usuario, contraseñas ni bases de datos persistentes.
• Sin API para la extracción masiva de datos.
• Todos los datos residen en la RAM con TTL y eliminación automática.

11. Tabla resumen

12. Conclusión

session.email es un servicio de correo electrónico desechable que:

• no almacena datos de forma permanente,
• no registra actividades (log),
• no escribe en el disco,
• no recopila metadatos,
• no permite correos electrónicos de salida,
• opera exclusivamente en RAM con TTLs estrictos,
• ofrece cifrado PGP para usuarios premium,
• se ejecuta sobre una arquitectura moderna y segura (KVM, Caddy, OpenSMTPD, Redis),
• emplea un sandboxing y sanitización estrictos del lado del cliente.

El sistema cumple con los principios de privacidad por diseño y minimización de datos, proporcionando garantías técnicamente únicas y sólidas para el anonimato y la seguridad de los datos de los usuarios.