Network Working Group L. Nault Internet-Draft 7 October 2026 Intended status: Experimental Expires: 10 April 2027 Handling Email AI-Processing Preferences draft-nault-email-ai-handling-00 Abstract This document proposes an experimental receiver handling profile for the companion Email AI-Processing Preference Signal. It requires evaluation before optional AI access, independent checks for each applicable use, and a protective default when a preference is absent. It addresses confirmation, mixed-source content, derived records, and usable ordinary communication when optional processing is declined. Requirements apply to systems claiming this profile, not to all Internet mail recipients; the profile does not determine legal consent. Editorial Status This note is to be removed before publishing as an RFC. This is an individual experimental proposal presented for community discussion and technical review. It results from splitting an earlier combined manuscript into a signaling specification and a companion receiver handling profile. It does not represent IETF or working group consensus. Names, vocabulary, and intended status remain provisional. Publication as an Internet-Draft does not establish an Internet Standard. 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." Nault Expires 10 April 2027 [Page 1] Internet-Draft Email AI Preference Handling October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Conformance . . . . . . . . . . . . . . . . . 3 3. Processing Boundary and Protective Default . . . . . . . . . 3 4. Mixed-Source Content and Conflicting Preferences . . . . . . 5 5. Derived Records and Subsequent Use . . . . . . . . . . . . . 5 6. Necessary Mail-Service Protection . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Experiment and Open Issues . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction A sender may choose to communicate without choosing to have an AI agent analyze, remember, profile, or train on that correspondence. This profile turns a preference signal into a defined admission policy for participating receiving systems. The profile separates accepting an email from admitting its content to optional AI processing. It leaves ordinary delivery, human reading, and conventional storage available. It does not claim to impose duties on all Internet recipients, prevent a malicious recipient from copying content, or settle legal authority. Nault Expires 10 April 2027 [Page 2] Internet-Draft Email AI Preference Handling October 2026 This document is separate from the signaling specification because receiver controls are an additional commitment. It does not claim that these controls fall within the current AIPREF working group charter. Syntax, category meanings, and message scope are defined by [SIGNAL]. This profile uses those definitions without adding new field directives. 2. Conventions and Conformance 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 receiver handling profile. A conforming receiver MUST implement the companion signal parser and all requirements of this profile across every optional AI path to covered content. Conformance cannot be limited to a visible assistant while an ungoverned background connector accesses the same content. The five categories are assist, memory, profile, train, and external. They are cumulative: summarization by an external provider followed by persistent embedding storage requires separate checks for assist, external, and memory. Authorizing one category MUST NOT authorize another by implication. The requirement-level conventions are collected in [BCP14]. 3. Processing Boundary and Protective Default The following requirements apply only to receivers claiming conformance to this handling profile. They do not impose requirements on all Internet mail recipients or guarantee enforcement against a non-participating recipient. A handling-profile receiver MUST evaluate preferences before exposing covered content to an AI model, AI agent, embedding service, or governed external processor. Header parsing and permission lookup MUST occur outside that governed processing path. The system may accept and store the message in an ordinary mail environment while making it unavailable to the optional AI path. Nault Expires 10 April 2027 [Page 3] Internet-Draft Email AI Preference Handling October 2026 For each requested operation, the receiver MUST identify every applicable category and evaluate each source preference. An explicit no blocks that operation under this profile. ask requires separate, purpose-specific confirmation from the relevant declaring party through an appropriately verified channel. yes satisfies only the expressed-preference check; legal authority, purpose, minimization, and confidentiality checks remain separate. A sender's yes MUST NOT be treated as consent on behalf of another person mentioned in the content. A missing field or omitted key means no preference was expressed. Under this profile, the optional operation MUST remain on hold unless a separate, documented instruction or agreement from the relevant declaring party covers that category and content scope. The recipient's decision to enable an agent, the recipient's acceptance of provider terms, and mere receipt of correspondence MUST NOT be treated as the sender's authorization. An indeterminate statement, including malformed syntax, unsupported versions, duplicate fields or keys, or unknown directives, MUST place optional AI processing on hold until the ambiguity is resolved with an adequately verified instruction covering the proposed operation. Receivers MUST NOT silently select the first or last duplicate. Ordinary delivery remains available. These conservative extension rules require evaluation during the experiment. A receiver MUST NOT reject a message solely because the sender declines optional AI processing. Where communication can be provided independently of that optional processing, it MUST provide a usable route outside the optional AI path. A service whose essential requested function is AI processing can explain that limitation without treating refusal as agreement. Confirmation MUST identify the requested purposes and any external processors with sufficient specificity to make the choice understandable. Confirmation MUST occur before processing, not after uploading the content to obtain an AI-generated consent request. This draft specifies no automatic challenge-response protocol. 1. Accept the message into the ordinary mail environment. 2. Parse the signal and identify source associations outside the optional AI path. 3. Identify every category implicated by the proposed operation. 4. Evaluate preferences, any separately recorded authorization, and independent applicable obligations. Nault Expires 10 April 2027 [Page 4] Internet-Draft Email AI Preference Handling October 2026 5. Admit the operation only if every required check passes; otherwise retain the ordinary communication route. A confirmation process MUST NOT invite an AI system to inspect content already held pending confirmation. Receivers SHOULD use static notices and limit notice data to what is necessary. Permission records SHOULD identify the content scope, categories, confirmation method, and applicable version without storing the correspondence itself unnecessarily. A separate confirmation MUST be category-specific and content-scoped; it MUST NOT create a blanket authorization for other purposes or future correspondence. This profile does not define a technical consent-receipt format or assert that its confirmation method satisfies any jurisdiction's legal requirements. 4. Mixed-Source Content and Conflicting Preferences The receiver MUST inspect top-level statements in encapsulated message/rfc822 messages before admitting that content to an optional operation. It MUST retain separately identifiable source statements and evaluate every applicable source for an operation that combines messages or attachments. Any applicable no blocks the operation. Any applicable ask keeps the operation on hold until the necessary confirmation exists. Any missing category requires a separate applicable instruction or agreement under the protective default. All applicable yes values satisfy only the preference check. This rule deliberately avoids treating an unspecified source as yes; it does not determine ownership or legal priority. If trustworthy source separation is unavailable, the receiver MUST apply known restrictions to the entire combined operation. Plain- text quotations may have unrecoverable origin. The receiver MUST NOT invent permission from quoted authors or represent an outer sender's choice as theirs. Questions of independent authority over information about other people require separate assessment. 5. Derived Records and Subsequent Use A receiver creating permitted derived records MUST preserve applicable source restrictions in its internal records and enforce them on later governed operations. A vendor must not receive unrestricted data solely because it is a summary or embedding. When a permitted output incorporates several sources, later operations require assessment of all associated source restrictions. Nault Expires 10 April 2027 [Page 5] Internet-Draft Email AI Preference Handling October 2026 Keeping an immediate summary solely as an ordinary human-readable communication record does not automatically authorize subsequent AI use. Creating or retaining it for future agent retrieval implicates memory. Any later training, profiling, or external processing requires its own category check against the preserved source preferences. This profile defines no on-wire withdrawal or update mechanism. A new message MUST NOT automatically broaden earlier preferences. A separately verified subsequent instruction can change the recorded handling choice for a specified source, category, and content scope, but the receiver MUST retain enough evidence to distinguish that instruction from the original signal. Deletion and withdrawal obligations under law or agreements remain independent. 6. Necessary Mail-Service Protection A narrow exception permits processing necessary to deliver and protect the mail service, including spam, malware, phishing, and abuse detection. The exception applies to proportionate protection tasks and their necessary security records; it does not cover general assistant functions, commercial profiling, or reuse to train general- purpose models. The necessity, retention, and permissible security- specific model development remain subject to applicable law and require further review during this experiment. The receiver MUST keep security processing separate from optional assistance, memory, commercial profiling, and general-purpose training. It MUST NOT classify an optional feature as necessary solely because the vendor bundled it into a mail product. This experiment does not provide a blanket permission to develop security models using correspondence; applicable authority and scope must be assessed separately. 7. 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. Nault Expires 10 April 2027 [Page 6] Internet-Draft Email AI Preference Handling October 2026 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. Preference handling MUST use a deterministic parser rather than model interpretation. Prompt instructions in message content MUST NOT override a field or a held-processing decision. Parsers SHOULD impose resource limits consistent with mail-service protection and MUST NOT truncate a field into an apparently permissive value. The field does not instruct systems to bypass spam, malware, or abuse defenses. Attackers may use no or ask values to create operational load. Systems SHOULD use the ordinary communication route without sending automated notices for every held message. Any automated replies must follow [RFC3834] safeguards against loops and unsolicited responses. The mechanism neither prevents exfiltration by a malicious recipient nor supplies end-to-end access control. Claims of compliance require separate evidence; this draft defines no remote attestation or audit protocol. The profile MUST NOT grant optional AI access merely to resolve an ambiguous preference or generate a confirmation request. External services used to verify identity or send notices also require data minimization and appropriate independent authority; confirmation must not disclose the held correspondence unnecessarily. 8. Privacy Considerations The field itself reveals preferences that might be sensitive. Implementations MUST NOT use a person's refusal as input to profiling, marketing segmentation, or adverse ranking. Necessary preference handling is distinct from learning characteristics about the sender. A preference is not a consent receipt. A yes value does not discharge privacy, copyright, confidentiality, employment, professional, or other obligations. The sender cannot consent for every person mentioned in a message. Applicable law may require further notice or express agreement even where a favorable preference is present. Nault Expires 10 April 2027 [Page 7] Internet-Draft Email AI Preference Handling October 2026 Admission controls must also cover background indexing, connected mailbox APIs, backups exposed to agents, connector caches, and derived records. A visible assistant that honors the field cannot establish compliance if another pipeline processes the same content first. Implementations SHOULD minimize preference logs and restrict access to them. Ordinary retention and deletion duties are unaffected. This experiment makes no claim that embeddings are anonymous or that deleting an email deletes its derived records. Refusal of optional AI processing MUST NOT itself justify poorer service or adverse treatment unrelated to the declined operation. Where the requested service can proceed without that processing, the receiver MUST NOT make agreement to it a condition of ordinary communication. 9. IANA Considerations This document requests no IANA action. The proposed header field registration belongs to the companion signaling specification. This profile adds no field names, values, or registry entries. 10. Experiment and Open Issues An experiment should use synthetic messages and independently instrument the boundary before model, embedding, or external-provider access. Cases include explicit refusal, ask without confirmation, absent fields, partial preferences, conflicting incorporated content, duplicate fields, unknown directives, failed authentication, and later use of derived records. Tests should demonstrate that declined or unresolved operations make no content-bearing request to the optional AI service while ordinary delivery and usable communication continue. Tests should also verify that permission for assistance does not permit memory, profiling, training, or external processing. Useful measurements include mistaken admission rates, category interpretation agreement, preservation of restrictions in derived records, and usability of the ordinary communication route. The handling profile needs technical and operational review; successful file rendering does not demonstrate implementation conformance. Nault Expires 10 April 2027 [Page 8] Internet-Draft Email AI Preference Handling October 2026 Open issues include confirmation evidence, scope changes and withdrawal, mixed-source provenance, retention of security records, necessary security-specific model development, accessibility boundaries, and evaluation of the protective default. Legal requirements remain jurisdiction-specific and outside the protocol's authority. 11. References 11.1. Normative References [BCP14] Bradner, S. and B. Leiba, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, RFC 8174, May 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004, . [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [SIGNAL] Nault, L., "Email AI-Processing Preference Signal", Work in Progress, Internet-Draft, draft-nault-email-ai-signal- 00, 7 October 2026, . 11.2. Informative References Author's Address Lawrence Nault Email: lawrence@lawrencenault.me Nault Expires 10 April 2027 [Page 9]