What happens to attachments after manual clear?

After you manually clear a temporary inbox, treat attachments as scheduled for deletion with the rest of the message content—you should no longer rely on opening them. Download files you need before clear. Manual clear revokes access immediately and starts purge of stored ciphertext for bodies and attachments per policy. It is not a secure-erase certificate for every backup plane, and it is not a substitute for durable storage when files matter.

This explainer separates general lifecycle mechanics from Mailby’s verified public policy. It does not publish internal retention knobs as user promises—always confirm /data-retention and /privacy.

Manual clear context and boundaries

Temporary inboxes exist to receive short-lived mail: OTPs, confirm links, one-off PDFs. Attachments hitch a ride on those messages—invoices, tickets, images, zip files.

“Manual clear” means the user explicitly deletes messages or ends the inbox/session from the product UI (wording may be Clear, Delete, or purge). That is distinct from:

• Automatic expiry when the receive lease or message retention clock ends
• Password/session loss without delete
• Provider-side abuse takedowns

Boundaries (Mailby product truth):

• Quick Inbox is live at /inbox.
• Free defaults are short (about one hour receive and message retention unless deleted earlier)—confirm live copy on the retention page.
• Privacy Pro extends windows via /pricing; it still expects eventual deletion.
• Encryption at rest protects stored blobs during life; TLS protects transit; this is not E2EE with the sender.
• Never claim zero logs, guaranteed anonymity, or cryptographic erasure proofs beyond what privacy docs state.

If the attachment is a boarding pass, contract, or tax PDF, copy it out before clear—or do not use temporary mail for that message class. See travel purchase email.

Demonstration: working path and failure

Working path:

1. Receive a message with a PDF in Quick Inbox.
2. Open safe preview; confirm it is the file you expect.
3. Download to local disk or password-manager document storage.
4. Click clear / delete inbox.
5. Confirm the UI no longer lists the message.
6. Treat the cloud object as pending purge; do not plan to re-download tomorrow from Mailby.

Failure / counterexample:

1. User opens an e-ticket only in the browser preview tab.
2. Clears the inbox to “be private.”
3. Discovers the download never completed.
4. Airline resend goes nowhere useful if the signup address was also disposable and dead.

Lesson: clear is not backup. Privacy action and archival action are opposite verbs.

Editorial verification date: 2026-09-24 against public retention/privacy pages—re-check before compliance quotes.

Mechanism: storage lifecycle (general + Mailby framing)

General principles for temp-mail style systems

1. SMTP accept → store raw MIME (often encrypted at rest).
2. Parse attachments as part of MIME body parts (RFC 2046).
3. Serve preview via authenticated session.
4. On delete/expiry → revoke indices and delete or GC ciphertext objects.
5. Backups/replicas may lag; public docs should describe whether delayed purge exists.

Mailby-aligned framing (public)

• Inbox metadata and encrypted bodies/attachments live for the retention window.
• Deleting a disposable inbox revokes access immediately and schedules purge of content (data-retention).
• Security logs for abuse defense may exist separately—read privacy for classes of data.
• Manual clear is the user-driven path to shorten life below the default clock.

What manual clear does not reliably do:

• Erase copies you already downloaded
• Erase the sender’s ESP copy
• Erase screenshots or synced browser downloads
• Prove deletion to a third-party auditor unless a specific report exists (do not invent one)

Data item table

Data item	Collected?	Access period	Deletion trigger	Verification method
Attachment bytes (encrypted at rest)	Yes, with message	Until retention end or clear	Manual clear / expiry / policy	UI empty; docs on purge
Message body	Yes	Same	Same	Same
Inbox address / session	Yes	Lease window	Lease end / clear	Cannot reopen session
Extracted OTP cache in UI	Derived	Session	Clear / navigation	UI state
Abuse/security logs	Limited	Per privacy policy	Policy TTL	Privacy page—not inbox UI
Your local download	On your device	Until you delete	You	Filesystem

Worked example

You requested a vendor’s sample PDF via disposable mail.

1. Keep the tab open until the PDF downloads.
2. Hash or rename the file locally so you know what it is.
3. Clear the inbox.
4. If you must re-request later, use a new disposable session—or a durable alias if this became a real vendor relationship (plus addressing comparison).

For MIME structure quirks that affect whether you even see the attachment in preview, see multipart/alternative rendering.

Alternatives when durable storage is required

Use a durable mailbox or document vault when attachments include:

• Legal contracts
• Travel tickets
• Warranties
• KYC documents (prefer not emailing these at all)
• Anything covered by employer retention policy

Developer workflows that parse attachments in CI should use the developer API with explicit teardown—see Playwright identity isolation—and avoid storing production PII in temp inboxes longer than the test.

Short answers

What happens to an attachment after manual clear?

Access ends immediately; stored attachment data is scheduled for purge with message content per retention policy. Do not expect restore.

