Technical lifecycle

How MyraMail Works

A step-by-step description of what is created, what the browser can access, what expires, and what remains as operational metadata.

Reviewed by Dynamic Foundries · 10 September 2026

Short answer

A button press creates a random Mailcow mailbox and 15-minute browser session. MyraMail reads its messages over IMAP, sanitizes displayed HTML, blocks remote content, and later removes the expired mailbox through scheduled cleanup.

1. Mailbox creation

The generation endpoint creates a random local part under myramail.com, an internal mailbox password, and a matching database row. If the mail server refuses creation, the database row is rolled back so the application does not return an address that cannot receive mail.

Creation is rate limited by source IP. MyraMail has no public automation API and does not support bulk mailbox creation.

2. Browser access

The application issues a signed token that expires after 15 minutes and stores it in an HttpOnly, Secure, SameSite cookie. The response does not expose that inbox token to page JavaScript. On reload, a session endpoint can return the generated address and remaining time without revealing the credential.

3. Receiving and displaying mail

External senders use ordinary SMTP delivery to reach the temporary mailbox. MyraMail opens that mailbox over encrypted IMAP, lists messages newest first, and displays a selected body in a sandboxed frame.

Before display, active elements, event handlers, forms, links, remote image sources, and unsafe inline-style URLs are removed. The frame also has a restrictive content security policy. This reduces script and tracking risk; it does not turn ordinary email into end-to-end encrypted communication.

4. Expiry and scheduled deletion

The browser token expires 15 minutes after generation. A scheduled server job identifies MyraMail mailboxes older than 15 minutes and requests deletion from the mail system. Because cleanup is scheduled, physical removal may occur shortly after the visible timer reaches zero rather than at the exact same second.

The mailbox and message contents are not recoverable through the product after expiry. MyraMail offers no extension, login, recovery key, or address restoration.

5. Operational records

The mailbox lifecycle is not the same as the application database lifecycle. For abuse prevention and internal usage reporting, the database retains the generated address, source IP, creation timestamps, internal credential fields, and final message count after the mailbox itself is removed. Web access logs can also contain IP address and user-agent data.

No automatic deletion period is currently configured for those generation records. Data-subject requests can be sent to contact@dynamic-foundries.com. This limitation is stated plainly because “the inbox expires” must not be misread as “the operator retains no metadata.”

6. Analytics

Google Analytics is optional and does not load until the visitor accepts it. The preference is stored in the browser. Generating an inbox sets a separate essential session cookie; refusing analytics does not prevent the inbox from working.

Implementation limits at a glance

  • One receive-only mailbox per generated session
  • 15-minute signed access token
  • No attachment-download interface
  • No outgoing SMTP, replies, forwarding, or aliases
  • No promise that every sender will deliver or every site will accept the domain
  • No anonymity or end-to-end encryption claim