| Internet-Draft | fmsg: Structured Host-to-Host Messaging | July 2026 |
| Mennell | Expires 7 January 2027 | [Page] |
fmsg is a message exchange protocol between domain defined hosts. Messages are binary encoded and form threads which require participation to reply to.¶
This document describes the motivation and architecture of fmsg, an existing protocol specification and implementation are referenced, but the full specification is not included here. The purpose of this document is to solicit IETF feedback on venue and scope before/if the specification can develop into standards-track documents.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://markmnl.github.io/fmsg-internet-draft/draft-mennell-art-fmsg-structured-messaging.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mennell-art-fmsg-structured-messaging/.¶
Discussion of this document takes place on the Applications and Real-Time Area Area mailing list (mailto:dispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dispatch/. Subscribe at https://www.ietf.org/mailman/listinfo/dispatch/.¶
Source for this draft and an issue tracker can be found at https://github.com/markmnl/fmsg-internet-draft.¶
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 7 January 2027.¶
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.¶
This document introduces fmsg, an open message exchange protocol that provides ownership and control at the domain level. First the motivation for fmsg is discussed from three main points: efficiency, structured threads and built-in verifications. Then the architecture is discussed: domain defined hosts, messages, threads and the protocol steps to perform message exchange.¶
Much of the architecture of fmsg is based on: fmsg is just messages. To receive a message, an fmsg address belonging to a domain has to send it to you. Group conversations emerge as participants reply to messages and add additional recipients over time.¶
Scope and request for feedback is made with suggestion on future document structure splitting the message definitions, protocol and transports.¶
This document uses the following terms:¶
Address: An fmsg address in the form @user@example.com identifying a recipient within a domain.¶
Client: An end application that sends and receives messages belonging to a particular Address via their Host.¶
Host: An implementation of the fmsg protocol responsible for sending and receiving messages to and from other fmsg hosts.¶
Sending Host: The Host transmitting a message.¶
Receiving Host: The Host receiving a message.¶
Message: An immutable data structure containing all the fields, content and attachments.¶
Thread: A directed acyclic graph (DAG) of messages formed by references from each message to a previous message.¶
Recipient: An Address identified in a message as an intended recipient.¶
Sender: The Address originating a message.¶
Participants: The Sender and all Recipients of a message. Only Participants may reply to a Message or add additional Recipients to a Thread.¶
The design of fmsg was motivated by three primary objectives.¶
First, to provide the most efficient practical message exchange while preserving the capabilities that have made Internet email successful. In particular, fmsg retains unsolicited messaging, multiple recipients, any media type, file attachments and ownership and control at the domain level.¶
Second, to make conversation structure part of the protocol itself. Rather than relying on application-specific heuristics to reconstruct message threads, fmsg messages explicitly reference previous messages using cryptographic hashes. This allows participants to independently construct deterministic, verifiable message threads and enables 1) verifying prior participants, and 2) consistent presentation of conversations across implementations.¶
Finally, to integrate sender verification and message integrity into the message exchange protocol. Rather than relying solely on complementary protocols or deployment-specific mechanisms, fmsg incorporates these properties into the architecture of message exchange itself. This is intended to simplify host deployment and operating hosts. The combination of sender verification and proof of prior participation (enabled by threads) helps inform implementation filtering policies.¶
This section describes the architecture of fmsg in terms of its core objects (messages, threads, participants and hosts) and the message exchange between hosts that ties them together.¶
The architecture is guided by several core principles. Ownership and control remain at the domain level. Messages are immutable and exchanged independently between hosts. Message threads are deterministic and verifiable by all participants. Sender verification and message integrity are incorporated into the message exchange protocol. The protocol intentionally defines only the exchange of messages, leaving concerns such as user identity, authentication, message retrieval and client functionality undefined.¶
The following subsections describe these principles and how they relate to one another.¶
Every fmsg address belongs to a domain, and each domain is responsible for operating one or more Hosts authorised to send and receive messages for addresses within that domain. Messages are exchanged directly between Sending Hosts and Receiving Hosts responsible for the sender's and recipients' domains.¶
Hosts are looked up by the fmsg sub-domain name which also serves as a list of authorised hosts. The Receiving Host can challenge the Sending Host during transmission for the digest of the full message being sent supplying the digest of the header received so far. Recipient policy and message size are checked before downloading the message content and any attachments. Messages and their attachments can be compressed with zlib-deflate. Messages can be accepted/rejected for each recipient belonging to a Receiving Host.¶
The core protocol defines only host-to-host message exchange. It does not define how users are authenticated, how addresses are provisioned, how messages are retrieved by clients, or how messages are stored within a domain. This allows domain owners to retain control over their own infrastructure, operational policies and user management while interoperating with other hosts through the fmsg message exchange protocol.¶
The fundamental object in fmsg is the message. Messages are immutable, structured binary objects with a reference to a parent message they are in reply to, if any; otherwise a message without a parent reference starts a thread.¶
Messages are immutable. Once created, the contents of a message never change. Corrections, replies, forwarding a message to additional Recipients and other conversation activity are represented by creating new messages rather than modifying existing ones. This immutability provides a stable foundation for verification, message integrity and conversation history.¶
Each message has exactly one Sender and one or more Recipients. Messages may contain arbitrary content represented by a Media Type and may include zero or more attachments each with their own Media Type. The protocol places no restrictions on the application semantics of the message content, allowing the exchange of plain text, rich text, images, audio, video or application-specific data.¶
Messages are exchanged independently between Sending Hosts and Receiving Hosts. The relationship between messages, including replies and conversation evolution, is described by the thread model rather than by the messages themselves.¶
A Thread is formed by messages explicitly referencing previous messages. The first message in a Thread has no parent, while each subsequent message references the message to which it replies. A Thread is therefore an emergent protocol object; the protocol defines only messages and the relationships between them. As messages receive independent replies, a Thread naturally forms a directed acyclic graph (DAG).¶
By making message relationships explicit, every Participant can deterministically reconstruct the same Thread from the same set of messages. Replies reference an earlier message, allowing only newly created message content to be transmitted while preserving the context and ordering of the conversation.¶
The Thread model also provides a consistent basis for conversation policy. Because the Participants of a message are explicitly defined, a Receiving Host can determine whether a Sender is authorised to reply to a message and how additional Recipients become Participants in the Thread. The protocol therefore defines conversation evolution in terms of new immutable messages rather than modification of existing messages.¶
A Participant is the Sender or a Recipient of a Message.¶
Only a Participant of a Message can reply to that Message. This ensures that conversation participation is explicit and verifiable, and prevents unrelated parties from introducing messages into an existing Thread.¶
A Participant may add additional Recipients to a Thread by creating a copy of the message with additional fields - which original Participant is adding the Recipients and the additional Recipients being added. Existing Messages are never modified. Instead, conversation membership evolves as new Messages are created, preserving the immutability of every Message while allowing conversations to naturally expand over time.¶
Because Participants are determined from the Thread itself, every Host can independently determine the Participants of any Message without requiring additional protocol state. This provides a consistent foundation for participant validation, conversation presentation and implementation-specific policy decisions.¶
Message exchange occurs directly between a Sending Host and one or more Receiving Hosts. A Sending Host is responsible for transmitting a Message to one Receiving Host per domain in the Message's Recipients. Each Receiving Host processes the Message independently and determines whether it will be rejected outright, or rejected/accepted by individual recipients belonging to the Receiving Host's domain.¶
Message acceptance is based on three complementary validation stages: Sender validation, Message validation, and Recipient validation. A Receiving Host completes each validation stage before accepting a Message.¶
Sender validation establishes that the Sending Host is authorised to exchange Messages on behalf of the Sender's domain and, where required, that it possesses the Message being transmitted. This validation provides assurance that the Message originates from an authorised Host.¶
Message validation confirms the integrity and consistency of the Message itself. This includes validating message structure, size constraints, replay status, and the Message's ancestry within the Thread to ensure the Message can be incorporated into a consistent and verifiable conversation history.¶
Recipient validation determines whether each Recipient is willing to accept the Message. This includes validating recipient-specific policy, verifying that the Sender is permitted to communicate within the context of the Thread, and applying any implementation-specific acceptance policies. Because Recipient validation is performed independently by each Receiving Host, acceptance decisions remain under the control of the recipient's domain.¶
A distinguishing feature of fmsg is the automatic challenge. While a Message is being received, and before its content is accepted, a Receiving Host may open a separate connection back to the Sending Host and challenge it for details of the Message currently being transmitted, supplying a digest of the Message header fields received thus far. The Sending Host responds by computing and returning a digest over the pending Message.¶
Because the challenge is directed at the Sending Host using address information independently verified against the Sender's domain beforehand, a successful response demonstrates that the Sending Host is reachable at an authorised address, and once the digest is verified to match that of the message, the Sending Host was genuinely in possession of the Message sent. This strengthens both Sender validation and Message validation, and imposes a small cost on the sender that helps deter unsolicited bulk messaging.¶
The challenge is optional and performed at the discretion of the Receiving Host, allowing protocol assurances to be traded against efficiency. The detailed mechanism is defined by the protocol specification rather than this document.¶
This document deliberately describes only the motivation, design goals and core architecture of fmsg. It does not define message encodings, the on-the-wire protocol procedures, or transport bindings. Those details exist today in an experimental specification [FMSG-SPEC] and reference implementation [FMSGD], and are intended to be specified separately as the work matures.¶
The anticipated document structure separates the work into:¶
this architectural overview;¶
a message format document defining the binary message structure;¶
a host-to-host protocol document defining the exchange procedures, including the challenge-response mechanism and message acceptance; and¶
one or more transport binding documents (for example, a TCP and TLS binding).¶
The author is seeking feedback from the IETF community on the following questions, rather than a detailed review of the underlying specification at this stage:¶
Is the IETF an appropriate venue for this work, and is the Applications and Real-Time (ART) area, by way of the DISPATCH working group, the right place to start?¶
Is there interest in standardising such a domain-level messaging protocol distinct from Internet email?¶
How much do existing or in-progress works affect new protocol work like this, when would the IETF prefer alignment and reconcilement rather than a new protocol?¶
This document covers an application-level protocol; in addition, Media Types and DNS are used. Should each area be engaged separately?¶
The fmsg architecture is designed around validation before acceptance. A Receiving Host validates a Message before accepting it into a Thread. This model ensures that sender verification, message integrity and recipient policy are evaluated before a Message becomes part of the recipient's conversation history.¶
The optional separate connection a Receiving Host can open to the Sending Host, the challenge, poses a threat of a denial-of-service-style attack where many, possibly spoofed, addresses trigger Receiving Hosts to open many connections to an unsuspecting host. The protocol prevents such an attack by requiring Receiving Hosts to verify that the origin IP address of an incoming Message exists among the authorised IP addresses of the purported sender's domain.¶
The protocol standardises the information available to make message acceptance decisions while intentionally leaving operational policy to Receiving Hosts. Implementations may apply additional measures, including spam filtering, rate limiting and abuse detection, when determining whether to accept a Message.¶
Operational security considerations, transport security, denial-of-service mitigations and other implementation guidance are outside the scope of this document and are expected to be defined by the corresponding protocol specifications.¶
This document describes an architecture that has been implemented and evaluated through experimental software.¶
A complete protocol specification, including message definitions and protocol procedures, has been developed [FMSG-SPEC]. A canonical implementation following updates to the specification exists [FMSGD]. This implementation has been used to iterate development hand-in-hand with evolution of the specification.¶
This document has no IANA actions.¶
The author thanks any review, feedback and implementation in advance.¶