Every time you hand out [email protected] to a website so you can filter (or later identify) who sold your address, you are using a convention that RFC 5233 formalized. It is a small, three-page standards-track document that quietly shaped how millions of people manage their inboxes.

The problem. An email address is traditionally a single opaque token: local@domain. If you wanted per-purpose addresses, you either registered dozens of aliases with your mail provider or ran your own server with wildcard rules. There was no interoperable way to say "the part after the + is a user-controlled tag, and my Sieve filter should be able to match on it."

What Sieve is. Sieve (RFC 5228) is a domain-specific language for server-side mail filtering. Unlike procmail, it is deliberately not Turing complete — no loops, no shell execution — so untrusted users can safely upload filter scripts to a shared IMAP server. Sieve is extended through named capabilities, and RFC 5233 registers one called subaddress.

What the extension actually does. It adds two match-part qualifiers, :user and :detail, that any address test can apply. Given a header like To: [email protected]:

• :user matches just ken
• :detail matches just sieve-users
• :localpart (from base Sieve) still matches the whole ken+sieve-users
• :domain matches example.org

So a filter can now say "if the detail portion is netflix, file into the Streaming folder" without hand-parsing the local-part.

Key design decisions. The RFC is careful about several things that seem obvious in retrospect:

• The delimiter is site-local, not standardized. The document acknowledges + is common but explicitly refuses to mandate it. Some sites use -, some use =. This matters because RFC 5321 already reserves + as a valid local-part character with no defined semantics — Sieve just gives it optional semantics.
• An empty detail is not the same as no detail. [email protected] has a zero-length detail; [email protected] has no detail at all. The :detail test distinguishes them, which turns out to matter for security rules ("reject if detail is present but empty").
• It composes with existing match types. You can combine :detail with :matches, :contains, and comparators, so you get glob matching on tags for free.
• It respects RFC 5228's error model. If an address lacks a detail portion, :detail tests behave as if the header value is absent — not as an error — so scripts stay robust.

Why it matters today. Gmail popularized +-addressing for consumers, but the server-side story is Sieve. Fastmail, Cyrus, Dovecot's Pigeonhole, and most modern IMAP stacks implement RFC 5233 verbatim. If you have ever written a filter rule that keys off the tag portion of an address, or built a signup tracker that gives every service a unique subaddress, this three-page RFC is why the plumbing exists. It is also a nice case study in minimum viable standardization: it does not invent the convention, it does not force a delimiter, it just gives filter authors two extra verbs and gets out of the way.

Historical note. Murchison was deep in the Cyrus IMAP world at CMU, and the extension formalizes what Cyrus already did in the wild for years. Much of Sieve's ecosystem — Sieve itself (RFC 3028, then 5228), ManageSieve (RFC 5804), and this extension — traces back to that Cyrus lineage, which is why so many mail servers speak it identically.