Akamind Inc.

jprimavesi@akamind.net https://akamind.net/

Applications and Real-Time email conversation threading This document defines an experimental Conversation-ID email header field. Participating originators can use it to associate messages with a conversation, alongside Message-ID, In-Reply-To, and References. The identifier is independent of any one message's Message-ID. Its usefulness depends on originators copying it into new messages and intermediaries preserving it during transport. The field is an untrusted grouping hint and provides no authentication or authorization. This document specifies its syntax and processing rules and describes an experiment to compare it with existing correlation methods.

Introduction Internet mail identifies messages with Message-ID and records reply relationships in In-Reply-To and References . These fields support threading even when some history is missing: the REFERENCES algorithm in , for example, accounts for truncated References fields. Some submission services replace a supplied Message-ID, as documented by the Amazon SES SendRawEmail API . An application may then fail to associate a reply with the message it sent if it has not retained the delivered identifier. Provider event data can expose assigned and original identifiers , allowing the application to maintain a mapping. A service API identifier is not necessarily the complete Message-ID field value. Conversation-ID adds an explicit, constant-size conversation identifier independent of any particular message. One possible use is a conversation continued by independently operated applications that do not share a complete reply history. A root Message-ID or provider identifier mapping may give equivalent results. The experiment compares these approaches to determine whether an explicit conversation field offers enough benefit to justify changes to originators and the additional exposure of correlation metadata. Transport preservation and reply propagation require separate support. A client can preserve an incoming message unchanged yet omit Conversation-ID from the reply it generates. Existing clients are not required to copy this field, and nonparticipating intermediaries may remove it. Grouping policy remains local. This document defines no universal grouping algorithm, SMTP extension, or conversation discovery service.

Terminology and Scope 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. The terms Mail User Agent (MUA), Mail Submission Agent (MSA), and Mail Transfer Agent (MTA) follow . A participating originator is an MUA or application implementing this specification, or an MSA acting on its behalf with sufficient conversation context. The requirements apply to implementations of this experiment. A conversation is a context that an originator intends to continue across messages. Recipients apply their own grouping and access-control policies. The originator's assertion does not establish membership or require recipients to display the same thread; it does not define a global equivalence relation.

The Conversation-ID Header Field

Syntax and Cardinality Conversation-ID is an optional, structured Internet mail header field. A generated message MUST contain no more than one instance of this field. It is not a trace field and does not form part of a Resent-* block. The following syntax uses ABNF . FWS is imported from , Section 3.2.2. HEXDIG and CRLF are imported from , Appendix B.1. Quoted ABNF strings are case-insensitive. The value is a UUID version 4 URN , Sections 4 and 5.4. Only version 4 with the two high-order variant bits set to 10 is accepted. White space is allowed only outside the complete cid-value token. Parameters, comments, quoted strings, angle brackets, and lists are not allowed. A newly generated field MUST use lowercase for the URN prefix and hexadecimal digits. Generators SHOULD emit one SP after the colon, no trailing white space, and no folding. They MUST NOT generate obsolete folding syntax. In this form the field is 62 ASCII characters excluding its terminating CRLF:

Parsing and Equality A receiver MUST count all field instances using a case-insensitive comparison of the field name before selecting a value. If there is exactly one instance, the receiver unfolds it according to and removes surrounding SP and HTAB characters from its field body. The remaining 45-octet token MUST match cid-value in . Receivers MUST accept uppercase and mixed-case forms allowed by the ABNF. Two valid values are equal if their UUIDs contain the same 128 bits. Lowercasing the complete validated ASCII token gives an equivalent comparison. Internal white space, an unsupported UUID version or variant, or additional content makes the field unusable. Receivers MUST NOT repair such content into a valid identifier. If the field is absent, malformed, or present more than once, a receiver MUST NOT use any Conversation-ID value from that message for conversation correlation. This rule applies even when duplicate instances have identical values or only one is valid. A receiver MUST NOT reject delivery solely because the field is absent, invalid, or duplicated. It processes the message using its existing mechanisms and policies. Normal message-size, syntax, and security limits still apply. Ignoring the field does not require changing the stored or relayed message.

