List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
RFC 2919

Document Type RFC - Proposed Standard (March 2001; Errata)
Was draft-chandhok-listid (individual in app area)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
This information refers to IESG processing after the RFC was initially published:
IESG IESG state RFC 2919 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Alexey Melnikov
Send notices to (None)
Network Working Group                                          R. Chandhok
Request for Comments: 2919                                       G. Wenger
Category: Standards Track                                   QUALCOMM, Inc.
                                                                March 2001

                                List-Id:
                A Structured Field and Namespace for the
                    Identification of Mailing Lists

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  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 management
   headers, it has become even more important to provide a unique
   identifier for 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.

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

Chandhok & Wenger           Standards Track                     [Page 1]
RFC 2919                        List-Id                       March 2001

   proposals like [RFC2369] have expanded the functionality that the MUA
   can provide by providing more information in each message sent by the
   mailing list distribution software.

   Actually 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 list server host, the list processing software, or the submission
   policy of the list changes the submission address itself can change.
   This causes great difficulty for automated processing and filtering.

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

   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.

2. The List Identifier Syntax

   The list identifier will, in most cases, appear like a host name in a
   domain of the list owner.  In other words, the domain name system is
   used to delegate namespace authority for list identifiers just as it
   has been used to distribute that authority for other internet
   resources.

   Using the domain name system as a basis for the list identifier
   namespace is intended to leverage an existing authority structure
   into a new area of application.  By using the domain name system to
   delegate list identifier namespace authority, it becomes instantly
   clear who has the right to create a particular list identifier, and
   separates the list identifier from any particular delivery host or
   mechanism.  Only the rights-holder of a domain or subdomain has the
   authority to create list identifiers in the namespace of that domain.
   For example, only the rights-holder to the "acm.org" domain has the
   authority to create list identifiers in "acm.org" domain.

Chandhok & Wenger           Standards Track                     [Page 2]
RFC 2919                        List-Id                       March 2001
Show full document text