session.email – Technical Whitepaper

1. Introduction

session.email is a privacy-first, zero-log, zero-persistence temporary email service designed exclusively for receiving incoming emails. The system ensures that user communication is never stored permanently; all data is processed strictly in RAM with strict TTL values.

The service rests on three main pillars:

• Privacy: no logs, no disk I/O, no metadata collection.
• Technical Architecture: Redis-based RAM management, SSE streaming, isolated client-side sandbox.
• Security: KVM isolation, OpenSMTPD hardening, Fail2ban, ECC PGP keys.

This document details the operation, security model, and privacy guarantees of session.email.

2. Infrastructure and Environment

2.1. Physical and Virtual Environment

• VPS Provider: RackNerd
• Location: USA
• Virtualization: KVM (hardware isolation)
• Memory: 1 GB RAM + 1 GB swap
• Operating System: Debian 12
• Firewall: UFW – all unused ports closed, including port 22 (SSH)
• SSH: non-standard port, brute-force protection

3. Software Architecture

3.1. Main Components

• Caddy: HTTP/2 and HTTP/3 (QUIC) reverse proxy.
• OpenSMTPD: exclusively for receiving (inbound) SMTP traffic.
• Go backend: message processing, Redis integration, SSE streaming.
• Redis: in-memory data management, TTL-based deletion, no persistence.
• GoatCounter: self-hosted, cookie-free, privacy-friendly analytics ( analytics.session.email ).
• Fail2ban: configured for OpenSMTPD and Caddy 404 event protection.

4. Data Flow

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

4.1. SMTP Reception

• OpenSMTPD receives incoming emails.
• Maximum message size: 25 MB – messages exceeding this are rejected.
• IP rate limiting is active to prevent overload and abuse.
• Outbound SMTP is completely disabled – the service does not send emails.

4.2. Backend Processing

The Go backend is responsible for message processing:

• Header and body parsing, "stripping" the message.
• The message is stored in RAM via Redis with a strict TTL.
• The message is streamed to the client's browser via an SSE (Server-Sent Events) channel.

4.3. Redis Operation

• AOF (Append Only File): disabled (appendonly no).
• RDB snapshot: enabled, but the system does not store emails permanently; Redis operates solely in RAM.
• Access: only at 127.0.0.1:6379, password protected.
• IP rate ban: applied at the Redis level as well.

4.4. TTL Values

• Free address: 15-minute TTL (client-side reconnection protection).
• Premium address: 1-hour TTL.
• Session cookie: 1 hour.

All data is automatically deleted upon TTL expiration; there is no persistent data awaiting manual deletion.

5. Zero-Persistence Guarantees

During its operation, session.email:

• does not write emails to disk,
• does not create mail spools or maildir structures,
• does not store log files for incoming messages,
• does not store IP addresses, user agents, or timestamps permanently,
• does not perform profiling or build user databases.

6. Client-Side Security

6.1. Isolated Iframe

Emails are displayed within an isolated, sandboxed iframe, which separates the message content from the main document.

6.2. Sanitization and Tracking Protection

• Use of purify.js to sanitize HTML content.
• Custom sanitization logic to filter out tracking pixels and suspicious elements.
• Option for HTML to plain text view for maximum security.

This approach reduces the risk of XSS, CSRF, remote resource loads, and other client-side attacks.

7. Premium PGP Feature

For premium users, session.email provides session-bound, memory-only PGP encryption.

• Algorithm: ECC, Curve25519.
• Library: openpgp.min.js.
• Key generation: each session receives a unique key pair.

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

The private key exists only in RAM, is never written to disk, and is automatically rotated and deleted at the end of the session. The user receives a public key that can be used to encrypt messages sent to them.

8. Analytics (GoatCounter)

session.email uses only minimal, privacy-friendly analytics:

• Tool: GoatCounter.
• Location: self-hosted VPS, analytics.session.email domain.
• Collected data: pageview statistics only.
• Exclusions: no tracking cookies, no fingerprinting, no third-party data sharing.

9. Payment System (Paddle)

Payments for premium features are processed through Paddle.

• Paddle webhooks are used to verify transaction status.
• The session.email server does not store payment data permanently.
• Paddle may use its own cookies for security and transaction management purposes.
• The server only sees the email address required for the transaction, which is not stored long-term.

10. Security Model

10.1. Threat Model

• Brute force / SSH attacks: non-standard SSH port, UFW, Fail2ban.
• SMTP flood: OpenSMTPD IP rate limit, max 25 MB message size.
• Redis attack: localhost access only, password protected, behind a firewall.
• XSS / HTML attacks: isolated iframe, purify.js, sanitization logic.
• Tracking / metadata leakage: filtering tracking pixels, HTML to plain text option.
• Disk forensics: no disk writes, no mail spool, no logs.

10.2. Attack Surface Minimization

• No outbound SMTP.
• No user accounts, passwords, or persistent databases.
• No API for bulk data retrieval.
• All data resides in RAM with TTL and automatic deletion.

11. Summary Table

12. Conclusion

session.email is a disposable email service that:

• does not store data permanently,
• does not log,
• does not write to disk,
• does not collect metadata,
• does not allow outbound emails,
• operates exclusively in RAM with strict TTLs,
• provides PGP encryption for premium users,
• runs on a modern, secure architecture (KVM, Caddy, OpenSMTPD, Redis),
• employs strict client-side sandboxing and sanitization.

The system adheres to privacy-by-design and data-minimization principles, providing technically unique and strong guarantees for user anonymity and data security.