Summary

  • A 27 October individual Internet-Draft proposes a JMAP DeletedItem interface for recovering destroyed email, contacts, calendar events, files and mail-filter scripts.
  • In a shared account, past read permission is the first condition for seeing a deleted item; purging and restoration face separate present-day permission checks.

Take an invoice from a shared mailbox. Once it is destroyed, an ordinary mail view stops showing it. John Coffey’s new JMAP Undelete draft would give a server that adopts the extension a second place to show it: a DeletedItem with a deletion time, an expiry time, a snapshot and, where available, a downloadable blob. The server would advertise which object types it keeps and how long a new deletion remains recoverable.

The proposal does not depend on the button that caused the loss. For an advertised type, the server would create the record after a JMAP destroy, an IMAP expunge, a POP3 deletion or automatic emptying of Trash. Merely moving mail to Trash does not qualify. That distinction matters to anyone designing a reassuring “undo” button: the recoverable record begins when the object is actually destroyed.

The sharper rule sits in Section 3.3. A shared-account user may see a deleted item only if that user could read the object in at least one container when it was destroyed. That is a necessary test, not a permanent ticket. The server may narrow access further, even to the account owner alone. The draft directs a server that cannot reliably reconstruct the old rights toward owner-only visibility. RFC 9670’s sharing model describes current rights to shared objects; this recovery proposal asks the server to remember enough of the old position to judge a new view.

Action follows another clock. To purge the retained item, mayPurge must be true and the user must have permission to remove the object from its former containers. To restore it, the user needs permission to create an object in a destination. If the old container is gone or unwritable, the draft chooses a writable default such as the inbox; without one, restoration fails. A person can therefore meet the historical test for viewing a record while lacking the authority to erase or recreate it. The protocol is explicit about that division.

Expiry adds a promise the operator cannot quietly shorten: changing retention settings must not bring an existing record’s expiresAt forward. At expiry, the item vanishes from this interface immediately. A successful purge also ends recovery through the extension. The draft’s privacy section places any separate legal or contractual retention outside this interface. Its security section points out the price of convenience: a stolen credential or delegated session with account access can reach recently destroyed data. The Datatracker lists this as an individual draft in I-D Exists; the one named server has its own recovery interface and has not implemented this JMAP method. No implementation test shows what happens to a retained item when shared-container rights change after deletion.