JMAP draft tightens security checks for email push notifications
News
The IETF JMAP working group has published emailpush revision 04, a draft that makes server security checks more explicit for notifications containing email details. Servers would reject notification configurations without encryption keys, withhold sensitive pushes until subscription verification, and stop account notifications when access or capability support disappears. Encryption itself is not new: revision 03 already required keys and client rejection of unencrypted notifications.
The official publication event records October 30, 2026, at 03:35:10 UTC; the draft text is dated October 29. This is another revision of an active working group document, not its first adoption. It remains an Internet-Draft, not a final standard or RFC. It creates no rollout deadline or provider mandate, and its proposed requirements are not production guidance.
Why email details change the notification risk
Ordinary JMAP state notifications tell a client that server data has changed. The client then synchronizes to discover the details. EmailPush has a different purpose: it can carry selected email properties, including the sender, subject, and preview, so a mobile app can display a useful notification without first fetching the message.
That saves a network round trip when connectivity is poor or background execution is constrained. It also puts sensitive message information into the notification path. I see the server checks as the central change because a missing configuration check can expose information before a receiving client has any opportunity to reject it.
Ordinary state notifications
Carry state information that prompts synchronization. Message details are retrieved through the account access protocol.
EmailPush notifications
Carry requested email properties for immediate display. The push path therefore handles sensitive user data.
Filtering is tied to delivery. The server evaluates a message after delivery-time processing, including mailbox placement and assigned keywords. Later actions, such as moving that message, do not generate another EmailPush. For app developers, that distinction separates an arrival notification from a general stream of mailbox changes.
What revision 04 adds on the server
Section 4 explicitly requires rejection when emailPush is non-null but the subscription keys are null. The rejection uses an "invalidProperties" SetError, with both "emailPush" and "keys" in its properties list. This makes the server responsible for blocking that configuration rather than relying solely on client behavior.
The distinction matters when comparing the previous revision with the new text. Revision 03 already required encryption keys and instructed clients to ignore notifications not encrypted with those keys. Its example also described subscription verification. Revision 04 makes the EmailPush delivery gate explicit and adds clear stopping conditions.
|
|
|
|---|---|---|
Encryption keys | Client requirement | Server rejection too |
Verification | Example flow | Explicit send gate |
Account access | No explicit stop | Stop account pushes |
Capability loss | No explicit stop | Stop account pushes |
Selected security changes between the two draft revisions.
Under the revised wording, a server must not send EmailPush objects until the subscription is verified. It must stop sending them for an account when the user loses access or the account stops supporting emailpush. A subscription that was valid yesterday is not sufficient authorization for tomorrow.
The transport scope is explicit too: EmailPush objects go only to the PushSubscription URL. They are not sent through server-sent events (SSE) or a WebSocket push channel. This matters for implementations that already share notification infrastructure across several JMAP transports.
For prototype dispatch paths, I would also test notifications queued before access revocation but processed afterward. That checks whether the stopping condition is enforced when sending, including work already waiting in a queue.
Payload limits now have explicit handling rules
Section 3 identifies the Web Push baseline: a push service is only required to support payloads up to 4,096 octets. Encryption consumes part of that space, leaving less room for the EmailPush JSON. This is a transport budget, not an email message size limit or a guaranteed 4,096-byte allowance for readable properties.
The revision 04 text requires splitting across multiple EmailPush objects when several email objects do not fit together. For one oversized email object, requested properties form a priority list. When the next property would exceed the budget, the server omits that property and every property after it. The retained properties must be a prefix of the requested list.
Illustrative property priority in a prototype configurationjson
{ "properties": ["id", "from", "subject", "preview"] }
With that ordering, an oversized subject means both subject and preview are omitted, even if the preview alone would fit. I would put the properties needed for identification or display first. Clients must handle missing later properties without treating a partial notification as a malformed message. Measure serialized UTF-8 bytes rather than counting visible characters: non-ASCII text and JSON escaping affect the budget. Include long subjects in prototype tests instead of testing only short English examples.
The draft also says pushes are not a complete record of new mail. Push services can delay or drop notifications, so normal synchronization remains necessary through Email/changes or IMAP. A visible notification is a convenience; it cannot be the sole mechanism that keeps the local mailbox accurate.
Encryption still leaves timing and size visible
Section 6 of revision 04 now explicitly discusses metadata exposure. Even with encrypted contents, the push service can observe when each notification is sent and the encrypted payload size. That reveals the arrival timing of messages matching their configured filter and can support inferences about requested properties, such as subject length.
The text identifies optional padding supported by RFC 8188 as a mitigation for size exposure. Padding does not hide notification timing, and the draft does not make it mandatory. Privacy reviews should therefore consider both the selected notification properties and the information available to the push service.
Budget for padding too
Padding consumes payload capacity alongside encryption overhead. In a prototype, test the final encrypted size and check whether padding causes additional splitting or property omission.
What implementers should test in isolated prototypes
Email server developers need to examine subscription validation and the point where notifications are dispatched. Mobile mail app developers need to examine partial payload handling and recovery after missing pushes. Privacy teams need to decide which message details belong in notifications at all.
Start by reviewing the 03-to-04 diff, particularly sections 3, 4, and 6. Keep experiments isolated because the proposal remains work in progress. My prototype review would focus on observable outcomes rather than merely confirming that a subscription request returns success.
- Missing keys: Submit non-null emailPush with null keys. Expect rejection identifying both properties, with no sensitive notification sent.
- Verification gate: Deliver matching mail before and after subscription verification. Confirm that EmailPush delivery starts only after verification.
- Revoked access: Remove account access, then separately remove emailpush capability support. Confirm that notifications stop for the affected account.
- Payload budgets: Exercise multiple arrivals and oversized properties. Verify splitting, ordered-prefix omission, and the final encrypted payload size.
- State recovery: Delay or drop pushes deliberately. Confirm that normal Email/changes or IMAP synchronization recovers the mailbox state.
Minimize requested properties before tuning payload packing. If a notification needs only a generic arrival indication, the draft allows an empty properties list. Otherwise, request only the details the app actually displays. Avoid sending previews simply because the server supports them.
What this means for email authentication teams
This proposal concerns secure user notifications after email delivery. It does not change marketing or bulk sender rules. There is no DNS, SPF, DKIM, or DMARC change required because of revision 04, and the draft is not evidence that Gmail, Yahoo, or Microsoft has adopted this extension.
At Suped, our email tester analyzes authentication in a real test message, while our domain health checker checks domain authentication configuration. Those workflows support existing sender authentication work. They do not validate EmailPush encryption or subscription authorization, which require tests inside the server and client implementation.
Keep the draft review focused on notification boundaries
For teams experimenting with EmailPush, the useful next step is a focused prototype review: confirm that authorization still holds when a push is dispatched, and prove the client recovers without receiving every notification. Keep sensitive properties to the minimum needed for display. Track further working group revisions before treating any proposed behavior as a stable implementation target.
Frequently asked questions
No. It is an Internet-Draft under active JMAP working group development, not an RFC. Publication of this revision creates no deployment deadline or requirement for mailbox providers to support it.
No. Revision 03 already required encryption keys and client rejection of notifications not encrypted with those keys. Revision 04 adds explicit server rejection when emailPush is non-null and subscription keys are null.
No. Notifications can be delayed or dropped, and payload limits can remove requested properties. The client still needs normal Email/changes or IMAP synchronization to recover an accurate mailbox state.
No changes are required because of this proposal. Its checks concern push subscriptions and notification delivery, not the DNS records used to authenticate email senders.
