Email AI-Processing Preference Signal

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

Relationship to Existing Work The AIPREF vocabulary proposal and HTTP attachment proposal 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.

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

The AI-Processing-Preference Header Field The proposed field name is AI-Processing-Preference. The field occurs at most once in the top-level 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 and the case-sensitive literals of . DIGIT, SP, and HTAB are core rules. Folding follows . 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.

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.

Message Scope and Source AssociationA 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 , rather than imposed as a universal mail-receiver policy here.

Forwarding and RepliesA 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.

Security ConsiderationsAn 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 . 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.

Privacy ConsiderationsThe 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.

IANA Considerations If this experiment proceeds, the author intends to request provisional registration in the message header field registry under . 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.

Experiment and Open IssuesInteroperability 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.