Summary

  • RFC 9787, published as an Informational RFC in August 2025, draws a sharp distinction between protecting an unfinished draft and protecting a message for its eventual recipients. A protected draft is for the author alone; recipient encryption belongs at actual send.
  • The difficult interoperability boundary is cross-device custody. Another mail user agent can resume an encrypted draft only if it can access both the mailbox and suitable user-controlled decryption key material. RFC 9787 acknowledges the need for secure certificate and secret-key sharing across MUAs but leaves that coordination problem unresolved.
  • A conforming MUA must not apply the user's normal signing key to a draft. The RFC's concern is that a signature normally associated with the author could make leaked unfinished text appear to carry commitment that the author had not yet chosen to make. That is a protocol-design concern about meaning and evidence, not a universal statement about legal effect.
  • IMAP and JMAP can identify draft state and model the transition toward submission, but those storage mechanics do not themselves define the cryptographic authority boundary. Operators still need to know which object was private composition, which client could change it, and when the final recipient-facing object actually came into existence.

Imagine an explicitly hypothetical transition. A user types several paragraphs on one device. The client autosaves them remotely. Later, another device opens the same mailbox and the words reappear in its composer. That continuity is useful, but two things should still be false: the people tentatively listed as recipients should not yet have gained the ability to read those paragraphs, and the reappearing text should not carry the same cryptographic signal of authorial commitment that a deliberately sent, normally signed message could carry.

That is the narrow but consequential boundary in RFC 9787 Section 9.5.

RFC 9787 is Informational, published in August 2025. It is implementation guidance rather than a Standards Track specification. Its draft guidance nonetheless uses normative requirement language for conforming MUAs, and the distinction it draws is unusually clear: saving, resuming and sending are not merely three user-interface moments around one cryptographic object. They can require different access scopes and different evidence of intent.

The draft is an author-only security state

Many MUAs save unfinished messages in a Drafts folder. When that folder is remote — an IMAP mailbox is the RFC's obvious example — storing the unfinished message in cleartext can expose content to infrastructure outside the user's direct control.

The timing matters. While composition is still in progress, the MUA may not know whether the completed message will eventually be protected. The user can make that decision late. RFC 9787 therefore says the MUA SHOULD encrypt all drafts unless it knows that the completed message will be cleartext or knows that the Drafts folder cannot be read by a potential attacker.

The encryption target is then deliberately narrower than the likely recipient set. A protected draft MUST be encrypted only to the user's own certificate, or to equivalent secret key material possessed only by that user. Intended recipients must not be able to decrypt it merely because their addresses already appear in the composer.

That produces a useful authority model.

During composition, encryption protects custody of unfinished content. It does not yet distribute access.

At sending, encryption can be reconstructed for the actual recipients.

Those are different actions with different principals. Treating them as the same operation would collapse the distinction the RFC is trying to preserve.

RFC 9787 makes the send boundary explicit: the message should be encrypted to recipients only upon actual sending. Its rationale is intuitive. People do not normally expect a recipient to gain access to a message before the sender has finished and sent it.

The harder problem is the second client

Single-device draft protection is conceptually simple: encrypt the remote copy to key material the same client can later use.

The cross-device case is where the architecture becomes demanding.

If an encrypted draft saved from one MUA is to reopen on another, the second MUA needs more than mailbox credentials. It must also have access to a decryption-capable secret key appropriate for that protected draft. Otherwise the mailbox can synchronize ciphertext while the user's editing state stops being portable.

RFC 9787 does not pretend that this coordination problem is solved. Appendix A.4.1 identifies cross-MUA sharing of local certificates and secret keys as future work: multiple MUAs attached to the same mailbox need efficient and secure ways to share the user's cryptographic material. The document leaves the details outside its present scope.

Appendix A.4.2 considers portable hardware-backed secret keys as another possibility, while likewise leaving detailed guidance out of scope.

This unresolved boundary should not be hidden behind the fact that mature message cryptography exists. S/MIME 4.0 and OpenPGP provide cryptographic machinery for messages. Their existence does not establish that draft-only, cross-device key coordination is widely deployed, consistently implemented or interoperable across products. No reviewed source in this evidence set establishes such prevalence.

