[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                        D. Cridland
Internet-Draft                                             Isode Limited
Intended status: Informational                         November 16, 2007
Expires: May 19, 2008


                      Internet Email Subaddressing
                     draft-newman-email-subaddr-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   It is often useful for a single user to have multiple email addresses
   which can be used to assist categorizing incoming email.  One way of
   doing this is to divide the local-part of an email address into user
   and detail parts.  The user part is used to route the message within
   the specified domain and the detail part is used to route the message
   according to a particular user's wishes.

   This specification formalizes the de-facto standard for subaddressing



Cridland                  Expires May 19, 2008                  [Page 1]


Internet-Draft        Internet Email Subaddressing         November 2007


   in use today and includes advice and requirements for final delivery
   agents, MUAs and mail list servers which wish to support
   subaddressing.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Subaddressing Syntax . . . . . . . . . . . . . . . . . . . . .  4
   4.  Subaddress Support Requirements  . . . . . . . . . . . . . . .  7
     4.1.  Final Delivery Agent Requirements  . . . . . . . . . . . .  7
     4.2.  Gateway/Firewall Requirements  . . . . . . . . . . . . . .  7
     4.3.  MUA Requirements . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Mailing List Server Requirements . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Subaddressing Scenarios . . . . . . . . . . . . . . .  9
     A.1.  Subscribe to Mailing List by Detailed Address  . . . . . .  9
     A.2.  User Controlled Distribution Lists . . . . . . . . . . . .  9
     A.3.  Mailto URL Indicator . . . . . . . . . . . . . . . . . . . 10
     A.4.  Support for Special Addresses  . . . . . . . . . . . . . . 10
     A.5.  Priority Categorization  . . . . . . . . . . . . . . . . . 10
     A.6.  Anti-Phishing  . . . . . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Open Issues and Discussion  . . . . . . . . . . . . . 10
     B.1.  To-do  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12



















Cridland                  Expires May 19, 2008                  [Page 2]


Internet-Draft        Internet Email Subaddressing         November 2007


1.  Introduction

   Subaddressing is a common technique for providing users with multiple
   addresses which can be used for filtering incoming email.  A key
   feature is that no administrative action is required to provision or
   enable a particular detail part; instead, as long as the domain's
   mail system is subaddress-aware, the user may use arbitrary detail
   parts.

   Although commonly deployed, subaddressing has had minimal formal
   documentation; this document attempts to define subaddressing, and
   also define what it means to be subaddress-aware.

   In general, deployed forms of subaddressing divide the local-part of
   an email address into two strings, seperated by a delimiter
   character.  This is most commonly a plus sign, "+".

   This document does not document all forms of subaddressing, merely
   the most common form, also known as "plus-addressing".  Other forms
   are also deployed, sometimes using a minus sign, and in some rare
   cases using encoding rules rather than simple catenation.

1.1.  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 [KEYWORDS].

   The formal grammar in this document uses Augmented BNF [ABNF].


2.  Definitions

   Final Delivery Agent
      The final delivery agent is the agent started by the Final MTA
      which interprets the local-part of the email address.

   Final MTA
      The final MTA is the MTA designated by the domain to the left of
      the "@" in an email address.

   Local-Part
      The local-part of an email address is everything to the left of
      the "@" in the address used for delivery and is formally defined
      in [IMAIL].  It is also know as the "left hand side" of an
      address.





Cridland                  Expires May 19, 2008                  [Page 3]


Internet-Draft        Internet Email Subaddressing         November 2007


   Mail List Server
      A Mail List Server takes messages directed to it, rewrites the
      envelope addresses and redistributes the message to one or more
      subscribers.

   MTA
      A Mail Transport Agent (MTA) receives email from other MTAs or
      MUAs and routes it towards the final MTA.

   MUA
      A Mail User Agent (MUA) is used by a user to send and read email.

   Detail Part
      A detail part is information in addition to the address of a
      primary mailbox which may be used for categorization by the
      recipient.  It is also known as a subaddress.

   User Part
      A user part is that portion of the local part which indicates the
      primary mailbox.  In a mail system which is not subaddress-aware,
      the user part is equal to the local part.

   Detailed Address
      An email address which has a detail part.

   Primary Address
      An email address which has no detail part, or the corresponding
      address to a detailed address with the detail part removed.



3.  Subaddressing Syntax

   A subaddress-aware final delivery agent divides the local-part into
   two pieces separated by a "+".  The user part is to the left of the
   "+" and the detail part is to the right of the "+".  A message with a
   valid user part is delivered to the primary address by default,
   regardless of the contents of the detail part.  The detail part MAY
   be used by final delivery filtering (e.g. to deliver messages with a
   particular detail part into a special mailbox) or by an MUA.

   For example, the detailed address
   <delenn+grey-council@babylon5.example.org> might be used to send
   email to <delenn@babylon5.example.org> relating to grey-council
   business.  Delenn can then direct her final delivery agent to file
   messages with a "grey-council" subaddress into her "grey-council"
   mailbox, perhaps with the [SIEVE-SUBADDRESS] extension.




Cridland                  Expires May 19, 2008                  [Page 4]


Internet-Draft        Internet Email Subaddressing         November 2007


   When generating a detailed address, the local part of the address
   MUST be canonically quoted.  A local part is canonically quoted if it
   is legal according to both the formal grammer in [IMAIL] and the
   formal grammar in [SMTP].  The following formal grammar restricts
   <local-part> in this fashion and distinguishes the user part from the
   detail part.  Subaddress-aware MUAs MUST NOT generate addresses which
   violate this syntax and subaddress-aware final delivery agents MAY
   refuse to apply subaddress interpretation to addresses which violate
   this syntax.










































Cridland                  Expires May 19, 2008                  [Page 5]


Internet-Draft        Internet Email Subaddressing         November 2007


   local-part     = local-quoted / local-unquoted

   local-quoted   = DQUOTE user-part-q ["+" detail-q] DQUOTE

   local-unquoted = [user-part-c] ["+" [detail-c]]

   user-part      = *(SAFEQ-CHAR / QUOTE-CHAR)
                    ;; This is the syntax for an unquoted user-part
                    ;; address. If it fits canonical form (user-part-c)
                    ;; it is used directly in a local-part.  Otherwise
                    ;; QUOTE-CHARs are escaped to fit quoted form.

   user-part-c    = userc-word *("." userc-word)

   user-part-q    = *(SAFEQ-CHAR / quoted)

   userc-word     = 1*SAFE-CHAR

   quoted         = "\" QUOTE-CHAR

   detail-part    = *(SAFEQ-CHAR / QUOTE-CHAR / "+")
                    ;; This is the syntax for an unquoted subaddress.
                    ;; If it fits canonical form (subaddress-c) it is
                    ;; used directly in a local-part.  Otherwise
                    ;; QUOTE-CHARs are escaped to fit quoted form.

   detail-c       = detailc-word *("." detailc-word)

   detail-q       = *(SAFEQ-CHAR / "+" / quoted)

   detailc-word   = 1*(SAFE-CHAR / "+")

   QUOTE-CHAR     = DQUOTE / "\"

   SAFE-CHAR      = %x21 / %x23-27 / %x2A / %x2D / %x2F-39 / %x3D /
                    %x3F / %x41-5A / %x5E-7E
                    ;; All printable US-ASCII characters except
                    ;; space, plus "+" and <specials> as defined
                    ;; in [IMAIL]

   SAFEQ-CHAR     = %x20-21 / %x23-2A / %x2C-5B / %x5D-7E
                    ;; All printable US-ASCII characters except
                    ;; plus, quote and backslash.








Cridland                  Expires May 19, 2008                  [Page 6]


Internet-Draft        Internet Email Subaddressing         November 2007


4.  Subaddress Support Requirements

   This section defines the requirements for subaddress aware final
   delivery agents, gateway/firewalls, MUAs and mail list servers.

4.1.  Final Delivery Agent Requirements

   By default, delivery to a detailed address MUST be identical to
   delivery to the primary address.  Configuration MAY be used to
   override behaviour for specific detailed addresses.

   If [SIEVE] is supported by the delivery agent, then
   [SIEVE-SUBADDRESS] MUST be supported.

4.2.  Gateway/Firewall Requirements

   A subaddress-aware gateway or firewall SHOULD preserve the detail
   part when rewriting an address.  A subaddress aware gateway MAY
   rewrite an address into canonical quoted form.

4.3.  MUA Requirements

   A subaddress-aware MUA MUST allow the user to include a detail part
   in the From header when sending a message.  A subaddress-aware MUA
   MUST generate addresses in canonically quoted form following the
   syntax for local-part in this specification.  A subaddress-aware MUA
   SHOULD allow the user to user a detailed address as the envelope
   sender address (as used in the SMTP MAIL FROM command).  A
   subaddress-aware MUA which validates local addresses MUST ignore
   detail parts for the purposes of such validation.

4.4.  Mailing List Server Requirements

   A subaddress-aware mailing list server MUST allow users to subscribe
   using a detailed address.  If such a server restricts postings by
   their envelope sender, Sender or From address, it MUST be able to be
   configured, by the subscriber, to ignore detail parts for the
   purposes of such restrictions.

   Mailing list servers SHOULD provide a per-user configuration setting
   to allow for alternate delimiters, such as "-".


5.  Security Considerations

   If a final delivery agent executes a command line containing the
   delivery address and the detail part contains meta-characters with
   special meaning to the command line interpretor this could result in



Cridland                  Expires May 19, 2008                  [Page 7]


Internet-Draft        Internet Email Subaddressing         November 2007


   a serious security violation.  In order to avoid this problem, the
   final delivery agent MUST verify the detail part contains no
   characters with special meaning to the command line interpretor, not
   use a command line interpretor, or strip the detail part from the
   address prior to generating the command line when it contains
   characters with special meaning.

   If a final delivery agent were to automatically create a mailbox
   based on the detail part, this could result in a denial of service
   problem as well as placing control of a user's mailbox namespace in
   the hands of outsiders.  In order to avoid this problem, final
   delivery agents MUST NOT automatically create new mailboxes based on
   the detail part without explicit permission from the owner of the
   primary address.  Final delivery agents SHOULD NOT automatically file
   a message into a mailbox based on the subaddress without explicit
   configuration from the owner of the primary address.

   Detailed addresses themselves may be used as a weak form of
   authorization token, for example in the scenario given in
   Appendix A.6.  In such cases, acquisition of the token by a third
   party may aid in fraud.  Therefore such subaddresses MUST be random,
   and MUST NOT be disclosed.


6.  Acknowledgements

   This draft is a direct ancestor of a 1997 draft by Chris Newman.
   Some usages documented herein may reflect this long heritage, however
   it has been updated with current usages, including the use of
   subaddressing as an anti-phishing technique described by John Klensin
   on the IETF mailing list.  No existing usages had fallen out of
   fashion in the intervening decade.

   Discussions within the SIEVE working group also influenced the
   changes to the draft - in particular, the terminology has been
   changed to match that of [SIEVE-SUBADDRESS].


7.  References

7.1.  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

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




Cridland                  Expires May 19, 2008                  [Page 8]


Internet-Draft        Internet Email Subaddressing         November 2007


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

   [SIEVE]    Showalter, T. and P. Guenther, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-13 (work in progress),
              October 2007.

   [SIEVE-SUBADDRESS]
              Murchison, K., "Sieve Email Filtering -- Subaddress
              Extension", draft-ietf-sieve-rfc3598bis-05 (work in
              progress), June 2006.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

