Version: 1.0 · Datum: 2026 · Betreiber: László Zsidi (Ungarn) ·
Kontakt: laszlo@zsidi.hu
1. Einleitung
session.email ist ein datenschutzorientierter Zero-Log, Zero-Persistence temporärer E-Mail-Dienst,
der ausschließlich für den Empfang von eingehenden E-Mails konzipiert ist. Das System stellt sicher, dass die Kommunikation der Benutzer niemals
dauerhaft gespeichert wird; alle Daten werden ausschließlich im RAM mit strikten TTL-Werten verarbeitet.
Der Dienst stützt sich auf drei Hauptpfeiler:
- Datenschutz: keine Logs, kein Disk-I/O, keine Metadatensammlung.
- Technische Architektur: Redis-basiertes RAM-Management, SSE-Streaming, isolierte clientseitige Sandbox.
- Sicherheit: KVM-Isolation, OpenSMTPD-Härtung, Fail2ban, ECC PGP-Schlüssel.
Dieses Dokument beschreibt detailliert die Funktionsweise, das Sicherheitsmodell und die Datenschutzgarantien von session.email.
2. Infrastruktur und Umgebung
2.1. Physische und virtuelle Umgebung
- VPS-Anbieter: RackNerd
- Standort: USA
- Virtualisierung: KVM (Hardware-Isolation)
- Speicher: 1 GB RAM + 1 GB Swap
- Betriebssystem: Debian 12
- Firewall: UFW – alle ungenutzten Ports geschlossen, auch Port 22 (SSH)
- SSH: auf nicht-standardmäßigem Port, mit Brute-Force-Schutz
Die KVM-Virtualisierung stellt sicher, dass speichergebundene Operationen in einer wirklich isolierten Umgebung stattfinden, die von anderen VPS-Instanzen getrennt ist.
3. Softwarearchitektur
3.1. Hauptkomponenten
- Caddy: HTTP/2 und HTTP/3 (QUIC) Reverse Proxy.
- OpenSMTPD: ausschließlich für den Empfang (inbound) von SMTP-Datenverkehr.
- Go-Backend: Nachrichtenverarbeitung, Redis-Integration, SSE-Streaming.
- Redis: In-Memory-Datenverwaltung, TTL-basierte Löschung, keine Persistenz.
-
GoatCounter: auf eigenem VPS gehostete, cookie-freie, datenschutzfreundliche Analytik (
analytics.session.email
).
- Fail2ban: für OpenSMTPD- und Caddy-404-Ereignisse konfigurierter Schutz.
4. Datenfluss (Data Flow)
[OpenSMTPD] → [Go Backend] → [Redis (RAM)] → [SSE Stream] → [Isolierte Iframe] → [Purify.js + Sanitizer]
4.1. SMTP-Empfang
- OpenSMTPD empfängt eingehende E-Mails.
- Maximale Nachrichtengröße: 25 MB – darüber hinaus werden E-Mails abgelehnt.
- IP-Ratenbegrenzung aktiv, um Überlastung und Missbrauch zu verhindern.
- Outbound-SMTP ist vollständig deaktiviert – der Dienst versendet keine E-Mails.
4.2. Backend-Verarbeitung
Das Go-Backend ist für die Verarbeitung der Nachrichten verantwortlich:
- Header- und Body-Parsing, „Säuberung“ der Nachricht.
- Die Nachricht wird im RAM mittels Redis mit einem strikten TTL gespeichert.
- Die Nachricht wird über einen SSE-Kanal (Server-Sent Events) an den Browser des Clients gestreamt.
4.3. Redis-Funktionsweise
- AOF (Append Only File): deaktiviert (
appendonly no).
- RDB-Snapshot: aktiviert, aber das System speichert keine E-Mails dauerhaft; Redis arbeitet ausschließlich im RAM.
- Zugriff: nur unter
127.0.0.1:6379, passwortgeschützt.
- IP-Rate-Ban: auch auf Redis-Ebene angewendet.
4.4. TTL-Werte
- Kostenlose Adresse: 15 Minuten TTL (Schutz gegen erneutes Verbinden auf Client-Seite).
- Premium-Adresse: 1 Stunde TTL.
- Session-Cookie: 1 Stunde.
Alle Daten werden automatisch gelöscht, wenn der TTL abläuft; es gibt keine dauerhaft gespeicherten Daten, die auf eine manuelle Löschung warten.
5. Zero-Persistence-Garantien
Während des Betriebs von session.email gilt:
- es werden keine E-Mails auf die Festplatte geschrieben,
- es werden kein Mail-Spool oder Maildir-Strukturen erstellt,
- es werden keine Protokolldateien über eingehende Nachrichten gespeichert,
- es werden keine IP-Adressen, User-Agents oder Zeitstempel dauerhaft gespeichert,
- es findet kein Profiling statt, es wird keine Benutzerdatenbank aufgebaut.
Das System arbeitet ausschließlich im RAM und stützt sich auf den Redis-TTL-Mechanismus. Nach Ablauf des TTL werden die Daten automatisch und unwiderruflich gelöscht.
6. Clientseitige Sicherheit
6.1. Isolierte Iframe
Die Anzeige der E-Mails erfolgt in einem isolierten, sandboxed Iframe, das den Inhalt der Nachricht vom Hauptdokument trennt.
6.2. Sanitization und Tracking-Schutz
- Verwendung von purify.js zur Bereinigung des HTML-Inhalts.
- Eigene Sanitization-Logik zum Filtern von Tracking-Pixeln und verdächtigen Elementen.
- Option für die HTML-zu-Plain-Text-Ansicht für maximale Sicherheit.
Dieser Ansatz reduziert das Risiko von XSS, CSRF, remote resource loads und anderen clientseitigen Angriffen.
7. Premium PGP-Funktion
Für Premium-Benutzer bietet session.email eine session-gebundene, nur im Arbeitsspeicher (memory-only) existierende PGP-Verschlüsselung.
- Algorithmus: ECC, Curve25519.
- Bibliothek:
openpgp.min.js.
- Schlüsselgenerierung: jede Session erhält ein einzigartiges Schlüsselpaar.
const { privateKey, publicKey } = await openpgp.generateKey({
type: 'ecc',
curve: 'curve25519',
userIDs: [{ name: 'Session User' }],
});
Der private Schlüssel lebt ausschließlich im RAM, wird niemals auf die Festplatte geschrieben und am Ende der Session automatisch rotiert und gelöscht.
Der Benutzer erhält einen öffentlichen Schlüssel, mit dem an ihn gesendete Nachrichten verschlüsselt werden können.
8. Analytik (GoatCounter)
session.email verwendet nur eine minimale, datenschutzfreundliche Analytik:
- Tool: GoatCounter.
-
Standort: eigener VPS, unter der Domain
analytics.session.email.
- Gesammelte Daten: nur Seitenaufrufsstatistiken.
- Keine: Tracking-Cookies, Fingerprinting, Weitergabe von Daten an Dritte.
9. Bezahlsystem (Paddle)
Die Bezahlung für Premium-Funktionen erfolgt über das Paddle-System.
- Paddle-Webhooks werden verwendet, um den Status von Transaktionen zu bestätigen.
- Der session.email-Server speichert keine Zahlungsdaten dauerhaft.
- Paddle kann eigene Cookies für Sicherheits- und Transaktionsverwaltungszwecke verwenden.
- Der Server sieht nur die für die Transaktion erforderliche E-Mail-Adresse und speichert auch diese nicht langfristig.
10. Sicherheitsmodell
10.1. Bedrohungsmodell
- Brute-Force / SSH-Angriffe: nicht-standardmäßiger SSH-Port, UFW, Fail2ban.
- SMTP-Flood: OpenSMTPD IP-Ratenbegrenzung, max. 25 MB Nachrichtengröße.
- Redis-Angriff: nur Localhost-Zugriff, passwortgeschützt, hinter einer Firewall.
- XSS / HTML-Angriffe: isolierte Iframe, purify.js, Sanitization-Logik.
- Tracking / Metadaten-Leck: Filtern von Tracking-Pixeln, HTML-zu-Plain-Text-Option.
- Disk-Forensik: keine Schreibvorgänge auf die Festplatte, kein Mail-Spool, keine Logs.
10.2. Minimierung der Angriffsfläche
- Kein Outbound-SMTP.
- Keine Benutzerkonten, Passwörter oder persistente Datenbanken.
- Keine API, über die massenhaft Daten abgerufen werden könnten.
- Alle Daten leben im RAM mit TTL und automatischer Löschung.
11. Zusammenfassende Tabelle
| Bereich |
Lösung |
Status |
| Datenspeicherung |
RAM-only (Redis mit TTL) |
✔ Zero-persistence |
| Log-Führung |
Vollständig deaktiviert, kein Disk-I/O |
✔ Zero-log |
| SMTP |
OpenSMTPD nur inbound, 25 MB Limit |
✔ Outbound deaktiviert |
| Web |
Caddy, HTTP/2 + HTTP/3 (QUIC) |
✔ Moderne Protokolle |
| Analytik |
GoatCounter, eigener VPS, cookie-frei |
✔ Datenschutzfreundlich |
| PGP |
ECC Curve25519, session-bound, memory-only |
✔ Premium-Verschlüsselung |
| Virtualisierung |
KVM, isolierter VPS |
✔ Hardware-Isolation |
| Sicherheit |
Fail2ban, Ratenbegrenzung, UFW |
✔ Aktiver Schutz |
12. Fazit
session.email ist ein Wegwerf-E-Mail-Dienst, der:
- keine Daten dauerhaft speichert,
- nicht protokolliert,
- nichts auf die Festplatte schreibt,
- keine Metadaten sammelt,
- keine ausgehenden E-Mails zulässt,
- ausschließlich im RAM mit strikten TTLs arbeitet,
- PGP-Verschlüsselung für Premium-Benutzer bietet,
- auf einer modernen, sicheren Architektur läuft (KVM, Caddy, OpenSMTPD, Redis),
- strenge clientseitige Sandboxing- und Sanitization-Methoden anwendet.
Das System entspricht den Prinzipien von Privacy-by-Design und Data-Minimization und bietet technisch einzigartig starke
Garantien für die Anonymität und Datensicherheit der Benutzer.