Individual Submission S. Moonesamy, Ed.
Internet-Draft December 11, 2011
Obsoletes: 2919 (if approved)
Intended status: Standards Track
Expires: June 13, 2012
List-Id: A Structured Field and Namespace for the Identification of
Mailing Lists
draft-moonesamy-rfc2919bis-00
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 header fields, it
has become even more important to provide a unique identifier for a
mailing list regardless of the particular host that runs the mailing
list manager at any given time.
The List-Id header field provides a standard location for such an
identifier. In addition, a namespace for mailing 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, mailing list managers can make it
easier for mail user agents to provide automated tools for users to
perform mailing list functions. The mailing list identifier can
serve as a key for automated processing tasks.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 13, 2012.
Moonesamy Expires June 13, 2012 [Page 1]
Internet-Draft List-Id December 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Moonesamy Expires June 13, 2012 [Page 2]
Internet-Draft List-Id December 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. List Identifier Syntax . . . . . . . . . . . . . . . . . . . . 4
3. List-Id Header Field . . . . . . . . . . . . . . . . . . . . . 5
4. Persistence of List Identifiers . . . . . . . . . . . . . . . 7
5. Uniqueness of List Identifiers . . . . . . . . . . . . . . . . 7
6. Operations on List Identifier . . . . . . . . . . . . . . . . 8
7. Supporting Nested Lists . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Subject Tags . . . . . . . . . . . . . . . . . . . . . . . 10
A.2. Changes from RFC 2919 . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Moonesamy Expires June 13, 2012 [Page 3]
Internet-Draft List-Id December 2011
1. Introduction
Internet mailing lists have evolved into fairly sophisticated forums
for group communication and collaboration. RFC 2369 [RFC2369]
expanded the functionality that the Mail User Agent (MUA) can provide
by providing more information in each message sent by the mailing
list manager (MLM).
Implementing such functionality in the MUA depends on the ability to
accurately identify messages as belonging to a particular mailing
list. The problem then becomes what attribute or property to use to
identify a mailing list. The most likely candidate is the submission
address of the mailing list itself. Unfortunately, when the server
where the mailing list manager is hosted or the submission policy of
the list changes the submission address itself can change. This
affects automated processing and filtering of messages from mailing
lists.
In order to further automate (and make more accurate) the processing
a software agent can do, RFC 2919 [RFC2919] specified how to generate
a unique identifier for a mailing list. This identifier can be
simply used for string matching in a filter, 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.
This document obsoletes RFC 2919 [RFC2919].
1.1. Terminology
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 [RFC2119].
1.2. Note
This Internet-Draft can be discussed on the apps-discuss@ietf.org
mailing list. [RFC-Editor: please remove this paragraph]
2. List Identifier Syntax
The List Identifier will, in most cases, appear like a host name in a
domain of the list owner. Using the domain name space as a basis for
the List Identifier namespace, it is intended to leverage an existing
name space structure to generate a unique identifier. It also allows
for the List Identifier to be kept separate from any particular
Moonesamy Expires June 13, 2012 [Page 4]
Internet-Draft List-Id December 2011
delivery host or mechanism.
While it is perfectly acceptable for a List Identifier to be
completely independent of the domain name of the host machine
servicing the mailing list, it is recommended that the owner of a
mailing list avoids generating List Identifiers in any domain name
space for which they do not have authority. For example, a mailing
list hosting service may choose to assign List Identifiers in their
own domain-based name space, or they may allow their clients (the
list owners) to provide List Identifiers in a namespace for which the
owner has authority.
If the owner of the mailing list does not have the authority to
create a List Identifier in a domain-based name space, they may
create unmanaged List Identifiers in the special unmanaged domain
"invalid".
The syntax for a List Identifier in ABNF [RFC5234] follows:
list-id = list-label "." list-id-namespace
list-label = dot-atom-text
list-id-namespace = domain-name / unmanaged-list-id-namespace
unmanaged-list-id-namespace = "invalid"
domain-name = dot-atom-text
Where:
dot-atom-text is defined in [RFC5322]
"invalid" is a reserved domain name defined in [RFC2606]
In addition, a List Identifier (list-id) MUST NOT be longer than 255
octets in length, for future compatibility. It should be noted that
"invalid" is not valid for the domain-name rule.
3. List-Id Header Field
This document specifies a List-Id header field which will provide an
identifier for a mailing list. This header field should be included
on all messages distributed by the mailing list manager (including
command responses to individual users), and on other messages where
the message clearly applies to this particular distinct mailing list.
There MUST be not be more than one of List-Id header field in any
Moonesamy Expires June 13, 2012 [Page 5]
Internet-Draft List-Id December 2011
given message.
This field MUST only be generated by mailing list managers, not MUAs.
The contents of the List-Id header mostly consist of angle-bracket
('<', '>') enclosed identifier, with internal whitespace being
ignored. Mailing List Managers MUST NOT insert whitespace within the
brackets. Client applications SHOULD treat any such whitespace, that
might be inserted by poorly behaved mailing list managers, as
characters to ignore.
The List-Id header field is subject to the encoding and character
restrictions for mail headers as described in [RFC5322].
The List-Id header MAY optionally include a description by including
it as a "phrase" [RFC5322] before the angle-bracketed List
Identifier. The MUA MAY choose to use this description in its user
interface; however, any MUA that intends to make use of the
description should be prepared to properly parse and decode any
encoded strings or other legal phrase components. For many MUAs the
parsing of the List-Id header field will simply consist of extracting
the List Identifier from between the delimiting angle brackets.
The syntax of the List-Id header field follows: list-id-header =
"List-Id:" [phrase] "<" list-id ">" CRLF
where phrase and CRLF are as defined in [RFC5322]. Unlike most
headers fields in RFC 5322 [RFC5322], the List-Id header field does
not allow free insertion of whitespace and comments around tokens.
Any descriptive text MUST be presented in the optional phrase
component of the header field.
Examples:
List-Id: List Header Mailing List <list-name.example.com>
List-Id: <commonspace-users.list-id.example.com>
List-Id: "Lena's Personal Joke List" <lenas-
jokes.da39efc25c530ad145d41b86f7420c3b.021999.invalid>
Moonesamy Expires June 13, 2012 [Page 6]
Internet-Draft List-Id December 2011
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.invalid>
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 mailing
list changes. On the other hand, transitioning from an informal
unmanaged-list-id-namespace to a domain name space is an acceptable
reason to change the List Identifier. Also if the focus of the
mailing list changes sufficiently the administrator may wish to
retire the previous mailing list and its associated identifier to
start a new mailing list reflecting the new focus.
5. Uniqueness of List Identifiers
This proposal uses a namespace that by definition can be used to
create unique identifiers within the domain.
There is a need 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.
It is suggested, but not required, that List Identifiers be created
under a subdomain of "list-id" within any given domain. This can
help to reduce internal conflicts between the administrators of the
subdomains of large organizations. For example, List Identifiers at
"example.com" are generated in the subdomain of "list-
id.example.com".
A List Identifier not ending with ".invalid" MUST be globally unique
in reference to all other mailing lists. List Identifiers ending
with ".invalid" are not guaranteed to be globally unique.
A List Identifier using the special "invalid" namespace SHOULD
include the month and year (in the form MYYYY), i.e. the List
Identifier is a "subdomain" of the "invalid" namespace. In addition,
Moonesamy Expires June 13, 2012 [Page 7]
Internet-Draft List-Id December 2011
some portion of the List Identifier MUST be a randomly generated
string, e.g. the random [RFC4086] component contains a hex encoding
of 128 bits of randomness (resulting in 32 hex characters) as part of
the List Identifier.
Thus, List Identifiers such as <lenas-
jokes.da39efc25c530ad145d41b86f7420c3b.021999.invalid> and
<da39efc25c530ad145d41b86f7420c3b.051998.invalid> follow these
guidelines, while <lenas-jokes.021999.invalid> and <mylist.invalid>
do not.
6. Operations on List Identifier
There is only one operation defined for List Identifiers, that of
case insensitive equality. A lookup string octet with a value in the
inclusive range from 0x41 to 0x5A, the uppercase ASCII [RFC20]
letters, MUST match the identical value and also match the
corresponding value in the inclusive range from 0x61 to 0x7A, the
lowercase ASCII letters. A lookup string octet with a lowercase
ASCII letter value MUST similarly match the identical value and also
match the corresponding value in the uppercase ASCII letter range.
The sole use of a List Identifier is to identify a mailing list, and
the sole use of the List-Id header field is to mark a particular
message as belonging to that list. The comparison operation MUST
ignore any part of the List-Id header field outside of the angle
brackets, the MUA may 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; however, this
will only be possible when the nested mailing list is aware of the
relationship between it and its "parent" mailing lists. If a mailing
list manager encounters a List-Id header field from any unexpected
source it SHOULD NOT pass it through to the list. This implies that
mailing list managers may have to be updated to properly support
List-Ids for nested lists.
8. Security Considerations
There are very few new security concerns generated with this
proposal. Message headers fields are an existing standard, designed
to easily accommodate new types. There may be concern with multiple
Moonesamy Expires June 13, 2012 [Page 8]
Internet-Draft List-Id December 2011
header fields being inserted or headers fields being forged, but
these are problems inherent in Internet mail, not specific to this
specification. Furthermore, the implications are relatively
harmless.
As mentioned above, mail list managers should not allow any user-
originated List-Id header 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 not be
used as an indication of the authenticity of the message.
9. IANA Considerations
The List-Id reference in the Permanent Message Header Field Names
registry should be updated to point to this document.
10. Acknowledgements
Most of the text in this document was copied from RFC 2919, authored
by Ravinder Chandhok and Geoffrey Wenger.
The numerous participants of the List-Header and ListMom-Talk mailing
lists contributed much to the formation and structure of this
document.
Grant Neufeld focused much of the early discussion, and thus was
essential in the creation of this document.
11. References
11.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
Moonesamy Expires June 13, 2012 [Page 9]
Internet-Draft List-Id December 2011
October 2008.
11.2. Informative References
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, July 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists",
RFC 2919, March 2001.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
Appendix A. Appendix
A.1. Subject Tags
A popular feature of some MLMs is the "tagging" of the Subject header
field by prefixing the header field's contents with the name of the
mailing list, e.g. "[example]" for a list called "example". While a
List Identifier is unique, a subject tag is usually the short form of
a mailing list's name. Such a namespace is inherently flat,
unmanaged and thus non-unique.
A.2. Changes from RFC 2919
This appendix contains a list of changes between this document and
RFC 2919.
o Removed text about the domain name system and domain ownership in
Section 2
o "localhost" replaced with "invalid"
o Replaced MTAs with mailing list managers in the sentence: "MTAs
MUST NOT insert whitespace within the brackets" in Section 3
o Case independence in Section 6 changed to case insensivity for
ASCII
o Added a paragraph in the appendix about subject tags
Moonesamy Expires June 13, 2012 [Page 10]
Internet-Draft List-Id December 2011
o Updated references
o Editorial changes
Author's Address
S. Moonesamy (editor)
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
Moonesamy Expires June 13, 2012 [Page 11]
