Email AI-Processing Preference Signal

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 10 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

Sending correspondence to a person or organization does not, by itself, communicate a preference about every automated use of that correspondence. A receiving system may summarize an email, retain extracted facts, correlate communications, infer characteristics about identifiable people, or supply content to a model provider. The sender may have no practical visibility into these activities.¶

This proposal provides a per-message signal that travels with email, rather than requiring senders to discover each recipient's tools. It specifies what the sender has expressed and how that expression remains associated with content. It does not prescribe a default processing policy for every mail recipient.¶

Ordinary email delivery, conventional storage, human reading, and necessary transport security are not prohibited by this signal. The proposal does not change SMTP or require an SMTP extension. Existing mail software can carry the field without understanding it. Such carriage provides no assurance that preferences will be honored.¶

The protective receiver handling profile is specified in [HANDLING]. A system can implement this signaling specification without claiming conformance to that profile; displaying a signal is not evidence that optional AI access has been controlled.¶

2. Relationship to Existing Work

The AIPREF vocabulary proposal [AIPREF-VOCAB] and HTTP attachment proposal [AIPREF-ATTACH] provide related work in progress. The HTTP proposal identifies email as a possible future attachment mechanism. This experiment uses a separate vocabulary to explore private correspondence, including non-generative profiling and persistent derived records. Its keys are not extensions registered under the AIPREF vocabulary and are not interchangeable with that vocabulary.¶

The AIPREF charter excludes technical enforcement of preferences. This document therefore confines its contribution to signaling, interpretation, and preservation. The separate handling profile proposes receiver controls. Community review should determine how this email vocabulary can align with AIPREF; separation alone does not establish charter fit or working group sponsorship.¶

3. 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.¶

Requirements apply only to implementations claiming conformance to this signaling specification.¶

• Sender: the declaring party responsible for the message preference statement; not necessarily the sole author or sole data subject.¶
• Covered content: the subject, body, attachments, and message-associated personal information used in a governed operation. Delivery addresses remain usable for ordinary delivery. Using addresses or other metadata for profiling is a governed operation.¶
• AI system: a learned model or agent using such a model to perform any of the operations defined below. Classification, ranking, and scoring are included; coverage is not limited to generative models.¶
• Participating implementation: software that generates, parses, displays, or preserves this field according to this specification. Receiver handling-profile conformance is a separate claim.¶
• Derived record: a summary, embedding, extracted fact, inferred label, score, or other content-derived representation. Encoding or transforming information does not remove its association with the source message.¶

The requirement-level conventions are collected in [BCP14].¶

4. The AI-Processing-Preference Header Field

The proposed field name is AI-Processing-Preference. The field occurs at most once in the top-level [RFC5322] header block. It is not a MIME part header. A sender implementing this mechanism MUST emit version 1 and MUST NOT emit duplicate keys. Field name matching is case-insensitive. Directive names and values are lowercase and case-sensitive.¶

The following ABNF defines the unfolded field body using [RFC5234] and the case-sensitive literals of [RFC7405]. DIGIT, SP, and HTAB are core rules. Folding follows [RFC5322]. Receivers MUST unfold before parsing, and MUST NOT interpret comments, encoded words, quoted strings, or natural-language message text as preference directives.¶

preference = OWS %s"v=1" 1*(OWS ";" OWS directive) OWS
directive  = key OWS "=" OWS value
key        = LCALPHA *(LCALPHA / DIGIT / "-")
value      = %s"yes" / %s"no" / %s"ask"
LCALPHA    = %x61-7A
OWS        = *(SP / HTAB)

At least one directive is required. There are no wildcard or blanket permission values. The version marker MUST appear first and MUST NOT occur again as a directive.¶

AI-Processing-Preference: v=1; assist=ask; memory=no;
 profile=no; train=no; external=no

yes expresses a favorable preference for the specified operation only. no expresses an objection. ask expresses a preference that separate confirmation be obtained before that operation. Omitted directives express no preference. None of these values establishes a legal basis or authorizes use of information about another person.¶

A missing field or omitted category means no preference was expressed for that category. Parsers MUST NOT convert absence into yes. This document does not decide whether processing may proceed when a preference is absent; that decision belongs to an applicable receiver policy or companion profile.¶

Duplicate fields or keys, malformed syntax, unsupported versions, and unknown directives produce an indeterminate statement in this version. A parser MUST report that status, MUST NOT select the first or last duplicate, and MUST NOT silently discard an unknown directive and report a fully understood statement. Implementations MUST distinguish an indeterminate statement from a valid statement containing omitted categories.¶

5. Operation Categories

• assist: supplying covered content to an AI system for immediate communication assistance, such as summarization, translation, reply drafting, or task extraction. This category alone does not cover keeping outputs for subsequent AI use.¶
• memory: retaining derived records for subsequent AI retrieval, correlation, or use beyond completion of the immediate task. Vector indexes and persistent agent memories are included. Ordinary mailbox retention is excluded, but future AI use of that mailbox requires a new operation assessment.¶
• profile: using AI to infer, classify, rank, or score an identifiable person or their relationships, circumstances, behavior, or likely actions. Complaint prioritization based on inferred attitude and purchasing-propensity scores are included.¶
• train: using covered content or derived records to train, fine-tune, distill, or otherwise adjust learned model parameters. This includes recipient-specific and vendor models, whether generative or non-generative. Retrieval without parameter changes is assessed under the other applicable categories.¶
• external: making covered content or derived records available for AI processing to a separate organization operating a processing service, including contractors and subprocessors. A provider's organizational affiliation, rather than the physical server location, determines applicability. Ordinary email transport is excluded.¶