What should I do first?

Download needed files, verify the download, then clear.

When is a permanent address safer?

Whenever the file must remain reachable without re-requesting from the sender.

What evidence changes the recommendation?

Live plan shows longer Privacy Pro retention that covers your need—and you still accept receive-only limits—or the sender offers a portal download bound to a durable login.

Sources, test date, and limitations

Test date: 2026-09-24.

External sources:

• RFC 2046 — MIME parts including attachments.
• OWASP secure data lifecycle concepts — general deletion vs. residual copies.

Limitations: Exact purge lag across replicas is an ops detail—trust public policy pages, not blog guesses. This article is not a legal opinion on GDPR erasure timelines. Mailby does not claim E2EE.

Browser downloads vs inbox storage

Clearing the inbox does not delete files already in your Downloads folder. Conversely, “seeing” a PDF in a preview pane may use a blob URL that disappears when the tab closes—even before clear. Always perform an explicit download.

Shared devices

On a borrowed computer, downloads may remain after you clear the remote inbox. Secure the local artifact separately (delete local file, clear browser downloads list).

Compliance language discipline

Say: “Manual clear revokes access and schedules purge per policy.” Do not say: “Cryptographically proven instantaneous global erasure” unless a formal report exists. Point readers to /privacy and /data-retention for binding wording.

Attachments in developer tests

CI should assert attachment presence, copy bytes to the test artifact store if needed, then delete the inbox. Leaving attachments in shared temp inboxes is how fixtures leak.

How this differs from a retention hub

Hub pages explain clocks. This article answers the attachment-specific question after manual clear, with a save-then-purge workflow.

Object storage mental model

Think of each attachment as an object keyed by message id. Clear removes your capability to read the key and schedules object deletion. CDN caches or backup snapshots—if any—follow policy TTLs disclosed publicly. Without an enterprise DPA stating otherwise, assume you cannot restore.

Malware caution

Do not clear instead of scanning a suspicious attachment. Clear removes your copy from the inbox; it does not sanitize a file you already opened locally. Prefer not downloading unexpected executables at all.

Shared Quick Inbox mistakes

Never paste a live Quick Inbox URL into a public chat for “team attachments.” Session binding exists for a reason (how it works). Use developer inboxes with auth for shared QA.

Policy refresh cadence

Retention defaults can change with plans. Before a compliance questionnaire, re-read /data-retention rather than quoting an old blog paragraph. This article teaches mechanics and habits; policy pages win conflicts.

Save-first templates for common files

• PDF tickets: download + wallet/app
• Images: download only if needed; prefer links you control
• Zips: prefer not; if required, scan then store outside temp mail

User-visible states vs backend truth

UI state	User should assume
Message listed	Attachment retrievable now
Message opened	Still retrieve now; download if needed
Cleared / empty inbox	Attachment gone for practical purposes
Lease expired	Same as cleared

Do not invent “recycle bin for temp mail” unless the product shows one.

Team education one-liner

“Clear means goodbye—save first.” Put it in onboarding for support staff who demo disposable inboxes.

Relationship to Privacy Pro

Longer retention delays automatic loss; manual clear still means goodbye. Plans change clocks, not the meaning of delete.

Final habit loop

Receive → evaluate → download if valuable → clear → move on. Skipping download is the defect. Clearing is the feature.

FAQ-style clarifications (not schema spam)

Does clear delete the sender’s copy? No.
Does clear delete my phone download? No.
Can support restore a cleared attachment? Do not expect yes.
Is encryption at rest the same as E2EE? No.
Should I use temp mail for KYC scans? No—prefer vendor portals and durable controls.

These five answers prevent most misconceptions support hears.

Practical save locations

Prefer password-manager document slots, encrypted notes, or OS folders you back up—not random desktop clutter. After saving, clear the temp inbox so the sensitive PDF is not sitting in a web session on a shared browser.

Edge: clearing while a download is in flight

If you clear mid-download, the browser may finish a partial file. Verify file size/PDF openability after download completes, then clear. Order matters: complete download → verify → clear.

Retention vs lease (again, because it matters)

Receive lease governs whether new mail is accepted. Message retention governs how long stored messages (and their attachments) remain. Manual clear short-circuits retention for that content. Keeping these clocks straight prevents false expectations—and prevents treating clear as “archive forever somewhere invisible.”

Last mile

Save the file, confirm it opens, then clear. Manual clear is privacy on purpose—not a trash bin with undo.

If the file matters tomorrow, it never belonged only in a temporary inbox.

Read the live retention policy when exact hours matter for your case.

Conclusion

Manual clear is a privacy accelerator, not an archive. Attachments die with the inbox’s content lifecycle. Save first, clear second.

Read /data-retention and /privacy for authoritative wording, then use /inbox only for files you can afford to lose after the session.