Semantics A valid Conversation-ID expresses the originator's intention to associate a message with a conversation. Originators MUST still construct Message-ID, In-Reply-To, and References according to , including their generation and uniqueness rules. Matching Conversation-ID values alone MUST NOT be treated as sufficient evidence for automatic grouping. Receivers need additional evidence evaluated under local policy, such as known reply relationships together with participant checks, a trusted application's stored conversation context, or an explicit user decision. Neither a Subject match nor an unauthenticated From address establishes that evidence by itself. If Conversation-ID conflicts with established reply relationships or an existing local grouping, receivers MUST NOT merge conversations solely to honor it. They MAY ignore the field or request an explicit grouping decision. A different or missing Conversation-ID does not require splitting messages already associated through other evidence. Global conflict resolution and identifier aliasing are outside the scope of this document.

Generation A participating originator MAY generate a Conversation-ID when starting a conversation. It MUST use a fresh UUIDv4 generated with a cryptographically secure random source, as discussed in , Section 6.9. The remaining 122 bits MUST be random; implementations MUST NOT encode a user, customer, campaign, tenant, host address, or timestamp in them. The identifier MUST NOT deliberately be reused across unrelated conversations. It MUST NOT be derived from message content, an address, a subject, or an application identifier. An MSA without sufficient conversation context MUST NOT add this field merely because an incoming submission lacks it. An identifier can be introduced into an existing conversation. It applies from that point onward; earlier messages remain unchanged. Independent participants might introduce different identifiers into the same discussion. Such conflicts are handled as described in .

Replies and Conversation Boundaries For a reply intended to continue its parent's conversation, a participating originator SHOULD include Conversation-ID. If it includes the field and the parent has a valid identifier, it MUST reuse that identifier. It MAY omit the field under an applicable security or privacy policy. Included identifiers use the format in . Parallel replies can share a Conversation-ID while retaining distinct Message-ID values and reply relationships. If the parent has no usable field, an originator MAY reuse an identifier already associated with that parent in trusted local state. Establishing that association requires the checks in . Otherwise, it MAY omit the field or generate a fresh identifier. It MUST NOT pick one value from duplicated or malformed fields as a substitute for that state. A participating application MAY also reuse an identifier from trusted local state in a non-reply message that continues an established conversation. Sharing a Conversation-ID does not require adding In-Reply-To or References where no corresponding reply relationship exists. When starting a separate conversation, including a private branch, the originator MUST either generate a fresh identifier or omit the field. A changed Subject alone does not establish that intention. An implementation SHOULD let its user or calling application choose whether to start a separate conversation. A user-composed forward, including a forward as an attachment, SHOULD be treated as a new conversation by default. An explicit decision to continue the same context MAY retain the identifier, after considering the changed audience. Fields in an attached message apply to that message and are not automatically inherited by the outer message. Existing reply-field semantics still apply.

Relay, Redistribution, and Stored Messages Except when applying the removal policy below, an MSA, MTA, or gateway implementing this specification MUST preserve a single valid Conversation-ID during ordinary submission or relay, including when it assigns a different Message-ID. The same requirement applies to a participating mailing-list redistributor or automatic forwarder when forwarding the same message. An implementation MUST NOT replace that valid identifier merely because Message-ID changes. An intermediary MAY remove the field to enforce an explicit security or privacy policy at a processing boundary. This exception permits removal, not replacement during ordinary relay. Removal loses the additional correlation signal but cannot make earlier copies unlinkable. When preserving a field, implementations SHOULD leave its wire representation unchanged; even semantically harmless rewriting can affect signatures. The experiment depends on preservation along the delivery path, including through nonparticipating intermediaries that have no obligation to preserve the field. Removal and its effect on correlation are measured under . Stored correlation metadata SHOULD be kept separately from the original message. A service MUST NOT alter a stored original or a message accepted for delivery or ordinary relay solely to add its local Conversation-ID. A participating MSA acting on behalf of the originator can add the field during initial submission if it has sufficient conversation context and follows the generation, propagation, and cardinality rules. The effects on existing signatures are described in .

