What I store and what disappears

Each address is a row in my database: the local part (the bit before @), which inbound hostname you picked from the allowed list, an expiry time, and timestamps for creation and updates. There is no password and no account—whoever has the inbox URL can read that mailbox until it expires.

I do not intentionally store your real identity when you create an address. Normal web requests may still carry an IP address to the server logs of whatever sits in front of the app (same as any website).

When mail arrives for an active address, I store metadata and body text: From, Subject, plain text and HTML bodies (HTML is sanitized before storage), the message’s RFC Message-ID when present (to reduce duplicates), and received time. Attachment binaries are not kept—only what fits in those text fields.

The service is inbound only: I never send outbound mail on your behalf from these addresses.

Inbound delivery is built on top of InboundParse, which receives SMTP mail and forwards normalized webhook payloads to this app.

When you create an address, you pick a lifetime. The presets today are: 30 minutes, 60 minutes, 90 minutes, 6 hours, 12 hours, 24 hours, and 7 days. That choice sets a single expires at timestamp on the address row.

After expiry, the inbox UI treats the mailbox as gone even if a background job has not finished yet—you should not see messages past that moment.

A scheduled worker job runs around the expiry time. It takes a database lock on that address, checks that the clock really has passed (with a small safety window), then in one transaction: deletes every stored message for that address and sets a destroyed at timestamp on the address. That is a hard delete from the application’s perspective, not a soft “archive.”

If a job is delayed, there is also a sweep that can catch already-expired addresses that were missed and run the same deletion path.

When someone uses Report abuse on the homepage, I store the local part, free-text reason, optional contact email, and request IP and user agent for triage. Those rows are operator-facing; they are not tied to the disposable TTL above unless I delete them manually.

If you submit feedback through the public form, I store your message, optional email, request IP and user agent, and a small JSON metadata blob (for example which page you were on). I use that only to improve the product or reply—see Contact if you want email instead.

The server may also enqueue an out-of-band notification (for example to a private operator channel) so I see your note quickly; that does not change what is persisted in the database described above.

The marketing site can show aggregate counts (addresses created, messages received, domains offered). Those are numbers only—no per-address detail in that widget.

I cannot promise what a host provider retains. I can promise what the code does: when destruction runs, the alias’s messages are removed and the alias is marked destroyed.

Today I do not back up databases or email messages. If the server falls over or something goes wrong, data can be lost—I treat that as an acceptable trade for a small disposable-mail experiment, not a archive service.

If you need something removed urgently, use Report abuse with the local part, or write via [email protected].