Run a declared filter without inventing delivery guarantees
04The subaddress capability enables tests; separate Sieve actions decide what happens after a match.
Two explicit alternative inputs: detail foo follows a permitted redirect plan, an unmatched detail follows implicit keep. No final remote delivery, sender authentication or mandatory redirect-policy bypass is claimed.
Source for this drawing: RFC 5233 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A selected value is input to a policy, not an authorization or forwarding guarantee.
- The capability identifier is "subaddress" (§3). The RFC’s example declares require ["envelope", "subaddress", "fileinto"]; because it uses all three extensions. Base require commands MUST precede other commands, and an unavailable required extension means later tests/commands MUST NOT execute. On a script error, base Sieve requires user notification and implicit keep; an unsupported capability does not mean silently discard the message (RFC5228 §§2.10.5–2.10.6,3.2).
- Under the RFC’s chosen plus scheme, if envelope :user "to" "postmaster" matches, fileinto "inbox.postmaster" stores the message and stop ends processing. The example assumes that user also receives postmaster mail and the folder/action are available. It ignores detail for that test, so postmaster+alerts can follow this branch. stop does not itself discard mail; an uncancelled implicit keep would still be taken (§4 example; RFC5228 §§3.3,4.1).
- For ken+mta-filters@example.com, the selected detail matches "mta-filters", and fileinto "inbox.ietf-mta-filters" is the illustrated disposition. A successful fileinto cancels implicit keep; it is not automatically followed by an extra default-inbox copy. Folder creation/error behavior is implementation-dependent, so the drawing assumes a usable folder (§4 example; RFC5228 §§2.10.2,4.1).
- For the separate ken+foo@example.com input, the example redirects to ken@example.net. Redirect chooses a new envelope recipient, not a new meaning for the original detail or a rewritten visible To header. Base Sieve requires loop control and permits local policy to ignore a redirect; an ignored redirect MUST NOT cancel implicit keep. The chosen successful-arrow example assumes it is permitted, not that remote delivery is guaranteed (§4 example; RFC5228 §4.2).
- If none of these selected tests match and no action cancels it, base implicit keep retains the message. These examples do not cover a full Sieve interpreter, aliases, mailbox provisioning, parser, SMTP delivery or all runtime errors. Subaddress text supplies no authentication or access grant; base Sieve security considerations still apply (§6; RFC5228 §§2.10.2,10). RFC5233 is a January2008 Proposed Standard obsoleting3598; there are no formal Updates, UpdatedBy or ObsoletedBy relationships in the checked metadata.
Fictional offline mail-filter examples. Address components are already parsed; the illustrated encoding is explicitly configured to match the local mail system. This is not a complete Sieve interpreter, address parser, provider setup or actual mail delivery. Example folders exist and illustrated actions succeed unless a failure is named.
Read the RFC section ↗