Relationship to Existing Mechanisms The name Conversation-ID also appeared in the expired PePP instant-messaging proposal , Section 6.19. That proposal provides historical context. This specification defines the field for Internet mail and does not specify interoperability or a shared identifier namespace with PePP. Message-ID identifies a message, while In-Reply-To and References describe its ancestry . Conversation-ID does not recover missing ancestors or establish message order. References can be folded across lines, so the per-line length limit is not a limit on the total length of that field. IMAP THREAD , IMAP OBJECTID THREADID , and JMAP threadId expose server-computed groupings or identifiers. A server MAY consider a valid Conversation-ID under local policy, but MUST NOT infer that it can change an already assigned server identifier in violation of those protocols. This specification defines no direct mapping or shared namespace between Conversation-ID and those identifiers. The experiment also compares approaches based on root Message-ID values, provider identifier mappings, and application-specific reply routing where available. Existing fields such as Thread-Index and Thread-Topic are unaffected.

Experiment Plan The experiment will compare existing correlation methods with and without Conversation-ID across independently operated systems, considering grouping errors, disclosure risks, and integration effort. This revision reports no measurements.

Evaluation and Reporting Reports should distinguish participating originators from unmodified clients, and transport preservation from propagation into replies. Record client and server versions, submission paths, enabled features, and test dates. Use synthetic messages or appropriately redacted fixtures so that others can reproduce the results. The baseline should use correctly generated reply fields and available mappings between original and delivered Message-ID values. Tests should cover replies, reply-all, concurrent replies, changed subjects, private branches, mailing lists, user-composed and automatic forwards, and removal of Conversation-ID. Include forged identifiers, duplicate fields, malformed values, conflicting ancestry, and cross-tenant input. Report transport preservation, reply propagation, correct correlations, false merges, false splits, integration effort, and mapping-maintenance cost separately, including changes from the baseline. Tests between services under common control do not by themselves establish independent implementation. Report negative results as well, including loss of the field on common paths and cases where it provides no additional benefit. A successful result should show reproducible gains on documented paths between independently implemented participants, including handling of conflicts and legacy clients. Any unauthorized cross-account disclosure blocks deployment. If propagation changes prove impractical or the field offers no useful gain over the baseline, the design should be revised or the experiment discontinued.