7.2.  Informative References

   [MAIL-ARCH]
              Crocker, D., "Internet Mail Architecture",
              draft-crocker-email-arch-09 (work in progress), May 2007.

   [MBOX-NAMES]
              Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.

   [MIXER]    Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
              Mapping between X.400 and RFC 822/MIME", RFC 2156,
              January 1998.


Appendix A.  Subaddressing Scenarios

   This appendix includes examples of how subaddressing used on the
   Internet today.

A.1.  Subscribe to Mailing List by Detailed Address

   Many users subscribe to mailing lists using a detailed address and
   use the final delivery agent to file all messages from that mailing
   list into a different incoming mailbox based on the detail part.
   This sorts mailing list traffic into appropriate mailboxes with 100%
   accuracy and without scanning the contents of the message headers.

A.2.  User Controlled Distribution Lists

   Some final delivery agents allow a user to set up a distribution list
   and associate it with a particular detailed address.  This permits



Cridland                  Expires May 19, 2008                  [Page 9]


Internet-Draft        Internet Email Subaddressing         November 2007


   users to manage their own distribution lists without administrative
   intervention.

A.3.  Mailto URL Indicator

   By including a different detail part for each mailto URL on a web
   page, a user can determine which mailto URL was selected for a
   particular message.

A.4.  Support for Special Addresses

   A user may forward mail from special purpose addresses, such as those
   described in [MBOX-NAMES] to a subaddress of their primary account.
   This avoids the need to login as multiple users while still keeping
   the mail separated.

