INTERNET-DRAFT Ravinder Chandhok
draft-chandhok-listid-00.txt Geoffrey Wenger
Expires: November 26, 1998 Within Technology, Inc.
May 26, 1998
List-Id:
A Structured Field and Namespace for the
Identification of Mailing Lists
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
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright Notice
Copyright (C) The Internet Society 1998. All Rights Reserved.
Abstract
Software that handles electronic mailing list messages (servers
and user agents) needs a way to reliably identify messages that
belong to a particular mailing list. With the advent of list
headers [LISTSPEC] it has become even more important to provide
an identifier to use to identify a mailing list regardless of
the particular host that serves as the list processor at any
given time.
The List-Id header provides a standard location for such an
identifier. In addition, a namespace for list identifiers
based on fully qualified domain names is described. This
namespace is intended to guarantee uniqueness for list owners
who require it, while allowing for a less rigorous namespace
for experimental and personal use.
By including the List-Id field, list servers can make it easier
for mail clients to provide automated tools for users to
perform list functions. The list identifier can serve as a key
to make many automated processing tasks easier, and hence more
widely available.
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 RFC 2119.
1. Introduction
Internet mailing lists have evolved into fairly sophisticated
forums for group communication and collaboration; however,
corresponding changes in the underlying infrastructure have
lagged behind. Recent proposals like [LISTSPEC] have expanded
the functionality that the MUA can provide by providing more
information in each message sent by the mailing list
distribution software.
In order to further automate (and make more accurate) the
processing a software agent can do, there needs to be some
unique identifier to use as an identifier for the mailing list.
This identifier can be simply used for filter string matching,
or it can be used in more sophisticated systems to uniquely
identify messages as belonging to a particular mailing list
independent of the particular host delivering the actual
messages. This identifier can also act as a key into a
database of mailing lists.
2. The List Identifier Syntax
The list identifer will, in most cases, appear like a host name
in the domain of the owner's choosing. In other words, the
domain name system is being used to delegate namespace
authority for list identifiers just as it has been used to
distribute that authority for other internet resources. If an
entity is the owner of a domain or subdomain, then it may
create list identifiers in the namespace of that domain. It is
important to note that it is perfectly acceptable for a list
identifier to be completely independent of the domain name of
the host machine servicing the mailing list.
If the owner of the list does not have access and permission to
a domain-based namespace, they MAY create unmanaged list
identifiers in the special unmanaged domain "x". This would
apply to personal user, or users unable to afford domain name
registration fees. The owner of a mailing list MUST NOT
generate list identifiers in any domain namespace for which
they do not have administrative control or have prior approval.
The syntax for a list identifier in ABNF [RFC2234] follows:
list-id = #label "." list-id-namespace
list-id-namespace = #domain-name | unmanaged-list-id-namespace
unmanaged-list-id-namespace = "x"
Where:
#label is a domain name label (limited to 63 characters), see
[RFC2181]
#domain-name is a fully qualified domain name (FQDN) [RFC2181]
In addition, a list identifier MUST NOT be longer than 255
octets in length, for future compatibility.
3. The List-Id Header Field
This document presents a header field which will provide an
identifier for an e-mail distribution list. This header SHOULD
be included on all messages distributed by the list (including
command responses to individual users), and on other messages
where the message clearly applies to this particular distinct
list. There MUST be no more than one of each field present in
any given message.
This field MUST only be generated by mailing list software, not
end users.
The contents of the List-Id header mostly consist of
angle-bracket ('<', '>') enclosed identifier, with internal
whitespace being ignored. MTAs MUST NOT insert whitespace
within the brackets, but client applications should treat any
such whitespace, that might be inserted by poorly behaved MTAs,
as characters to ignore.
The list header fields are subject to the encoding and
character restrictions for mail headers as described in
[RFC822].
The List-Id header may optionally include a description by
including it as a "phrase" [DRUMS], usually before the
angle-bracketed list identifier. The MUA MAY choose to use
this description in its user interface.
The syntax of the List-Id header follows:
list-id-header = "List-ID:" [FWS] [phrase] "<" list-id ">"
[CFWS] CRLF
where phrase, quoted-string, FWS, CFWS and CRLF are as defined
in [DRUMS].
Examples:
List-Id: "List Header Mailing List" <list-header.nisto.com>
List-Id: <commonspace-users.within.com>
List-Id: "Lena's Personal Joke List" <lenas-jokes.0299.x>
List-Id: "An internal CMU List" <0Jks9449.cmu.edu>
List-Id: <0Jks9449384848xyzzy.0598.x>
4. Persistence of List Identifiers
Although the list identifier MAY be changed by the mailing list
administrator this is not desirable. (Note that there is no
disadvantage to changing the description portion of the List-Id
header.) A MUA MAY not recognize the change to the list
identifier because the MUA SHOULD treat a different list
identifier as a different list. As such the mailing list
administrator SHOULD avoid changing the list identifier even
when the host serving the list changes. On the other hand,
transitioning from an informal unmanaged-list-id-namespace to a
domain namespace is an acceptable reason to change the list
identifier. Also if the focus of the list changes sufficiently
the administrator may wish to retire the previous list and it's
associated identifier to start a new list reflecting the new
focus.
5. Uniqueness of List Identifiers
This proposal seeks to leverage the existing administrative
process already in place for domain name allocation. In
particular, we exploit the fact that domain name ownership
creates a namespace that by definition can be used to create
unique identifiers within the domain.
In addition, there must be a mechanism for identification of
mailing lists that are administrated by some entity without
administrative access to a domain. In this case, general
heuristics can be given to reduce the chance of collision, but
it cannot be guaranteed. If a list owner requires a guarantee,
they are free to register a domain name under their control.
List-IDs not ending with ".x" MUST be globally unique in
reference to all other mailing lists.
List owners wishing to use the special "x" namespace for their
list identifier SHOULD use the month and year (in the form
MMYY) that they create the list identifier as a "subdomain" of
the "x" domain. In addition, some portion of the list
identifier should be a randomly generated string.
Thus, list identifiers such as <lenas-jokes.48585903.0299.x>
and <0Jks9449384848xyzzy.0598.x> conform to these guidelines,
while <lenas-jokes.0299.x> and <mylist.x> does not. In fact,
a particular list owner with several lists may choose to use
the same random number subdomain when generating list
identifiers for each of the lists.
List-IDs ending with ".x" are not guaranteed to be globally
unique.
6. Operations on List Identifiers
There is only one operation defined for list identifiers, that
of case insensitive equality (See Section 3.4.7. CASE
INDEPENDENCE [RFC822]). The sole use of a list identifier is
to identify a mailing list, and the sole use of the List-Id
header is to mark a particular message as belonging to that
list. The comparison operation MUST ignore any part of the
List-Id header outside of the angle brackets, the MUA MAY
choose to inform the user if the descriptive name of a mailing
list changes.
7. Supporting Nested Lists
A list that is a sublist for another list in a nested mailing
list hierarchy MUST NOT modify the List-Id header field.
8. Security Considerations
There are very few new security concerns generated with this
proposal. Message headers are an existing standard, designed to
easily accommodate new types. There may be concern with headers
being forged, but this problem is inherent in Internet
e-mail, not specific to the header described in this document.
Further, the implications are relatively harmless.
Mail list processors should not allow any user-originated
List-Id fields to pass through to their lists, lest they
confuse the user and have the potential to create security
problems.
On the client side, a forged list identifier may break
automated processing. The list identifier (in its current
form) should never be used as an indication of the authenticity
of the message.
9. Acknowledgements
The numerous participants of the List-Header [LISTHEADER] and
ListMom-Talk [LISTMOM] mailing lists contributed much to the
formation and structure of this document.
Grant Neufeld <grant@acm.org> focused much of the early
discussion, and thus was essential in the creation of this
document.
References
[RFC822] David H. Crocker, "Standard for the Format of ARPA
Internet Text Messages" RFC 822, August 1982.
[RFC2181] Elze, R., Bush, R. "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2234] D. Crocker, P. Overell. "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[LISTSPEC] Grant Neufeld and Joshua D. Baer, "The Use of URLs as
Meta-Syntax for Core Mail List Commands and their Transport
through Message Header Fields" 'work in progress', February
1998.
<ftp://ietf.org/internet-drafts/draft-baer-listspec-02.txt>
[DRUMS] P. Resnick, Editor, "Internet Message Format Standard",
March 13 1998.
<ftp://ietf.org/internet-drafts/draft-ietf-drums-msg-fmt-04.txt>
[] "List-Header" Mail list. list-header@list.nisto.com
<http://www.nisto.com/listspec/mail/>
<http://www.nisto.com/listspec/>
[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
<http://cgi.skyweyr.com/ListMom.Home>
Editors' addresses
Ravinder Chandhok
Within Technology, Inc.
RD#1 Box 228
Waynesburg PA 15370 USA
Email: chandhok@within.com
Web: http://www.within.com/~chandhok
Geoffrey Wenger
Within Technology, Inc.
RD#1 Box 228 Waynesburg
PA 15370 USA
Email: wenger@within.com
Web: http://www.within.com/~wenger
draft-chandhok-listid-00.txt
Expires: November 26, 1998