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]