datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Sieve Email Filtering: Subaddress Extension
RFC 5233

Document type: RFC - Proposed Standard (January 2008; Errata)
Obsoletes RFC 3598
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5233 (Proposed Standard)
Responsible AD: Lisa Dusseault
Send notices to: sieve-chairs@tools.ietf.org

Network Working Group                                       K. Murchison
Request for Comments: 5233                    Carnegie Mellon University
Obsoletes: 3598                                             January 2008
Category: Standards Track

              Sieve Email Filtering: Subaddress Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   On email systems that allow for 'subaddressing' or 'detailed
   addressing' (e.g., "ken+sieve@example.org"), it is sometimes
   desirable to make comparisons against these sub-parts of addresses.
   This document defines an extension to the Sieve Email Filtering
   Language that allows users to compare against the user and detail
   sub-parts of an address.

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

Murchison                   Standards Track                     [Page 1]
RFC 5233              Sieve: Subaddress Extension           January 2008

1.  Introduction

   Subaddressing is the practice of augmenting the local-part of an
   [RFC2822] address with some 'detail' information in order to give
   some extra meaning to that address.  One common way of encoding
   'detail' information into the local-part is to add a 'separator
   character sequence', such as "+", to form a boundary between the
   'user' (original local-part) and 'detail' sub-parts of the address,
   much like the "@" character forms the boundary between the local-part
   and domain.

   Typical uses of subaddressing might be:

   o  A message addressed to "ken+sieve@example.org" is delivered into a
      mailbox called "sieve" belonging to the user "ken".

   o  A message addressed to "5551212#123@example.com" is delivered to
      the voice mailbox number "123" at phone number "5551212".

   This document describes an extension to the Sieve language defined by
   [RFC5228] for comparing against the 'user' and 'detail' sub-parts of
   an address.

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].

3.  Capability Identifier

   The capability string associated with the extension defined in this
   document is "subaddress".

4.  Subaddress Comparisons

   Test commands that act exclusively on addresses may take the optional
   tagged arguments ":user" and ":detail" to specify what sub-part of
   the local-part of the address will be acted upon.

      NOTE: In most cases, the envelope "to" address is the preferred
      address to examine for subaddress information when the desire is
      to sort messages based on how they were addressed so as to get to
      a specific recipient.  The envelope address is, after all, the
      reason a given message is being processed by a given sieve script
      for a given user.  This is particularly true when mailing lists,

Murchison                   Standards Track                     [Page 2]
RFC 5233              Sieve: Subaddress Extension           January 2008

      aliases, and 'virtual domains' are involved since the envelope may
      be the only source of detail information for the specific
      recipient.

      NOTE: Because the encoding of detailed addresses are site and/or
      implementation specific, using the subaddress extension on foreign
      addresses (such as the envelope "from" address or originator

[include full document text]