wdiff draft-newman-email-subaddr-00.txt draft-newman-email-subaddr-01.txt

Network Working Group C. Newman
Internet Draft: Internet Email Subaddressing Innosoft
Document: draft-newman-email-subaddr-00.txt July 1997
Expires in six months 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

This document Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is an Internet-Draft. 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.

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

The list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the 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 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). 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 a primary address user
and a subaddress. detail parts. The primary
address user part is used to route the message within
the specified domain and the subaddress 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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

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 used in this Document document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "MAY" "OPTIONAL" in this
document are to be interpreted as defined in "Key words for
use described 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

Detail Part
A subaddress 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. Subaddress Subaddressing Syntax

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

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

When generating a subaddress, 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 primary address user part from the subaddress. Subaddress aware
detail part. Subaddress-aware MUAs MUST NOT generate addresses which
violate this syntax and subaddress aware 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 DQUOTE user-part-q ["+" subaddress-q] <"> detail-q] DQUOTE

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

primary [detail-c]]

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

primary-c

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

primary-q userc-word)

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

primc-word

userc-word = 1*SAFE-CHAR

quoted = "\" QUOTE-CHAR

subaddress

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.

subaddress-c

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

subaddress-q detailc-word)

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

subc-word

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

QUOTE-CHAR = <"> DQUOTE / "\"

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

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

By default, delivery to a valid primary detailed address MUST be delivered identical to
delivery to that
primary address by default, regardless of the contents of the
subaddress. The subaddress primary address. Configuration MAY be used to route the message
according to rules specified
override behaviour for specific detailed addresses.

If [SIEVE] is supported by the owner of that primary address. delivery agent, then
[SIEVE-SUBADDRESS] MUST be supported.

4.2. Gateway/Firewall Requirements

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

4.4. Mail Mailing List Server Requirements

A subaddress aware mail subaddress-aware mailing list server MUST allow users to subscribe
using a subaddress. detailed address. If such a server restricts postings by
their envelope sender, sender Sender or from From address, it MUST be able to be
configured, by the subscriber, to ignore
subaddresses 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 subaddress 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 subaddress detail part contains no
characters with special meaning to the command line interpretor, not
use a command line interpretor, or strip the subaddress 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 folder mailbox
based on the subaddress, detail part, this could result in a denial of service
problem as well as placing control of a user's folder mailbox namespace in
the hands of outsiders. In order to avoid this problem, final
delivery agents MUST NOT automatically create new folders mailboxes based on
the subaddress detail part without explicit permission from the owner of the
primary address. Final delivery agents SHOULD NOT automatically file
a message into a folder mailbox based on the subaddress without explicit permission
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", 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., 4234, October 2005.

[IMAIL] Resnick, P., "Internet Message Access Protocol - Version
4rev1", Format", RFC 2060, University of Washington, December 1996.

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

[MBOX-NAMES] Crocker, D., "Mailbox Names 2822,
April 2001.

[KEYWORDS]
Bradner, S., "Key words for Common Services, Roles
and Functions", use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2142, Internet Mail Consortium, May 2119, March 1997.

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

[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] Postel, Klensin, J., "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 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. Subaddress Subaddressing Scenarios

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

A.1. Subscribe to Mailing List by Subaddress Detailed Address

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

A.3. Mailto URL Indicator

By including a different subaddress 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 subaddresses detailed addresses to different
audiences and prioritize reading them appropriately. For example,
one of the current esteemed area directors uses an "iesg" subaddress "ietf" detail part
to prioritize IESG 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
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

Full Copyright Statement

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).