A.5.  Priority Categorization

   A user may advertise different detailed addresses to different
   audiences and prioritize reading them appropriately.  For example,
   one of the current esteemed area directors uses an "ietf" detail part
   to prioritize IETF traffic separately from regular email.

A.6.  Anti-Phishing

   If a user provides their bank with a unique detailed address, then
   any messages arriving either to the primary address or to a different
   detailed address are more easily detirmined to be fraudulent, and can
   be easily filtered out.

   This effectively uses the detailed address as a weak authorization
   token, so it is advisable to choose a random or unusual detail part.


Appendix B.  Open Issues and Discussion

   This section will hopefully be empty prior to publication as an RFC.

   The author is aware of two main areas of contention which stalled the
   original document.  Firstly, the choice of subaddress delimiter
   character is not universal, nor even the choice of having one at all.
   Unfortunately, a choice must be made for interoperability, therefore
   the plus character remains specified by this document, being the most
   common case.

   Secondly, the recommendation in Section 4.4 effectively means that
   mailing list management software is encouraged into interpreting the
   local-part of addresses in foreign domains.  This recommendation has



Cridland                  Expires May 19, 2008                 [Page 10]


Internet-Draft        Internet Email Subaddressing         November 2007


   been reduced in this version - to requiring that the ability be
   present, and possible to configure by the subscriber.  It is the
   author's assertion that modern mailing list management software is
   typically able to be configured by the subscriber in many ways
   already, so this ought to settle contention.

B.1.  To-do

   This is likely to break [MIXER] - either a solution or advice will be
   needed here.

   Need to switch to and use terminology within [MAIL-ARCH], rather than
   defining potentially clashing terminology.


Author's Address

   Dave Cridland
   Isode Limited
   5 Castle Business Village
   36, Station Road
   Hampton, Middlesex  TW12 2BX
   GB

   Email: dave.cridland@isode.com


























Cridland                  Expires May 19, 2008                 [Page 11]


Internet-Draft        Internet Email Subaddressing         November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made 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 the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Cridland                  Expires May 19, 2008                 [Page 12]