Planned Evaluation Environment Note to the RFC Editor: remove this subsection before publication. The author plans to evaluate the field in Oveyon (https://oveyon.com/), an email service operated by Akamind Inc. Independent MUA, helpdesk, and mail-service implementers are invited to take part. Later revisions can document verified implementation status and interoperability results following .

Security Considerations An attacker can copy or choose a syntactically valid identifier; UUID uniqueness does not prevent deliberate reuse. Receivers MUST NOT treat possession of a Conversation-ID as permission to retrieve history, join a private conversation, select another tenant, or trigger a privileged action. Automated agents and workflow systems need authorization checks independent of this field. Correlation lookups MUST remain inside the applicable account, tenant, mailbox, or otherwise authorized processing context. Implementations MUST NOT automatically merge records across access boundaries because identifiers match. Authentication of a sender alone does not establish that sender's authority over a particular conversation. An originator including Conversation-ID in a message it signs with DKIM SHOULD add the field before generating the signature and SHOULD include it among the signed header fields. Signers SHOULD consider protecting against insertion of another instance as described in , Section 5.4. Verification authenticates the signing domain's assertion and the covered content. It does not establish conversation membership or identify the party that created the identifier. If a gateway adds Conversation-ID after DKIM signing, a signature whose h= list omits the field name does not cover the added field. The addition alone does not invalidate that signature. If the signer listed Conversation-ID in h= when the field was absent, adding it causes that signature to fail verification; see , Sections 3.5 and 5.4. A later signature covering the field conveys that signer's assertion; it does not extend or repair an earlier signature. Implementations evaluating integrity MUST determine whether a successfully verified signature covers the field. A message-level DKIM pass is insufficient. Signing does not permit field insertion prohibited by . Implementations MUST apply the duplicate and malformed-field rules in , bound parsing and storage work, and treat the value as data. They MUST NOT automatically resolve the URN or fetch an external resource solely because the field is present. Authorized lookups in implementation storage or configured services remain possible. No origin authority or resource-resolution mechanism is defined. Without an applicable integrity mechanism, removal of the field may go undetected. Its absence MUST NOT grant additional privileges or bypass existing policy. Adding a valid field MUST NOT increase trust in message bodies or instructions supplied to automated agents.

Privacy Considerations A stable identifier allows recipients, intermediaries, archives, and log operators to correlate messages. It can expose relationships even when addresses or subjects differ. discusses correlation and secondary-use risks. UUIDv4 avoids encoding a host address or timestamp, but the identifier is neither secret nor resistant to tracking. Originators MUST NOT deliberately reuse it as a customer, campaign, or cross-conversation tracking identifier. Private branches and forwards follow the boundary policy in . Removing Conversation-ID leaves other possible links through References, quoted content, and attachments. Operators SHOULD minimize retention and sharing of identifiers in telemetry and public test reports. Users or applications SHOULD be able to omit the field when exposing conversation continuity is inappropriate.

IANA Considerations IANA is requested to register Conversation-ID in the Provisional Message Header Field Names registry using the following template.

Header field name:

Conversation-ID

Applicable protocol:

mail

Status:

provisional

Trace:

no

Author/Change controller:

Juliano Primavesi, Akamind Inc.; jprimavesi@akamind.net

Specification document(s):

This document, .

Related information:

None.

Provisional registration does not imply endorsement by the IETF or IANA.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Informative References This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. Amazon Web Services Accessed 10 October 2026. Amazon Web Services Accessed 10 October 2026. Fujitsu Fujitsu Fujitsu Fujitsu Fujitsu This document describes a protocol designed for scalable and secure Instant Messaging and Presence Services. The protocol, Privacy enhanced Presence Protocol (PePP), has been developed for an experimental Presence Service and recently extended to satisfy a variety of requirements for the Internet-wide, interoperable standards. This is a protocol proposal for the IMPP Working Group. Expired historical proposal; cited for context only.

Illustrative Message Sequence These field fragments omit unrelated fields. Alice originates a message with a fresh identifier: To: Bob Subject: Project discussion Message-ID: Conversation-ID: urn:uuid:550e8400-e29b-41d4-a716-446655440000 ]]> Bob's participating client continues that conversation. The Message-ID changes and the Conversation-ID stays the same: To: Alice Subject: Re: Project discussion Message-ID: In-Reply-To: References: Conversation-ID: urn:uuid:550e8400-e29b-41d4-a716-446655440000 ]]> If a submission service instead delivered Alice's Message-ID as <wire1@example.org>, Bob's reply fields would reference that delivered identifier. A preserved Conversation-ID could still supply the same additional hint when Bob's client participates. For a third case, assume Message-ID was rewritten as above and Bob uses a nonparticipating client. Its reply might contain these fields, with no Conversation-ID: To: Alice Subject: Re: Project discussion Message-ID: In-Reply-To: References: ]]> Alice's application correlates this reply using the conventional reply fields and any trusted local mapping from <wire1@example.org> to <m1@example.com>, subject to . The missing field does not by itself start a new conversation or constitute a delivery error. If the available evidence is insufficient, the application can leave the reply ungrouped pending a local or user decision. If trusted local state associates the reply with the earlier conversation, Alice can reuse its identifier in a newly composed response as described in . Her application does not insert the missing field into Bob's stored message; see . If Bob forwards the message to Carol to start a private discussion, the outer message uses a fresh identifier or omits Conversation-ID. It does not automatically inherit Alice's identifier from quoted or attached content.