[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
Network Working Group                                          C. Newman
Internet Draft: Internet Email Subaddressing                    Innosoft
Document: draft-newman-email-subaddr-00.txt                    July 1997
                                                   Expires in six months


                      Internet Email Subaddressing


Status of this memo

     This document is an Internet-Draft.  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."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
     Coast), or ftp.isi.edu (US West Coast).


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 a primary address and a subaddress.  The primary
     address is used to route the message within the specified domain
     and the subaddress is used to route the message according to a
     particular user's wishes.

     This specification formalizes the de-facto standard for
     subaddressing in use today and includes advice and requirements for
     final delivery agents, MUAs and mail list servers which wish to
     support subaddressing.


1. Conventions Used in this Document

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"



Newman                                                          [Page 1]


Internet Draft        Internet Email Subaddressing         July 22, 1997


     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [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.

     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.

     Subaddress
          A subaddress is information in addition to the address of a
          primary mailbox which may be used for categorization by the
          recipient.

3. Subaddress Syntax

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



Newman                                                          [Page 2]


Internet Draft        Internet Email Subaddressing         July 22, 1997


     For example, an address <delenn+grey-council@babylon5.org> could be
     used to send email to <delenn@babylon5.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" folder.

     When generating a subaddress, 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 primary address
     from the subaddress.  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.

     local-part     = local-quoted / local-unquoted

     local-quoted   = <"> primary-q ["+" subaddress-q] <">

     local-unquoted = [primary-c] ["+" [subaddress-c]]

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

     primary-c      = primc-word *("." primc-word)

     primary-q      = *(SAFEQ-CHAR / quoted)

     primc-word     = 1*SAFE-CHAR

     quoted         = "\" QUOTE-CHAR

     subaddress     = *(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.

     subaddress-c   = subc-word *("." subc-word)

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

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




Newman                                                          [Page 3]


Internet Draft        Internet Email Subaddressing         July 22, 1997


     QUOTE-CHAR     =  <"> / "\"

     SAFE-CHAR      =  %21 / %23..27 / %2A / %2D / %2F..39 / %3D /
                       %3F / %41..5A / %5E..7E
                       ;; All printable US-ASCII characters except
                       ;; space, plus "+" and <specials> as defined
                       ;; in [IMAIL]

     SAFEQ-CHAR     =  %20..21 / %23..2A / %2C..5B / %5D..7E
                       ;; All printable US-ASCII characters except
                       ;; plus "+", quote <"> and backslash "\"


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

     A message with a valid primary address MUST be delivered to that
     primary address by default, regardless of the contents of the
     subaddress.  The subaddress MAY be used to route the message
     according to rules specified by the owner of that primary address.


4.2. Gateway/Firewall Requirements

     A subaddress aware gateway or firewall SHOULD preserve the
     subaddress 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 subaddress
     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 include a subaddress in the envelope
     sender address (as used in the SMTP MAIL FROM command).  A
     subaddress aware MUA which validates local addresses MUST ignore
     subaddresses for the purposes of such validation.







Newman                                                          [Page 4]


Internet Draft        Internet Email Subaddressing         July 22, 1997


4.4. Mail List Server Requirements

     A subaddress aware mail list server MUST allow users to subscribe
     using a subaddress.  If such a server restricts postings by their
     envelope sender, sender or from address, it MUST ignore
     subaddresses for the purposes of such restrictions.


5. Security Considerations

     If a final delivery agent executes a command line containing the
     delivery address and the subaddress contains meta-characters with
     special meaning to the command line interpretor this could result
     in a serious security violation.  In order to avoid this problem,
     the final delivery agent MUST verify the subaddress contains no
     characters with special meaning to the command line interpretor,
     not use a command line interpretor, or strip the subaddress 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 folder
     based on the subaddress, this could result in a denial of service
     problem as well as placing control of a user's folder namespace in
     the hands of outsiders.  In order to avoid this problem, final
     delivery agents MUST NOT automatically create new folders based on
     the subaddress without explicit permission from the owner of the
     primary address.  Final delivery agents SHOULD NOT automatically
     file a message into a folder based on the subaddress without
     explicit permission from the owner of the primary address.


6. References

     [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
     ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt

     [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
      Messages", RFC 822, University of Delaware, August 1982.

          <ftp://ds.internic.net/rfc/rfc822.txt>

     [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
     4rev1", RFC 2060, University of Washington, December 1996.

         <ftp://ds.internic.net/rfc/rfc2060.txt>






Newman                                                          [Page 5]


Internet Draft        Internet Email Subaddressing         July 22, 1997


     [MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles
     and Functions", RFC 2142, Internet Mail Consortium, May 1997.

             <ftp://ds.internic.net/rfc/rfc2142.txt>

     [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821,
     Information Sciences Institute, August 1982.

             <ftp://ds.internic.net/rfc/rfc821.txt>


7. Author's Address

Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA

Email: chris.newman@innosoft.com

Appendix A. Subaddress Scenarios

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


A.1. Subscribe to Mailing List by Subaddress

     Many users (including the author of this specification) subscribe
     to mailing lists using a subaddress and use the final delivery
     agent to file all messages from that mailing list into a different
     incoming folder based on the subaddress.  This sorts mailing list
     traffic into appropriate folders 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 subaddress.  This permits
     users to manage their own distribution lists without administrative
     intervention.


A.3. Mailto URL Indicator

     By including a different subaddress for each mailto URL on a web
     page, a user can determine which mailto URL was selected for a



Newman                                                          [Page 6]


Internet Draft        Internet Email Subaddressing         July 22, 1997


     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 subaddresses to different audiences
     and prioritize reading them appropriately.  For example, one of the
     current esteemed area directors uses an "iesg" subaddress to
     prioritize IESG traffic separately from regular email.


































Newman                                                          [Page 7]