Control review · 28 July 2026
Mailbox retention control audit
“Expires” and “is deleted” are different events. This audit maps each control in the current application and SMTP configuration so the privacy description does not imply instant erasure where the code only stops access and schedules cleanup.
Current code and repository defaults
| Control | Value | Meaning |
|---|---|---|
| Mailbox session window | 1 hour (3600s) | An address is available until the server-side expiresAt time shown by the countdown. |
| Default extension limit | 1 time | Each accepted extension adds one mailbox window. Production can override this value. |
| Session-record grace | 600 seconds (600s) | Redis session and address mappings remain briefly after access expiry so stale state can be cleared safely. |
| SMTP raw-body TTL | 1 hour (3600s) | The checked-in SMTP configuration stores Redis message bodies with this SETEX duration. |
| SQL cleanup lock | 60 seconds (60s) | New-session requests can trigger cleanup, but a Redis lock limits concurrent sweeps. |
Lifecycle, in execution order
1. Session creation
The API creates a cryptographically random 16-byte session ID and an eight-hex-character default prefix. The ID is placed in an HttpOnly, SameSite=Strict cookie; Secure is added in production. Redis stores the session and address mapping until the visible expiry plus a short cleanup grace.
2. Receiving and visibility
The SMTP process writes routing metadata to SQL and can store the raw body in Redis using the configured TTL. The inbox API requires the matching session cookie, rejects an expired session, and returns only messages newer than one configured mailbox window. Extending an address extends the session, not the age of already received messages.
3. Extension
If the configured extension count allows it, expiresAt moves forward by one mailbox window. This audit corrected the Redis TTL calculation so the session mapping now lasts until the extended expiry plus grace instead of disappearing after a fixed single window.
4. Expiry
After expiresAt, the API stops returning inbox messages and clears the browser cookie on the next relevant request. Expiry is an access control boundary; it is not a claim that every SQL row and infrastructure log is deleted in the same millisecond.
5. Cleanup or manual deletion
Starting a new mailbox can acquire a one-minute Redis lock and delete SQL message rows older than one mailbox window. A user can delete selected message rows sooner. Redis raw bodies expire independently under the SMTP SETEX configuration, while limited infrastructure logs follow provider, security, reliability, and legal retention needs.
Controls verified in this review
- The session cookie is HttpOnly, SameSite=Strict, path-scoped to /, and Secure in production.
- Expired sessions cannot read messages through the inbox list procedure.
- Inbox reads require the session recipient to match the queried mail rows.
- Session and address keys use expiring Redis records rather than indefinite keys.
- Manual message deletion is implemented as a server-side database deletion.
- Homepage and message views have no AdSense component, so mailbox content is not paired with ads.
What this audit does not prove
- It does not inspect production Redis, SQL, hosting, backup, or logging dashboards.
- Environment variables may change the mailbox window and extension count; the live countdown is authoritative for a visitor's current session.
- Deleting TmpKit's copy cannot recall a message retained by its sender, a network intermediary, a downloaded device, or a backup governed by another retention cycle.
- Operational verification still requires sampled production TTLs and cleanup telemetry without exposing message content.