Support explicit RFC address groups when composing and importing email

[bbottema]

What and why

Investigate explicit support for named RFC address groups in message headers, especially when importing, editing and re-exporting email.

A group can describe an audience without replacing every member's personal display name:

To: Approvers: alice@example.org, bob@example.org;,
    Observers: carol@example.org;

An empty group can also label an undisclosed audience:

To: Newsletter subscribers:;

The actual recipients must then be supplied separately through Bcc or the delivery envelope. The group label does not itself provide delivery or privacy.

The strongest potential use case is preserving meaningful group names and membership during a structured read/edit/write cycle. Creating named audiences is a secondary use case whose value depends on how mail clients handle them. Untouched exact-EML forwarding already has a byte-preservation path; this proposal is about structured handling and optional composition, not replacing that path.

Separate from SJM's existing recipient collections

SJM's Recipients / RecipientsBuilder grouping applies defaults or overrides to individual recipients, such as names and S/MIME certificates. It produces a flat recipient collection, not an RFC address group.

A fixed name of "Team" means:

To: Team <alice@example.org>, Team <bob@example.org>

It does not mean:

To: Team: alice@example.org, bob@example.org;

There is no missing automatic conversion here and no confirmed bug in that contract. Any RFC-group capability must be explicit and must leave existing recipient-collection semantics unchanged.

These groups are also different from server-managed mailing lists: they do not provide membership lookup, a group mailbox, or automatic updates to the member list. A populated To/Cc group exposes its member addresses.

Investigation so far

• RFC 5322 section 3.4 defines named groups, including empty groups. This is established message-header syntax, not a new SMTP delivery mechanism.
• Jakarta Mail's InternetAddress API already provides isGroup() and getGroup(true). We should reuse that parser rather than implement address parsing ourselves.
• Angus 2.0.5 SMTPTransport expands groups internally. Its expandGroups() method and expanded address array are private, and its per-send address state is cleared after sending. Expanding recipients for a submission receipt is therefore a separate adapter concern; it does not add first-class RFC-group semantics to SJM's builders.
• The IETF EMAILCORE applicability-statement draft, revision 30, section 3.3 warns that group syntax has seen little use and that a standards-compliant message may still encounter implementations that do not support it. This is draft guidance, not a verified client compatibility matrix.
• Mozilla still tracks generating RFC groups from address-book lists as an open enhancement. It also has an older, still-unconfirmed reply-all report involving empty groups. These records identify areas to investigate; they do not prove the behaviour of current Thunderbird releases.
• Thunderbird's addressing guide documents the ordinary Bcc/undisclosed-recipient use case. Explicit empty-group labels would add presentation control, not a new ability to send privately.

As of 9 September 2026, this investigation has not established a tested compatibility matrix for current Gmail, Outlook, Apple Mail and Thunderbird versions. Accepting a message, displaying named groups, composing groups and preserving them in replies are different capabilities. We should not advertise broad client support without checking them.

Research before choosing an API

• Trace current public import, copy/edit, validation and send paths with real RFC-group input. Determine whether names or membership are preserved, flattened or rejected, and produce focused examples before calling anything a defect.
• Test current Gmail, Outlook (classic/new/web), Apple Mail and Thunderbird. Record versions and distinguish receipt/display, reply-all, composition and round-trip preservation.
• Cover populated groups, empty groups, mixed groups and individual mailboxes, encoded names and duplicate mailbox occurrences. Do not confuse RFC group terminators with non-standard semicolon-separated address lists.
• Decide whether the evidence warrants structured import/preservation only, or an explicit composition API as well. Do not repurpose existing default/override names as RFC group names.
• Keep header structure separate from the actual delivery envelope. Check Bcc and envelope overrides, per-mailbox receipts/retry advice and S/MIME certificate association.
• Document the distinction from SJM recipient collections and server-managed mailing lists, plus any demonstrated client limitations.

This is an enhancement proposal pending research, with no target release or milestone.