Split using the mail system’s actual encoding
02The separator, the order of the parts and repeated-separator handling belong to the encompassing mail system.
Compare first and last occurrence as alternative configured rules. Only the rule matching the actual mail system is correct; there is no universal first/last default.
Source for this drawing: RFC 5233 · Read RFC section 4 ↗
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.
The replacement generalizes the encoding description, includes a detail-first example and a foreign-address caution, and uses empty-value wording. It does not mandate plus addressing.
Read the updated RFC section ↗Implementations MUST use an encoding that matches the mail system.
- In the first chosen scheme, user comes before a plus separator and detail after it: ken+sieve@example.org. The local-part is ken+sieve; the domain is example.org. :user selects ken and :detail selects sieve, excluding both the separator and @domain (§4). The spans show characters, not packet bits or a new wire field. Verified editorial erratum3079 corrects the published figure’s :local-part label to the actual selector :localpart; rejected erratum1331 does not change that syntax.
- The RFC also illustrates a scheme in which detail comes before a two-character separator: sieve--ken@example.org. With that configured scheme, :detail is sieve and :user is ken. A plus sign and user-first order are examples, not requirements. The separator can be a character sequence (§§1,4).
- When a separator occurs more than once, splitting logic is implementation-defined and normally follows the mail system. The two expressly alternative interpretations of ken+list+tag are first-separator→user ken/detail list+tag and last-separator→user ken+list/detail tag. The RFC does not choose either universally (§4).
- Implementations MUST ensure that the detail encoding matches what the encompassing mail system uses or allows. This includes the chosen separator, ordering and repeated-occurrence behavior. RFC5233 does not define how to configure, discover or query that method; the helper therefore requires an explicit scheme rather than guessing a provider policy (§4).
- If the site does not encode a detail in an address, the special no-detail rules apply rather than stripping an arbitrary suffix. Address syntax validation and the domain boundary are supplied by the surrounding Sieve/mail implementation; these bounded helpers operate on already parsed components, not full RFC5322 addresses (§4; RFC5228 §2.7.4).
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 ↗