The operational question is therefore not simply, "Can this mailbox store encrypted email?" It is: can every authorized composing client identify the same evolving draft, decrypt the latest valid version, update it without losing another client's work, and preserve the distinction between author-only draft protection and recipient-facing protection at send?

Signing creates a different kind of boundary

Encryption controls who may read the draft. Signing raises a separate question: what statement does possession of a signature permit another party to make about the author?

RFC 9787 answers narrowly. A conforming MUA MUST NOT sign a draft with the user's normal signing key. The RFC explains that placing a non-repudiable signature on unfinished text can imply commitment if the draft escapes its intended custody.

That should not be inflated into a universal legal rule that every signature has identical effect in every jurisdiction or context. The reviewed material does not establish such a proposition. The implementation point is simpler: a normal author signature is intended to mean more than "this byte sequence existed temporarily in my composer".

For cryptographic coordination between the same user's MUAs, RFC 9787 suggests that a different key could be negotiated for draft signing. It does not define the mechanism.

That distinction is important. "Do not use the normal signing key" is specified guidance. "Here is a standardized multi-device draft-signing system" is not.

Draft flags are useful state, not a complete commitment model

Existing mail protocols already expose draft mechanics.

IMAP4rev2 defines the \Draft system flag for a message whose composition has not completed. RFC 6154 defines the \Drafts special-use mailbox for draft messages.

JMAP Mail defines $draft, describes draft creation and replacement, and includes a submission example in which successful submission removes draft state and moves the message from Drafts to Sent.

These mechanisms are useful because they make lifecycle state observable. They do not, on their own, answer the cryptographic questions raised by RFC 9787. A server can know that an object is marked as a draft without proving that only the author can decrypt it. It can move state toward Sent without proving that the user's normal signing key was withheld during composition. Nor does a draft flag establish whether two clients merged edits correctly or whether an older draft version remained recoverable somewhere after submission.

Storage state and authority state overlap, but they are not identical.

Proposal: a draft-intent custody receipt

A practical implementation could preserve a small amount of evidence around this transition without logging the message itself. I propose calling that evidence a draft-intent custody receipt. This is an editorial proposal, not a requirement of RFC 9787 and not a claim that such a format is standardized or deployed.

The receipt would exist to answer one narrow audit question: did an object remain in author-only draft custody until a specific send event converted it into a recipient-facing message?

For that purpose, the receipt should record only:

  • a draft object and version reference;
  • the class of storage endpoint holding the draft;
  • the author-only encryption scope and the relevant key class;
  • the clients authorized and technically able to decrypt and update it;
  • the last-writer or merge state for the current version;
  • confirmation that the user's normal signing key was not used to sign the draft, which is different from asserting that the key was absent from the device;
  • confirmation that recipient encryption had not been applied before send;
  • the actual send event, initiating client, timestamp and a digest representing the final recipient set;
  • a hash of the submitted object;
  • the result of post-send draft cleanup or tombstoning;
  • an accountable owner for the receipt and an expiry or review trigger.

The receipt should not retain the message body, subject, unrestricted recipient list, secret keys, credentials or general mailbox logs. It is evidence about the custody transition, not a second surveillance archive built beside the mailbox.

Even those limited fields require care. An ordinary hash is not automatically anonymized data. Low-entropy values can sometimes be guessed; separate records can be correlated; repeated digests can expose equality even when the underlying value is not stored directly. A recipient-set digest therefore may need keyed construction or placement inside a tightly access-controlled evidence system, accompanied by a defined purpose and short retention. The submitted-object hash deserves the same treatment if its reuse permits unwanted correlation.

The important property is restraint. The receipt should be just sufficient to reconstruct the security-state transition without becoming a durable copy of the very information draft encryption was meant to keep private.

What the evidence does not establish

The evidence boundary here needs to remain explicit.

The RFC Editor's errata search for RFC 9787 showed no matching RFC 9787 errata at the review cutoff used for this article.

The reviewed sources do not establish how widely vendors follow Section 9.5, how often remote cleartext drafts leak, whether particular products implement interoperable draft-only keys, what legal weight a leaked signed draft would receive, or whether any standardized cross-MUA draft-key exchange has emerged.

Those are separate empirical questions. They should not be filled with inference merely because the security model makes the questions obvious.

Sources