correspondence deserves the strongest version of the promise, so it gets architecture instead
Email files hold the most candid writing people produce — arguments, love letters, legal threats, the message from someone who has since died. A viewer for such things must not be in a position to read them, and this one structurally isn't: the parsers run inside your browser tab, the site is flat files with no server-side application, and no request anywhere in the codebase carries message content. There is no counter clerk. The counter is your own machine wearing a nice apron.
The proof anyone can run: load the page, disconnect from the internet, open a decade of correspondence. Everything works — parsing, attachments, printing. What the letters said stayed between you and them.
What this viewer blocks on your behalf: remote images in HTML mail report your reading back to the sender's server, so they're blocked by default and counted on screen. Choosing to load them is the one action on this site that touches the network with anything mail-related — it fetches those images from their servers, exactly as a mail client would, and the button exists so that's your call, made knowingly.
Kept: nothing. No message, header, or attachment is stored anywhere — close the tab and the mailroom is empty. There's no localStorage in use at all on this site.
Counted: no analytics, no ad code, no cookies of this site's making. One typeface from Google Fonts, cached on first visit. The host tallies raw visits. Who wrote to you, and what they said, is not in this operation's power to know.
questions → poste restante · reviewed 12 jul 2026