RFC 5233

Sieve Email Filtering: Subaddress Extension

📅 published January 2008, from ietf

Sieve Email Filtering: Subaddress Extension 💖

Okay bestie, here's the whole vibe at a glance 🎀

  • Series: Network Working Group
  • RFC number: 5233
  • Author: Kenneth Murchison, Carnegie Mellon University
  • Date: January 2008
  • Category: Standards Track
  • Obsoletes: RFC 3598

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🙌 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract 🦋

So, on email systems that allow 'subaddressing' or 'detailed addressing' (think "ken+sieve@example.org"), it's sometimes super useful to compare things against the sub-parts of an address 👀 This document defines an extension to the Sieve Email Filtering Language that lets users compare against the user and detail sub-parts of an address. It's giving filtering superpowers 💅

Table of Contents 📋

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Capability Identifier ...........................................2
4. Subaddress Comparisons ..........................................2
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Normative References ............................................5
Appendix A. Acknowledgments ........................................6
Appendix B. Changes since RFC 3598 .................................6

1. Introduction ✨

Okay so subaddressing is when you add some 'detail' info onto the local-part of an [RFC2822] address to give that address some extra meaning 🧚 A super common way to do this is to slap a 'separator character sequence', like "+", between the 'user' (the original local-part) and the 'detail' sub-parts. It's kind of like how "@" forms the boundary between the local-part and the domain 💜

Here are some typical uses of subaddressing 🍓

  • A message addressed to "ken+sieve@example.org" gets delivered into a mailbox called "sieve" that belongs to the user "ken".
  • A message addressed to "5551212#123@example.com" gets delivered to the voice mailbox number "123" at phone number "5551212". Iconic 📞

This document describes an extension to the Sieve language defined by [RFC5228]. It lets you compare against the 'user' and 'detail' sub-parts of an address, and honestly, it's so useful 🫶

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the rules-of-the-road words, so read them carefully 🙈

3. Capability Identifier 🎀

The capability string for the extension in this document is "subaddress" 🪄

4. Subaddress Comparisons 💅

Test commands that only act on addresses can take the optional tagged arguments ":user" and ":detail". These pick out which sub-part of the address's local-part gets acted upon 👑

NOTE: Most of the time, the envelope "to" address is the best one to check for subaddress info when you want to sort messages by how they were addressed, so you can get to a specific recipient 📬 The envelope address is literally the reason a message is being processed by a given sieve script for a given user. This is especially true with mailing lists, aliases, and 'virtual domains', since the envelope might be the only place the detail info for that specific recipient lives 🥹
NOTE: The encoding of detailed addresses is site and/or implementation specific. So if you use the subaddress extension on foreign addresses (like the envelope "from" address or originator header fields), you might get inconsistent or incorrect results 💀

The ":user" argument picks out the user sub-part of the local-part of an address. If the address isn't encoded with a detail sub-part, then ":user" gives you the entire left side of the address (same as ":localpart") ✨

The ":detail" argument picks out the detail sub-part of the local-part of an address. If the address isn't encoded with a detail sub-part, then the address fails to match any of the specified keys. If a zero-length string is encoded as the detail sub-part, then ":detail" resolves to the empty value ("") 🧚

NOTE: If the encoding method for detailed addresses uses a separator character sequence, and that sequence shows up more than once in the local-part, then how the address gets split is implementation-defined. It usually depends on the format used by the encompassing mail system 🌀

Implementations MUST make sure that the encoding method used for detailed addresses matches the one used and/or allowed by the encompassing mail system. Otherwise, unexpected results might happen 😭 Heads up, the mechanisms used to define and/or query the encoding method used by the mail system are outside the scope of this document.

The ":user" and ":detail" address parts follow the same rules and restrictions as the standard address parts defined in [RFC5228], Section 2.7.4 📏

For convenience, the "ADDRESS-PART" syntax element defined in [RFC5228], Section 2.7.4, gets augmented here like so:

ADDRESS-PART  =/  ":user" / ":detail"

Here's a diagram of the ADDRESS-PARTs of an email address where the detail info follows a separator character sequence of "+" 🖼️

       :user "+" :detail  "@" :domain
      \-----------------/
          :local-part

And here's one where the detail info comes before a separator character sequence of "--" 🖼️

       :detail "--" :user  "@" :domain
      \------------------/
          :local-part

Now for the example, where the detail info follows "+" 🎀

require ["envelope", "subaddress", "fileinto"];

# In this example the same user account receives mail for both
# "ken@example.com" and "postmaster@example.com"

# File all messages to postmaster into a single mailbox,
# ignoring the :detail part.
if envelope :user "to" "postmaster" {
    fileinto "inbox.postmaster";
    stop;
}

# File mailing list messages (subscribed as "ken+mta-filters").
if envelope :detail "to" "mta-filters" {
    fileinto "inbox.ietf-mta-filters";
}

# Redirect all mail sent to "ken+foo".
if envelope :detail "to" "foo" {
    redirect "ken@example.net";
}

5. IANA Considerations 📮

The following template is the IANA registration for the subaddress Sieve extension specified in this document. This registration replaces the one from RFC 3598 🔄

To: iana@iana.org
Subject: Registration of new Sieve extension

Capability name: subaddress
Description:     Adds the ':user' and ':detail' address parts
                 for use with the address and envelope tests
RFC number:      RFC 5233
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>

This info has been added to the list of Sieve extensions given on http://www.iana.org/assignments/sieve-extensions 🌸

6. Security Considerations 🔐

Security considerations are discussed in [RFC5228]. It is believed that this extension does not introduce any additional security concerns. 🛡️

7. Normative References 📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
           2001.

[RFC5228]  Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email
           Filtering Language", RFC 5228, January 2008.

Appendix A. Acknowledgments 🫶

Huge thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed, Mark Mallett, and Barry Leiba for their help with this document 💖

Appendix B. Changes since RFC 3598 🎀

  • The discussion of how the user and detail info is encoded now uses generic language.
  • Added a note that this extension is most useful when used on the envelope "to" address.
  • Added a note that this extension isn't very useful on foreign addresses (envelope "from" or originator header fields).
  • Fixed the envelope test example so it only uses the "to" address.
  • Replaced the ":user" example with one that doesn't produce unexpected behavior.
  • The zero-length string ("") is now called "empty" instead of "null" (per RFC 5228).
  • Only RFC 2606 domains are used in examples.
  • Miscellaneous editorial changes 🧹

Author's Address 📬

Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA

Phone: +1 412 268 2638 EMail: murch@andrew.cmu.edu

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔖

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 ✨

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address that info to the IETF at ietf-ipr@ietf.org 🦋

📦 where this page comes from