JMAP draft adds safeguards for restoring deleted email
News
Published 4 Nov 2026
Updated 4 Nov 2026
7 min read
Summarize with
The JMAP Object History draft adds explicit safeguards for restoring deleted email: servers can decline to keep history for harmful content removed by an administrator, or reject its restoration. Revision 03 also changes how clients find destroyed objects and restore them through existing JMAP methods.
Published on 2 November 2026 UTC, with the publication event recorded at 23:18:24Z, this is a material revision of an adopted, active JMAP working-group document. It remains work in progress, not a final RFC or production guidance. No provider rollout, enforcement date or implementation deadline is announced, and the publication does not establish changed Gmail, Outlook or Yahoo behavior.
The new safeguard covers administrator-removed harmful content
New section 8.5, Harmful Content, explicitly permits a server to exclude history for an object removed because it contains phishing or malware. It also permits refusing an attempted restoration with a forbidden SetError. Section 5.1 includes forbidden among the defined restore failures when server policy or content prevents recovery. These permissions appear in the revision 03 text.
Both choices use the draft keyword MAY. An implementation can exercise that discretion; the draft does not mandate a particular anti-phishing policy. It does not introduce message scanning, detection rules or an automatic remediation service.
A policy permission, not a deployment claim
Revision 03 explicitly accommodates harmful-content removal in history retention and restoration. It does not establish an exploitable bypass in deployed servers, and earlier drafts did not require servers to restore dangerous content.
The operational inference I draw is that security removal should remain effective when a mailbox has history or a recently deleted view. If an administrator removes a malicious message, the recovery design should account for the retained copy and a later attempt to restore it.
That differs from helping someone recover a message they deleted accidentally. A client needs to distinguish an ordinary undo opportunity from a server policy decision that prevents the same content returning. This distinction matters to JMAP mailbox providers, client developers and administrators evaluating undelete support.
The API changes make recovery explicit
The previous revision 02 text already described restoration and server acceptance or rejection. Revision 03 replaces the create-with-old-ID approach, including the Email/import old-ID approach identified in its change notes, with a restore argument on Foo/set. For email, that means Email/set. There is no new Foo/restore method.
Foo is the draft's placeholder for an object type. The new restore map identifies destroyed objects by ID and optionally supplies a patch. The server restores the final version, preserving its ID and server-set properties where possible, rather than asking the client to reconstruct a new object.
|
|
|
|---|---|---|
Deleted search | Old state approach | Query arguments |
Restore request | Create with old ID | Set restore argument |
Harmful content | No explicit subsection | Explicit policy options |
History access | Safeguards present | Safeguards continue |
Selected differences between the two draft revisions.
Finding deleted objects becomes easier for a client without a state string predating deletion. Foo/query gains onlyDestroyed, destroyedAfter and destroyedBefore. The first switches the query to retained destroyed objects; the date arguments restrict the destruction time window. A client no longer needs an old state string to discover those objects.
This illustrative method-call excerpt searches a deletion window. It assumes server support and inclusion of the object-history capability in the enclosing request's using array. The account and object IDs are placeholders for lab use.
Draft Email/query method-call excerptjson
[ ["Email/query", { "accountId": "accountA", "onlyDestroyed": true, "destroyedAfter": "2026-11-01T00:00:00Z", "destroyedBefore": "2026-11-03T00:00:00Z", "limit": 50 }, "q1"] ]
After finding a destroyed message, the client can request restoration directly. A null value in the restore map requests the final version without a patch. A patch lets the client adjust properties, such as the destination mailbox, during restoration.
An earlier version of an object that still exists is handled through an ordinary Foo/set update. The restore argument specifically addresses destroyed objects. Keeping those operations distinct helps clients avoid treating every historical version as a separate recoverable message.
A missing original mailbox produces ordinary validation failure. The client can restore that container first or choose an available mailbox in the patch. This second excerpt illustrates choosing a replacement mailbox; it assumes message42 has retained history and availableMailbox exists in the account.
Draft Email/set restore with a mailbox patchjson
[ ["Email/set", { "accountId": "accountA", "restore": { "message42": { "mailboxIds": {"availableMailbox": true} } } }, "r1"] ]
A restored Email retains the final version's blobId and message content. The client does not need to download the content first. Server-set properties are retained where possible; if the server must change one, the response reports the changed value.
Clients also need to inspect the restored and notRestored response maps. A request can contain several object IDs, so the interface should report each outcome rather than assume every requested restoration succeeded. A policy refusal needs different handling from an invalid patch or exhausted quota.
Section 5.2 also says a restored SieveScript remains inactive because it was deactivated before destruction. That is proposed document text drawing on JMAP-SIEVE, not evidence of a newly fixed security flaw. Restoring a script and activating it are separate operations.
Other deletion paths and existing permissions still matter
Revision 03 clarifies that destruction includes removal through IMAP EXPUNGE, POP3 DELE or automatic server deletion. Changes through other protocols can also create historical versions. Reviewing only the JMAP deletion path would therefore leave part of the proposed behavior untested.
Access-control requirements and administrative purge/privacy guidance already existed in revision 02. Sections 8.2-8.4 continue those safeguards, including permission checks for history and restrictions on exposing destroyed objects. The new harmful-content subsection adds explicit policy discretion alongside those existing protections.
Ordinary user recovery
An authorized user restores an accidentally deleted object when retained history and server policy permit it. The client handles missing containers and normal validation errors.
Administrative security removal
The server can decline history retention for harmful content or deny restoration. A recovery interface should explain a policy refusal without treating it as a temporary failure.
Retention also has a storage consequence. Revision 03 says counting retained history against a user's quota is NOT RECOMMENDED: deleting messages to free space would otherwise leave the user waiting for history to expire. Restored objects count against quota normally.
History remains subject to retention and purge policy. Administrators should review how security removal interacts with that policy, while clients should avoid promising permanent recoverability. Existing privacy guidance also matters when a user expects deletion to remove information that remains retrievable through history.
Revision 03 adds a per-version expires value describing when the server expects to discard that version. It is a best-effort indication, not a guarantee. It also clarifies that clients paging history for several IDs with historyBefore use one Foo/get call per ID. Both details matter when designing a recovery view that stays accurate as retained history changes.
What developers and administrators should test
I would start with design review and lab tests against the draft. The useful question is whether normal recovery and administrative removal produce the intended outcomes across the supported deletion paths. There is no urgent production migration attached to this publication.
Test both a message deleted accidentally and harmless test content designated for administrative security removal. Keep the expected retention outcome separate from the expected restore response, so a successful ordinary undo does not stand in for testing the security policy.
- Security removal. Verify that policy can exclude retained history or deny restoration of administrator-removed content.
- Deletion paths. Exercise JMAP deletion, IMAP EXPUNGE, POP3 DELE and automatic cleanup.
- Permissions. Check history access and restoration after permission changes, including shared mailboxes.
- Error handling. Show a useful forbidden response, and handle missing mailboxes and quota failures separately.
- Scripts and retention. Confirm restored scripts stay inactive, then review retention disclosure and administrative purge behavior.
These checks concern post-delivery mailbox security. DMARC, SPF and DKIM address message and domain authentication. The draft changes neither DNS authentication records nor inbox placement requirements.
Suped's DMARC monitoring supports investigation of sender authentication, while our email tester analyzes a sent message. Those are separate workflows from validating a mailbox server's retained-history and restore policy.
Review recovery policy before implementation
For teams evaluating JMAP history support, the next step is to document what ordinary deletion retains, what administrative security removal retains, and how the client explains a refused restore. Review that behavior against revision 03 in a lab, then track subsequent draft changes before making implementation commitments.
Frequency asked questions
No. It is a revision of an active, adopted working-group Internet-Draft. The publication announces no provider rollout or implementation deadline.
The new subsection uses MAY permissions. Servers can decline history retention for administrator-removed harmful content or reject restoration with forbidden; the draft does not mandate a detection system.
The proposed Email/set restore argument restores the destroyed object with its original ID and the final version's blobId and content. An optional patch can change properties such as mailbox placement.
No. This draft concerns mailbox object history and restoration after delivery. It does not change DMARC, SPF or DKIM records, or introduce new inbox placement requirements.
