CURE: Consent Upon Recipient Engagement
draft-cure-core-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Madhu Balakrishna | ||
| Last updated | 2026-01-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cure-core-00
Network Working Group M. Balakrishna
Internet-Draft 24 January 2026
Intended status: Experimental
Expires: 28 July 2026
CURE: Consent Upon Recipient Engagement
draft-cure-core-00
Abstract
This document specifies CURE (Consent Upon Recipient Engagement), a
fully native, asynchronous mechanism for expressing and enforcing
recipient consent in email without introducing mailbox enumeration,
synchronous negotiation, or new SMTP commands. CURE does not
guarantee delivery, consent, or sender legitimacy; rather, it
provides a privacy-preserving signal that mailbox providers MAY use
to improve enforcement and sender accountability.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 July 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Balakrishna Expires 28 July 2026 [Page 1]
Internet-Draft CURE January 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Core Invariants . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 4
3.1. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. CURE-Ask (Consent Request) . . . . . . . . . . . . . 4
3.1.2. CURE-Allow (Consent Token) . . . . . . . . . . . . . 5
3.2. Granting Rule . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Exchange Flow . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Receiver Handling Guidelines . . . . . . . . . . . . . . 6
3.4.1. Prioritization . . . . . . . . . . . . . . . . . . . 6
3.4.2. Probationary Presentation . . . . . . . . . . . . . . 6
3.5. DNS-Based Discovery . . . . . . . . . . . . . . . . . . . 7
3.5.1. DNS Record Format . . . . . . . . . . . . . . . . . . 7
3.5.2. Discovery Process . . . . . . . . . . . . . . . . . . 8
3.5.3. Example DNS Records . . . . . . . . . . . . . . . . . 8
3.5.4. Caching and TTL . . . . . . . . . . . . . . . . . . . 9
3.5.5. DNS Security . . . . . . . . . . . . . . . . . . . . 9
4. State Machines (Normative) . . . . . . . . . . . . . . . . . 9
4.1. Sender State Machine . . . . . . . . . . . . . . . . . . 9
4.1.1. Sender States . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Sender Transitions . . . . . . . . . . . . . . . . . 9
4.1.3. Sender Invariants . . . . . . . . . . . . . . . . . . 10
4.2. Recipient Domain State Machine . . . . . . . . . . . . . 10
4.2.1. Recipient States . . . . . . . . . . . . . . . . . . 10
4.2.2. Recipient Transitions . . . . . . . . . . . . . . . . 10
4.2.3. Recipient Invariants . . . . . . . . . . . . . . . . 11
4.3. Observability Constraints . . . . . . . . . . . . . . . . 11
4.4. Forbidden Transitions . . . . . . . . . . . . . . . . . . 11
5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Common Grammar Elements . . . . . . . . . . . . . . . . . 12
5.2. CURE-Ask Header . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.2. Processing Rules . . . . . . . . . . . . . . . . . . 13
5.3. CURE-Allow Header . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 13
Balakrishna Expires 28 July 2026 [Page 2]
Internet-Draft CURE January 2026
5.3.2. Processing Rules . . . . . . . . . . . . . . . . . . 14
5.4. Token Return Format . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Recipient Enumeration . . . . . . . . . . . . . . . . . . 15
6.2. Token Replay and Forgery . . . . . . . . . . . . . . . . 15
6.3. Timing Side-Channels . . . . . . . . . . . . . . . . . . 15
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
7.1. Integrated Environments (Webmail) . . . . . . . . . . . . 15
7.2. Enterprise Gateways . . . . . . . . . . . . . . . . . . . 16
7.3. Standalone Clients (IMAP/POP) . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Data Minimization . . . . . . . . . . . . . . . . . . . . 16
8.2. Tracking Pixel Replacement . . . . . . . . . . . . . . . 16
8.3. Token Opaqueness . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. CURE-Ask . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. CURE-Allow . . . . . . . . . . . . . . . . . . . . . . . 17
9.3. CURE Scope Registry . . . . . . . . . . . . . . . . . . . 17
9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 17
A.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix B. Protocol Examples . . . . . . . . . . . . . . . . . 18
B.1. Introduction Request (Cold Start) . . . . . . . . . . . . 18
B.2. Explicit Token Return . . . . . . . . . . . . . . . . . . 18
B.3. Consented Delivery . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Current email standards lack a native mechanism for recipients to
express consent to senders without exposing their mailbox existence
or opening themselves to spam. Existing mechanisms often rely on
out-of-band subscriptions, synchronous SMTP extensions (which
disclose recipient existence), or content filtering (which is opaque
to legitimate senders).
The CURE protocol provides a minimal, email-native consent signal
that preserves SMTP's ambiguity regarding recipient existence while
enabling mailbox providers to enforce recipient intent. This
protocol does not attempt to fix email delivery guarantees, but
constrains how consent can safely emerge within the existing email
delivery architecture.
1.1. Core Invariants
The protocol adheres to the following design invariants:
Balakrishna Expires 28 July 2026 [Page 3]
Internet-Draft CURE January 2026
1. *Asynchronous*: No request/response semantics are introduced over
SMTP.
2. *Recipient-initiated*: Consent moves from the recipient to the
sender based on meaningful action, not unilaterally from sender
requests.
3. *Non-enumerable*: No signal in the protocol reveals mailbox
existence or state to a sender.
4. *Ignorable*: All components may be safely ignored by non-
participating senders or receivers without breaking email
delivery.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Terminology
* *Sender*: The domain sending email, authenticated via mechanisms
such as SPF, DKIM, and DMARC.
* *Recipient Domain*: The mailbox provider or system responsible for
receiving email and enforcing local policy.
* *Recipient*: The end user or entity whose actions may implicitly
grant consent.
* *CURE-Ask*: Consent Request, a header sent by the Sender.
* *CURE-Allow*: Consent Token, a header minted by the Recipient
Domain and returned to the Sender.
3. Protocol Description
3.1. Objects
The protocol defines two primary header objects:
3.1.1. CURE-Ask (Consent Request)
The CURE-Ask object is transported as an [RFC5322] header. It is
declarative, non-authoritative, and safe to ignore.
Example:
CURE-Ask: v=1; id=uuid; sender=sender.com; scope=transactional; \
rate=3/1h; purpose=account-notifications; \
expires=2026-02-01T00:00:00Z
Balakrishna Expires 28 July 2026 [Page 4]
Internet-Draft CURE January 2026
The Recipient Domain acts as the sole arbiter of scope. The scope
granted in a subsequent CURE-Allow token MAY differ from the scope
requested in CURE-Ask.
3.1.2. CURE-Allow (Consent Token)
The CURE-Allow object is cryptographically minted by the recipient
domain. It is never granted due to message delivery alone. The
token is bound to the recipient (typically hashed), sender identity,
scope, rate, and expiry.
3.1.2.1. Token Semantics and Construction
To allow stateless validation, it is RECOMMENDED that Recipient
Domains construct tokens using a keyed-hash message authentication
code (HMAC):
Token = Base64( HMAC-SHA256(SecretKey, SenderDomain + HashedRecipient
+ Expiry + Scope) )
This construction prevents the need for a stateful database of all
active tokens.
3.2. Granting Rule
Consent is granted *only* when the recipient *replies* to the
message. A reply is a universally observable email-native action
that can be detected by the Recipient MTA via outbound SMTP,
regardless of email architecture.
Consent is *never* granted by:
* Message delivery
* Message open
* Tracking pixels
* Passive rendering of content
* Clicking links (web-based, not email-native)
* Any action outside the email protocol
3.3. Exchange Flow
1. *Request*: The sender transmits an initial message containing the
CURE-Ask header.
2. *Processing*: The Recipient Domain receives the message. It MUST
validate the authentication status of the sender (DMARC
alignment). It MAY store the request properties internally but
sends NO response (neither SMTP nor email) to the sender at this
stage.
Balakrishna Expires 28 July 2026 [Page 5]
Internet-Draft CURE January 2026
3. *Action*: If the Recipient later acts meaningfully (per
Section 3.2):
* The Recipient Domain mints a CURE-Allow.
* The token is stored server-side.
4. *Token Return/Refresh (Optional)*:
* *Explicit*: The Recipient Domain MAY send a machine-readable
notification (see Section 5.4) to the sender. This
notification MUST be a separate message from any user-
generated reply. It MUST be sent to the address specified in
the rpt parameter of CURE-Ask, or the From address if rpt is
absent.
* *Refresh*: If an incoming message contains a valid CURE-Allow
token nearing expiry, the Recipient Domain MAY silently mint
and return a refreshed token to extend the consent window.
The absence of a token return is indistinguishable from denial or a
non-existent recipient.
3.4. Receiver Handling Guidelines
To mitigate the "Cold Start" problem while preventing abuse,
Receivers are advised to implement intelligent handling for
unsolicited messages containing valid CURE-Ask headers:
3.4.1. Prioritization
Receivers SHOULD NOT process incoming CURE-Ask requests on a strictly
First-Come-First-Serve (FCFS) basis. Doing so allows abusive senders
to flood the user's view, effectively starving legitimate
introduction requests (a Denial-of-Service attack).
Instead, Receivers SHOULD prioritize the presentation of requests
based on: 1. *Domain Reputation*: Age and historical volume
consistency of the Sender Domain. 2. *Authentication*: Strength of
DMARC policies (e.g., p=reject is preferred). 3. *User Signals*:
Implicit signals such as whether the user has previously interacted
with the domain.
3.4.2. Probationary Presentation
Receivers MAY route verified CURE-Ask messages to a dedicated
"Consent Review" interface or a distinct folder (e.g., "Requests").
Within this interface, Receivers SHOULD offer explicit controls:
* *Allow*: If the user explicitly accepts the request, the Receiver
has two implementation options:
Balakrishna Expires 28 July 2026 [Page 6]
Internet-Draft CURE January 2026
- *Integrated providers* (controlling both MUA and MTA): MAY
directly mint a CURE-Allow token without requiring an actual
reply, since they can observe the user's explicit consent
action.
- *Standard providers*: MAY automatically send a reply on the
user's behalf to trigger the consent mechanism, then mint the
token upon detecting the outbound reply.
* *Deny/Ignore*: If the user declines, the Receiver removes the
request. No signal is sent to the sender (indistinguishable from
non-delivery).
This explicit interaction model provides a better user experience
than requiring manual replies, while remaining compatible with the
email-native reply-based granting rule.
*Low-Friction Fallback*: Receivers unwilling to implement custom UI
controls MAY simply render the message as standard content. In this
mode, the Receiver relies on the user manually replying to grant
consent. This ensures backward compatibility with existing MUAs.
3.5. DNS-Based Discovery
To enable senders to discover whether a recipient domain supports
CURE before sending messages, recipient domains SHOULD publish a DNS
TXT record at the subdomain _cure under their primary domain.
3.5.1. DNS Record Format
The DNS TXT record MUST use the following format:
_cure.example.com. IN TXT "v=CURE1; capabilities=ask,allow; \
policy=default-scope:transactional; default-expiry:90d"
*Parameters:*
* *v* (required): Protocol version. MUST be CURE1 for this
specification.
* *capabilities* (optional): Comma-separated list of supported
features. Valid values:
- ask: Domain processes CURE-Ask headers
- allow: Domain mints and validates CURE-Allow tokens
- refresh: Domain supports token refresh
- explicit: Domain sends explicit token return notifications
* *policy* (optional): Semicolon-separated list of default policy
parameters:
- default-scope: Default scope granted if not specified in CURE-
Ask (e.g., transactional, promotional, relationship)
Balakrishna Expires 28 July 2026 [Page 7]
Internet-Draft CURE January 2026
- default-expiry: Default token expiry duration (e.g., 30d, 90d,
1y)
- max-rate: Maximum allowed rate limit (e.g., 10/1d, 100/1w)
- require-dmarc: If present, requires p=reject or p=quarantine
DMARC policy
If the capabilities parameter is omitted, senders SHOULD assume the
domain supports all features defined in this specification.
If policy parameters are omitted, senders SHOULD NOT make assumptions
about domain policy and rely on explicit CURE-Allow token parameters.
3.5.2. Discovery Process
Senders SHOULD perform DNS discovery as follows:
1. Extract the recipient domain from the email address (e.g.,
example.com from user@example.com)
2. Query for TXT records at _cure.<domain> (e.g., _cure.example.com)
3. If a valid CURE record is found, the domain supports CURE
4. If no record is found or the record is invalid, the sender MAY
still send CURE-Ask headers (per the Ignorable invariant)
3.5.3. Example DNS Records
*Full support with strict policy:*
_cure.gmail.com. IN TXT "v=CURE1; capabilities=ask,allow,refresh,explicit; \
policy=default-scope:transactional; default-expiry:90d; \
max-rate:10/1d; require-dmarc"
*Basic support with permissive policy:*
_cure.example.org. IN TXT "v=CURE1; capabilities=ask,allow; \
policy=default-scope:relationship; default-expiry:1y"
*Minimal declaration (no policy advertised):*
_cure.example.net. IN TXT "v=CURE1"
*Enterprise gateway with custom policy:*
_cure.corporate.com. IN TXT "v=CURE1; capabilities=ask,allow; \
policy=default-scope:promotional; default-expiry:30d; \
max-rate:5/1w; require-dmarc"
Balakrishna Expires 28 July 2026 [Page 8]
Internet-Draft CURE January 2026
3.5.4. Caching and TTL
Senders SHOULD cache DNS discovery results according to the TTL
specified in the DNS record. A recommended TTL is 86400 seconds (24
hours) to balance freshness with query load.
3.5.5. DNS Security
DNS discovery is subject to standard DNS security considerations.
Senders SHOULD use DNSSEC when available to validate the authenticity
of CURE DNS records. The absence of a CURE DNS record MUST NOT be
interpreted as the domain rejecting CURE-Ask headers.
4. State Machines (Normative)
This section defines the sender-side and recipient-domain-side state
machines for CURE. These state machines are normative and intended
to eliminate ambiguity in implementation.
State transitions MUST NOT expose mailbox existence, consent status,
or enforcement decisions to the sender.
4.1. Sender State Machine
4.1.1. Sender States
* *S0: No-Consent*: The sender possesses no valid CURE-Allow for the
recipient.
* *S1: Consent-Requested*: The sender has transmitted one or more
messages containing a CURE-Ask.
* *S2: Consent-Granted*: The sender possesses a valid CURE-Allow.
* *S3: Consent-Expired*: The sender previously possessed a CURE-
Allow, but it is no longer valid due to expiry.
* *S4: Consent-Revoked*: The sender possessed a CURE-Allow that has
been revoked by recipient policy.
4.1.2. Sender Transitions
+======+==================+====+================================+
| From | Event | To | Notes |
+======+==================+====+================================+
| S0 | Send message | S1 | No acknowledgment expected |
| | with CURE-Ask | | |
+------+------------------+----+--------------------------------+
| S1 | Send additional | S1 | Ask MAY be repeated or omitted |
| | messages | | |
+------+------------------+----+--------------------------------+
| S1 | Receive CURE- | S2 | Allow MUST be validated |
Balakrishna Expires 28 July 2026 [Page 9]
Internet-Draft CURE January 2026
| | Allow (explicit) | | |
+------+------------------+----+--------------------------------+
| S2 | Allow expires | S3 | Expiry handled locally |
+------+------------------+----+--------------------------------+
| S2 | Allow rejected | S4 | Rejection is indistinguishable |
| | during SMTP | | from other failures |
+------+------------------+----+--------------------------------+
| S3 | Send message | S1 | Fresh request |
| | with CURE-Ask | | |
+------+------------------+----+--------------------------------+
| S4 | Send message | S1 | Revocation does not prevent |
| | with CURE-Ask | | re-request |
+------+------------------+----+--------------------------------+
Table 1
4.1.3. Sender Invariants
* The sender MUST NOT assume consent based on message delivery or
lack of rejection.
* The sender MUST treat all SMTP failures identically.
* The sender MUST NOT probe for consent state.
* The sender MUST be prepared for CURE-Allow loss or revocation at
any time.
4.2. Recipient Domain State Machine
4.2.1. Recipient States
* *R0: Unknown*: No prior CURE interaction exists for the sender-
recipient pair.
* *R1: Pending*: A CURE-Ask has been observed but no consent has
been granted.
* *R2: Consented*: A valid CURE-Allow exists and is enforceable.
* *R3: Revoked*: Consent has been explicitly or implicitly revoked.
4.2.2. Recipient Transitions
+======+===============================+====+==================+
| From | Event | To | Notes |
+======+===============================+====+==================+
| R0 | Receive message with CURE-Ask | R1 | State MAY be |
| | | | transient |
+------+-------------------------------+----+------------------+
| R0 | Recipient meaningful action | R2 | Ask presence not |
| | | | required |
+------+-------------------------------+----+------------------+
| R1 | Recipient meaningful action | R2 | Allow minted |
Balakrishna Expires 28 July 2026 [Page 10]
Internet-Draft CURE January 2026
+------+-------------------------------+----+------------------+
| R2 | Allow expires | R0 | Expiry does not |
| | | | imply revocation |
+------+-------------------------------+----+------------------+
| R2 | Abuse signal / unsubscribe | R3 | Revocation is |
| | | | immediate |
+------+-------------------------------+----+------------------+
| R3 | Recipient meaningful action | R2 | Fresh consent |
| | | | minted |
+------+-------------------------------+----+------------------+
Table 2
4.2.3. Recipient Invariants
* Receipt of CURE-Ask MUST NOT alter SMTP behavior.
* CURE-Ask MUST NOT grant consent by itself.
* Absence of CURE-Ask MUST NOT prevent consent granting.
* Revocation MUST be silent and indistinguishable from non-
existence.
4.3. Observability Constraints
At no point MAY the sender reliably distinguish between:
* R0 (Unknown)
* R1 (Pending)
* R3 (Revoked)
* Non-existent recipient
SMTP responses, timing, and message acceptance MUST remain ambiguous
across these states.
4.4. Forbidden Transitions
The following transitions MUST NOT occur:
* R0 -> R2 solely due to message delivery.
* R1 -> R2 due to message open or passive rendering.
* Any sender state transition based on SMTP success.
* Any recipient transition that emits a synchronous signal.
5. Header Syntax
This section defines the formal syntax and processing rules for CURE
headers. All ABNF is defined using the Augmented Backus-Naur Form
(ABNF) as specified in [RFC5234].
Balakrishna Expires 28 July 2026 [Page 11]
Internet-Draft CURE January 2026
CURE introduces two new message headers:
* CURE-Ask: Consent Request
* CURE-Allow: Consent Token
Header field names are case-insensitive.
5.1. Common Grammar Elements
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
SP = %x20
HTAB = %x09
WSP = SP / HTAB
DQUOTE = %x22
field-name = ALPHA *(ALPHA / DIGIT / "-")
field-value = *(WSP / VCHAR)
version = 1*DIGIT "." 1*DIGIT
uri = "<" 1*(VCHAR) ">"
base64url = 1*(ALPHA / DIGIT / "-" / "_")
timestamp = 1*DIGIT
5.2. CURE-Ask Header
The CURE-Ask header signals the sender’s request for recipient
consent. Presence of this header does not imply delivery preference
or enforcement.
5.2.1. Syntax
Balakrishna Expires 28 July 2026 [Page 12]
Internet-Draft CURE January 2026
CURE-Ask = "CURE-Ask:" WSP ask-params
ask-params = ask-version *( ";" WSP ask-param )
ask-version = "v=" version
ask-param = ask-scope / ask-rate / ask-context / ask-rpt / ask-ext
ask-scope = "scope=" scope-token
scope-token = 1*(ALPHA / DIGIT / "-" / "_")
ask-rate = "rate=" 1*DIGIT "/" 1*DIGIT [ALPHA]
ask-context = "ctx=" uri
ask-rpt = "rpt=" uri
ask-ext = field-name "=" field-value
5.2.2. Processing Rules
* Senders MAY include CURE-Ask in any message.
* Absence of CURE-Ask MUST NOT prevent consent granting.
* Receivers MUST ignore unknown parameters.
* Presence of CURE-Ask MUST NOT affect SMTP responses.
5.3. CURE-Allow Header
The CURE-Allow header conveys a previously granted consent token.
Tokens are opaque to senders and only verifiable by the recipient
domain.
5.3.1. Syntax
Balakrishna Expires 28 July 2026 [Page 13]
Internet-Draft CURE January 2026
CURE-Allow = "CURE-Allow:" WSP allow-params
allow-params = allow-version ";" WSP allow-token *( ";" WSP allow-param )
allow-version = "v=" version
allow-token = "token=" base64url
allow-param = allow-expiry / allow-scope / allow-ext
allow-expiry = "exp=" timestamp
allow-scope = "scope=" scope-token
allow-ext = field-name "=" field-value
5.3.2. Processing Rules
* Senders MUST treat tokens as opaque.
* Senders MUST NOT attempt to infer recipient state from token
rejection.
* Receivers MUST validate tokens locally.
* Invalid, expired, or revoked tokens MUST be silently ignored.
5.4. Token Return Format
To enable automated processing by Senders, explicit token returns
MUST use the media type application/cure-token+json. The body of the
return message MUST contain a JSON object with the following
properties:
* *token* (string, required): The Base64 encoded CURE-Allow token.
* *scope* (string, required): The scope granted.
* *expiry* (string, required): ISO 8601 UTC timestamp of expiry.
* *issuer* (string, optional): The domain minting the token.
Example:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"scope": "transactional",
"expiry": "2026-07-28T00:00:00Z",
"issuer": "google.com"
}
Balakrishna Expires 28 July 2026 [Page 14]
Internet-Draft CURE January 2026
6. Security Considerations
This section analyzes CURE against the identified threats. CURE is
explicitly designed to avoid introducing new enumeration, probing, or
amplification vectors beyond those already present in SMTP.
6.1. Recipient Enumeration
CURE MUST NOT enable a sender to distinguish between existing and
non-existing recipients, nor between consented and non-consented
recipients.
CURE achieves this by:
* Prohibiting synchronous consent signaling.
* Requiring identical SMTP behavior regardless of CURE state.
* Mandating silent rejection of invalid, expired, or revoked tokens.
6.2. Token Replay and Forgery
CURE-Allow tokens are opaque and domain-scoped. Senders MUST treat
tokens as unstructured data. Recipient domains MUST ensure:
* Tokens are bound to the recipient domain.
* Tokens are not transferable across recipients.
* Replay is bounded via expiry and local rate limits.
6.3. Timing Side-Channels
Recipient domains MUST ensure that CURE processing does not introduce
observable timing differences. SMTP response timing MUST NOT vary
based on CURE state.
7. Deployment Considerations
To maximize coverage across diverse email architectures, CURE support
is divided into three deployment models:
7.1. Integrated Environments (Webmail)
Providers that control both the MTA and the MUA (e.g., Gmail, Yahoo)
CAN reliably detect all "Meaningful Actions," including clicks,
views, and replies. These providers SHOULD implement the
"Probationary Presentation" (Requests Folder) model described in
Section 3.4.2 to offer the best user experience.
Balakrishna Expires 28 July 2026 [Page 15]
Internet-Draft CURE January 2026
7.2. Enterprise Gateways
Corporate environments using Secure Email Gateways (SEGs) CAN detect
clicks via Link Rewriting and replies via outbound inspection. SEGs
SHOULD intercept CURE-Ask headers and afford administrative or end-
user controls to manage consent policies.
7.3. Standalone Clients (IMAP/POP)
Users on decoupled clients (Outlook Desktop, Thunderbird) connecting
to basic ISPs often cannot signal clicks to the Recipient Domain.
For these users, *Replying* remains the only universally observable
consent signal. Senders targeting these environments SHOULD
encourage reply-based consent workflows (e.g., "Reply to this email
to start receiving notifications").
8. Privacy Considerations
CURE is designed to improve recipient privacy by moving consent
negotiation out of the content layer (tracking pixels) and into the
protocol layer (headers).
8.1. Data Minimization
Senders receive NO information until the recipient explicitly acts.
The simple presence of a CURE-Ask header leaks no data.
8.2. Tracking Pixel Replacement
By providing a reliable channel for consent, CURE removes the
justification for "Open Tracking" pixels. Future receiver policies
MAY strictly block tracking pixels for senders who do not implement
CURE.
8.3. Token Opaqueness
Tokens MUST NOT contain PII visible to the sender. Senders MUST
treat tokens as opaque strings.
9. IANA Considerations
This document requests the registration of two new message headers in
the "Permanent Message Header Field Names" registry, a new media
type, and a new registry for CURE scopes.
9.1. CURE-Ask
* *Header field name*: CURE-Ask
Balakrishna Expires 28 July 2026 [Page 16]
Internet-Draft CURE January 2026
* *Applicable protocol*: mail
* *Status*: experimental
* *Author/Change controller*: IETF
* *Specification document*: this document
9.2. CURE-Allow
* *Header field name*: CURE-Allow
* *Applicable protocol*: mail
* *Status*: experimental
* *Author/Change controller*: IETF
* *Specification document*: this document
9.3. CURE Scope Registry
This document creates the "CURE Scope" registry. Initial entries:
* *transactional*: Strictly for transactional notifications
(receipts, alerts).
* *promotional*: For marketing or promotional content.
* *relationship*: For ongoing relational updates (newsletters,
digests).
9.4. Media Type Registration
* *Type name*: application
* *Subtype name*: cure-token+json
* *Required parameters*: None
* *Encoding considerations*: UTF-8
* *Security considerations*: See Section 6
* *Interoperability considerations*: See Section 5.4
Appendix A. References
A.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234,
January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
10.17487/RFC5322, October 2008.
Balakrishna Expires 28 July 2026 [Page 17]
Internet-Draft CURE January 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
Appendix B. Protocol Examples
B.1. Introduction Request (Cold Start)
The sender sender@example.com sends a first message to
receiver@example.net. Note the use of rpt to direct tokens to a
machine-readable endpoint.
From: sender@example.com
To: receiver@example.net
Subject: Welcome to Sender Service
Date: Mon, 25 Jan 2026 09:00:00 -0000
Message-ID: <msg1@example.com>
CURE-Ask: v=1; scope=relationship; rpt=mailto:tokens@example.com; rate=1/1d
Hello! Please reply to this email to subscribe to our updates.
B.2. Explicit Token Return
The recipient chooses to "Allow" or "Reply". The Recipient Domain
example.net generates a separate notification to tokens@example.com.
From: no-reply@example.net
To: tokens@example.com
Subject: CURE Token Delivery
Date: Mon, 25 Jan 2026 09:05:00 -0000
Content-Type: application/cure-token+json
{
"token": "dGhpcyBpcyBhIHZhbGlkIHRva2Vu...",
"scope": "relationship",
"expiry": "2026-07-25T00:00:00Z",
"issuer": "example.net"
}
B.3. Consented Delivery
The sender uses the token to deliver a subsequent message.
Balakrishna Expires 28 July 2026 [Page 18]
Internet-Draft CURE January 2026
From: sender@example.com
To: receiver@example.net
Subject: Your Weekly Digest
Date: Tue, 01 Feb 2026 09:00:00 -0000
Message-ID: <msg2@example.com>
CURE-Allow: v=1; token=dGhpcyBpcyBhIHZhbGlkIHRva2Vu...
Here is the update you requested.
Author's Address
Madhu Balakrishna
Email: madhugb04@gmail.com
Balakrishna Expires 28 July 2026 [Page 19]