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.

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

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The formal grammar in this document uses Augmented BNF [ABNF] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).

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.

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] (Murchison, K., “Sieve Email Filtering -- Subaddress Extension,” June 2006.) extension.

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] (Resnick, P., “Internet Message Format,” April 2001.) and the formal grammar in [SMTP] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.). 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.

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.

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] (Showalter, T. and P. Guenther, “Sieve: An Email Filtering Language,” October 2007.) is supported by the delivery agent, then [SIEVE‑SUBADDRESS] (Murchison, K., “Sieve Email Filtering -- Subaddress Extension,” June 2006.) 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 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 (Anti-Phishing). 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] (Murchison, K., “Sieve Email Filtering -- Subaddress Extension,” June 2006.).

7.  References

7.1. Normative References

7.2. Informative References

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 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] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.) 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 (Mailing List Server Requirements) effectively means that mailing list management software is encouraged into interpreting the local-part of addresses in foreign domains. This recommendation has 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] (Kille, S., “MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME,” January 1998.) - either a solution or advice will be needed here.

Need to switch to and use terminology within [MAIL‑ARCH] (Crocker, D., “Internet Mail Architecture,” May 2007.), rather than defining potentially clashing terminology.

Author's Address

Full Copyright Statement

Copyright © 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.