Sieve Email Filtering -- Subaddress Extension
RFC 3598

 
Document Type RFC - Proposed Standard (September 2003; No errata)
Obsoleted by RFC 5233
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3598 (Proposed Standard)
Telechat date
Responsible AD Ned Freed
IESG note Published as RFC 3598 10-Sep-2003
Send notices to <ken@oceana.com>
Network Working Group                                       K. Murchison
Request for Comments: 3598                            Oceana Matrix Ltd.
Category: Standards Track                                 September 2003

             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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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 mail filtering
   language that allows users to compare against the user and detail
   parts of an address.

Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Capability Identifier . . . . . . . . . . . . . . . . . . . .   2
   3.  Subaddress Comparisons. . . . . . . . . . . . . . . . . . . .   2
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References. . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Intellectual Property Statement . . . . . . . . . . . . . . .   5
   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .   5
   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .   6

Murchison                   Standards Track                     [Page 1]
RFC 3598                 Sieve Email Filtering            September 2003

1.  Introduction

   Subaddressing is the practice of appending some "detail" information
   to the local-part of an [IMAIL] address to indicate that the message
   should be delivered to the mailbox specified by the "detail"
   information.  The "detail" information is prefixed with a special
   "separator character" (typically "+") which forms the boundary
   between the "user" (original local-part) and the "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:

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

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

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

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2.  Capability Identifier

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

3.  Subaddress Comparisons

   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, aliases, and
   "virtual domains" are involved since the envelope may be the only
   source of detail information for the specific recipient.

Murchison                   Standards Track                     [Page 2]
RFC 3598                 Sieve Email Filtering            September 2003

   The ":user" argument specifies that sub-part of the local-part which
   lies to the left of the separator character (e.g., "ken" in
   "ken+sieve@example.org").  If no separator character exists, then
   ":user" specifies the entire left-side of the address (equivalent to
Show full document text