Categories are cumulative. A task that sends content to an external model, summarizes it, and stores an embedding for later use implicates external, assist, and memory. Every applicable category must be assessed. Local processing does not exempt profiling, memory, or training. Calling a product a search tool or security tool does not change the actual purpose of an operation.¶

These categories describe preferences for optional AI uses of correspondence. Ordinary delivery, human reading, conventional mailbox storage, and narrowly necessary mail-service protection remain outside that scope. The companion profile defines the operational boundary for security processing. Product names do not determine whether a use belongs to a category.¶

6. Message Scope and Source Association

A statement applies to the message it accompanies, including attachments. It does not grant the sender authority over quoted correspondence, attachment creators, other data subjects, or all future messages in a conversation. A yes value MUST NOT be represented as permission from those other parties.¶

Different declaring parties can express different preferences for incorporated content. A parser MUST preserve separately identifiable statements and their source associations rather than treating an outer-message yes value as a replacement for incorporated statements. This specification does not determine legal priority among declaring parties.¶

For an encapsulated message/rfc822 attachment, its own top-level statement remains associated with that inner message. An outer statement remains applicable as a declaration about the encompassing message. Where software cannot recover the boundaries or origin of a plain-text quotation, it MUST NOT claim that the outer sender has supplied the quoted author's preference.¶

Conservative reconciliation for actual processing operations is specified in [HANDLING], rather than imposed as a universal mail-receiver policy here.¶

7. Forwarding and Replies

A participating client forwarding an unchanged message MUST preserve its field and source association. Encapsulation as message/rfc822 is preferable where it preserves original headers. A new forwarding message may carry its own statement, but MUST NOT erase or relabel incorporated declarations as the forwarding sender's own.¶

Reply preferences apply to the new reply content. They MUST NOT retrospectively change earlier statements. A client preserving quoted declarations SHOULD use source-associated metadata or encapsulation. No interoperable fragment-level format is defined here; an implementation MUST describe any limitations of its quotation preservation.¶

This version supplies no on-wire update, withdrawal, deletion, or acknowledgement mechanism. A new message does not automatically revoke or broaden an earlier statement. Separate instructions and legal obligations remain independent of this signal.¶

8. Security Considerations

An attacker can add, alter, remove, or duplicate an unsigned field. An absent field therefore cannot safely be interpreted as permission. Authentication of a message does not establish valid consent, sender authority over all content, or recipient compliance.¶

A participating sending domain SHOULD include this field in DKIM signature coverage and protect against insertion of additional occurrences as described by [RFC6376]. Receivers MUST distinguish verified coverage from mere presence of a signature. DKIM identifies a signing domain; it does not prove an individual's identity or ownership of the information.¶

Forwarders and mailing lists may alter headers or invalidate signatures. A receiver MUST NOT turn failed authentication into a favorable preference. Preservation of restrictions can be conservative without asserting that an unverified statement grants rights.¶

The field MUST be parsed deterministically, outside model interpretation. Natural-language instructions in the body MUST NOT be interpreted as field directives. Parsers SHOULD impose resource limits and MUST NOT truncate a field into an apparently favorable statement; an incomplete parse is indeterminate.¶

This field does not disable spam, malware, or abuse defenses and does not provide access control, remote attestation, or proof that a recipient honored a preference. Field preservation alone does not prove handling-profile conformance.¶

9. Privacy Considerations

The field itself reveals preferences that may be sensitive. Interfaces SHOULD display it accurately without implying that a favorable preference establishes legal consent or authority over other people's information. A sender cannot consent for every person mentioned in a message.¶

Software SHOULD avoid unnecessarily logging or distributing preference metadata. The signal does not discharge privacy, copyright, confidentiality, employment, or professional obligations. Embeddings and summaries are not presumed anonymous.¶

10. IANA Considerations

If this experiment proceeds, the author intends to request provisional registration in the message header field registry under [RFC3864]. No registration has been requested by preparing this document. The proposed template is:¶

Header field name: AI-Processing-Preference
Applicable protocol: mail
Status: experimental
Author/change controller: Lawrence Nault
  <lawrence@lawrencenault.me>
Specification document: this document, Section 4
  (field syntax and interpretation)
Related information: individual experimental proposal;
  not the AIPREF HTTP Content-Usage field

The field name and registry route require review before submission. This document creates no registry for directive names. Extensions require a new version and a published specification.¶

11. Experiment and Open Issues

Interoperability experiments should use independent generators and parsers with synthetic correspondence. Cases include folded fields, omitted categories, absent fields, duplicates, unknown directives, unsupported versions, DKIM coverage, mailing lists, forwarded messages, encapsulated messages, and mixed-source replies.¶

Useful results include parser agreement, field and source-association preservation rates, interface accuracy, and authentication failures. Experiments with this specification alone cannot claim to demonstrate that optional AI processing was prevented.¶

Community review should address vocabulary alignment with AIPREF, category boundaries, an interoperable fragment-level format, registry naming, and possible future acknowledgements or updates. The proposed five categories and absence-as-no-preference semantics are intentional design choices for this revision.¶

Author's Address