home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-newman-email-subaddr-00.txt
< prev
next >
Wrap
Text File
|
1997-07-29
|
13KB
|
397 lines
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]