Summary

  • RFC 5233 added :user and :detail address parts to Sieve comparisons, but it did not standardize one separator or a universal plus-address format.
  • The encompassing mail system owns the local encoding; the envelope to can preserve the recipient detail that a visible header does not.

The sign was local; the contract was the boundary

An address with a detail suffix can route a message into a folder, identify a mailing-list subscription or distinguish a voice mailbox. A plus sign is one familiar way to show that detail, but it is only an example. RFC 5233, published in January 2008, gave Sieve two additional address parts: :user and :detail. It described the pieces a filter might compare, not a global addressing grammar.

The distinction matters because an email local part is interpreted in a local mail system. RFC 5233 shows detail after the user with +, and also detail before the user with . When the chosen separator appears more than once, the split is implementation-defined and usually follows the encompassing system's format. The implementation must match the encoding that the system uses or allows; how that format is defined or queried is outside the RFC. A filter cannot safely infer that + means “detail” merely because another provider uses it that way.

For an address without an encoded detail, :user means the entire local part, equivalent to Sieve's :localpart. :detail does not match a requested value. An encoded empty detail is different: it resolves to the empty string. Those rules let a script distinguish “no detail component” from a component that exists but contains no text.

RFC 5233 also separates where an address came from. The address test examines structured message headers; the optional envelope test examines transport envelope data. If a filter is sorting mail by the address that caused delivery to this recipient, the RFC says the envelope to is preferred in most cases. Mailing lists, aliases and virtual domains can make that envelope the only place where the recipient-specific detail survives. Applying the local encoding to a foreign address—such as an originator or envelope from—can yield inconsistent or wrong results.

The extension replaced RFC 3598's earlier subaddress text. Its change notes made the encoding language generic and added the envelope and foreign-address cautions. IANA records the capability as subaddress; that registry entry advertises an extension name, not a promise that every mail system accepts any particular tagged address. The protocol history is therefore a boundary story: Sieve can compare local parts once the host's own interpretation is supplied, but it cannot create that interpretation or prove how a mailbox was provisioned.

Sources