RFC 2919《List-Id：邮件列表标识字段与命名空间》中文译本

IETF · RFC 2919 · 标准跟踪（Standards Track）· 2001 年 3 月

备忘录现状（Status of this Memo）

本备忘录为互联网社群规定了互联网标准跟踪（Standards Track）协议，并请求对改进进行讨论与提出建议。请参阅"Internet Official Protocol Standards"（STD 1）的当前版本，以了解本协议的标准化状态与现状。本备忘录的分发不受限制。

版权声明（Copyright Notice）

Copyright (C) The Internet Society (2001). 保留所有权利。

摘要（Abstract）

处理电子邮件列表邮件（服务器与用户代理）的软件，需要一种可靠的方式来识别属于某个特定邮件列表的邮件。随着列表管理信头（list management headers）的出现，为邮件列表提供一个唯一标识符变得更加重要——无论在任何给定时刻作为列表处理器（list processor）的具体主机是哪一台。

List-Id 信头为此类标识符提供了一个标准位置。此外，还描述了一种基于完全限定域名（FQDN）的列表标识符命名空间。该命名空间旨在为需要唯一性的列表所有者提供唯一性保证，同时也允许用于实验性与个人用途的、约束较宽松的命名空间。

通过包含 List-Id 字段，列表服务器可以让邮件客户端更轻松地为用户提供执行列表功能的自动化工具。该列表标识符可作为一把"钥匙"，使许多自动化处理任务变得更简单，因而也更易普及。

1. 引言（Introduction）

互联网邮件列表已发展成为相当成熟的群体交流与协作论坛；然而，底层基础设施的相应变化却滞后了。近期的提案，如 [RFC2369]，通过在每封由邮件列表分发软件发出的邮件中提供更多信息，扩展了 MUA（邮件用户代理，Mail User Agent）所能提供的功能。

要在 MUA 中真正实现此类功能，依赖于能够准确地将邮件识别为归属于某个特定邮件列表。问题随之变为：应当使用何种属性或特征来标识一个邮件列表。最可能的候选者是邮件列表自身的提交地址（submission address）。遗憾的是，当列表服务器主机、列表处理软件或列表的提交策略发生变化时，提交地址本身也可能随之改变。这给自动化处理与过滤带来了极大困难。

为了进一步自动化（并提高准确度）软件代理所能进行的处理，需要某种唯一标识符来作为邮件列表的标识。该标识符可以简单地用于过滤器中的字符串匹配，也可以用于更复杂的系统，以独立于投递实际邮件的具体主机的方式，将邮件唯一地识别为属于某个特定邮件列表。该标识符还可以作为邮件列表数据库的一把钥匙（key）。

本文件中的关键词"MUST（必须）"、"MUST NOT（必须不）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应当）"、"SHOULD NOT（应当不）"、"RECOMMENDED（推荐）"、"MAY（可以）"和"OPTIONAL（可选）"，应按 RFC 2119 中的描述进行解释。

2. 列表标识符语法（The List Identifier Syntax）

在大多数情况下，列表标识符（list identifier）看起来像列表所有者域中的一个主机名。换句话说，域名系统（DNS）被用来委派列表标识符的命名空间权限，正如它已被用于委派其他互联网资源的权限一样。

以域名系统作为列表标识符命名空间的基础，意在将现有的权限结构引入一个新的应用领域。通过使用域名系统来委派列表标识符命名空间权限，究竟谁有权创建某个特定的列表标识符便一目了然，并且将列表标识符与任何特定的投递主机或机制分离开来。只有某个域或子域的权利持有者（rights-holder）才有权在该域的命名空间中创建列表标识符。例如，只有"acm.org"域的权利持有者才有权在"acm.org"域中创建列表标识符。

虽然列表标识符完全可以独立于为邮件列表提供服务的那台主机的域名，但邮件列表的所有者 MUST NOT（必须不）在任意其不具权限的域命名空间中生成列表标识符。例如，一家邮件列表托管服务可以选择在其自身基于域的命名空间中分配列表标识符，也可以允许其客户（即列表所有者）在所有者具有权限的命名空间中提供列表标识符。

如果列表所有者无权在基于域的命名空间中创建列表标识符，他们可以在特殊的非托管域"localhost"中创建非托管的列表标识符。这适用于个人用户，或无力承担域名注册费用的用户。

列表标识符的 ABNF [RFC2234] 语法如下：

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    = "localhost"

domain-name = dot-atom-text

其中：

• dot-atom-text 在 [DRUMS] 中定义。
• "localhost" 为保留域名，在 [RFC2606] 中定义。

此外，出于未来的兼容性考虑，列表标识符（list-id）的长度 MUST NOT（必须不）超过 255 个八位组（octet）。需要注意的是，"localhost" 对 domain-name 规则而言是无效的。

3. List-Id 信头字段（The List-Id Header Field）

本文件提出了一种信头字段，用于为电子邮件分发列表提供标识符。该信头 SHOULD（应当）被包含在该列表分发的每一封邮件中（包括对单个用户的命令响应），以及在其他邮件明确适用于这一特定列表的情形下。在任何给定邮件中，每个字段的出现 MUST NOT（必须不）超过一个。

该字段 MUST（必须）仅由邮件列表软件生成，而非最终用户。

List-Id 信头的内容主要由尖括号（'<'、'>'）括起来的标识符组成，内部空白被忽略。MTA（邮件传输代理，Mail Transfer Agent） MUST NOT（必须不）在括号内插入空白，但客户端应用程序应将任何可能由行为不良的 MTA 插入的此类空白视为可忽略的字符。

列表信头字段须遵守 [RFC822] 中所描述的邮件信头的编码与字符限制。

List-Id 信头 MAY（可以）选择性地包含一个描述，方法是将描述作为"phrase（短语）"[DRUMS] 置于尖括号括起的列表标识符之前。MUA MAY（可以）选择在其用户界面中使用该描述；然而，任何打算利用该描述的 MUA 应当准备好正确地解析与解码任何已编码字符串或其他合法的短语组成部分。对许多 MUA 而言，对 List-Id 信头的解析将仅仅是提取分隔尖括号之间的列表标识符。

List-Id 信头的语法如下：

list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF

其中 phrase 与 CRLF 如 [DRUMS] 中所定义。与 [RFC822] 中的多数信头不同，List-Id 信头不允许在标记（token）周围随意插入空白与注释。任何描述性文本必须置于信头的可选 phrase 组成部分中。

示例：

List-Id: List Header Mailing List <list-header.nisto.com>
List-Id: <commonspace-users.list-id.within.com>
List-Id: "Lena's Personal Joke List"
         <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>
List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu>
List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>

4. 列表标识符的持久性（Persistence of List Identifiers）

尽管列表标识符 MAY（可以）由邮件列表管理员更改，但这并不可取。（注意，更改 List-Id 信头中描述部分并无不利之处。）MUA 可能无法识别列表标识符的更改，因为 MUA SHOULD（应当）将一个不同的列表标识符视为一个不同的列表。因此，即使服务该列表的主机发生变化，邮件列表管理员 SHOULD（应当）避免更改列表标识符。另一方面，从非正式的 unmanaged-list-id-namespace 过渡到域命名空间，是更改列表标识符的一种可接受的理由。此外，如果列表的关注焦点发生了足够大的变化，管理员可能希望停用先前的列表及其关联标识符，以启动一个反映新焦点新列表。

5. 列表标识符的唯一性（Uniqueness of List Identifiers）

本提案试图利用为域名分配而已经建立的现有管理流程。特别地，我们利用了"域名所有权创建了一个定义上可用于在域中创建唯一标识符的命名空间"这一事实。

此外，必须有一种机制，用于标识由某个实体管理、但不具有域的管理访问权限的邮件列表。在这种情况下，可以给出一般性启发式规则以降低冲突的可能性，但无法保证。如果列表所有者需要保证，他们可自由注册一个由其控制的域名。

建议（但非强制）在任何给定域的"list-id"子域下创建列表标识符。这有助于减少大型组织各子域管理员之间的内部冲突。例如，"within.com"上的列表标识符在"list-id.within.com"子域下生成。

不以".localhost"结尾的 List-ID MUST（必须）相对于所有其他邮件列表是全局唯一的。

希望使用特殊"localhost"命名空间作为其列表标识符的列表所有者，SHOULD（应当）使用其创建列表标识符的月份与年份（以 MMYYYY 形式）作为"localhost"命名空间的"子域"。此外，列表标识符的某一部分 MUST（必须）为随机生成的字符串。生成此类标识符的列表所有者应参考 [MSGID] 以获取关于生成唯一标识符的进一步建议，并参考 [RFC1750] 以获取关于生成随机数的建议。特别是，带有随机成分的列表标识符 SHOULD（应当）在列表标识符中包含一个 128 位随机性的十六进制编码（即产生 32 个十六进制字符）。

因此，诸如 <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> 与 <da39efc25c530ad145d41b86f7420c3b.051998.localhost> 这样的列表标识符符合这些准则，而 <lenas-jokes.021999.localhost> 与 <mylist.localhost> 则不符合。拥有多个列表的某个特定列表所有者 MAY（可以）选择在对每个列表生成列表标识符时使用相同的随机数子域。

以".localhost"结尾的 List-ID 不保证全局唯一。

6. 列表标识符上的运算（Operations on List Identifiers）

为列表标识符定义的运算仅有一种，即大小写不敏感的相等性比较（参见 [RFC822] 第 3.4.7 节"CASE INDEPENDENCE"）。列表标识符的唯一用途是标识一个邮件列表，而 List-Id 信头的唯一用途是将某一特定邮件标记为属于该列表。比较运算 MUST（必须）忽略 List-Id 信头中尖括号以外的任何部分；MUA MAY（可以）选择在该邮件列表的描述性名称发生变化时通知用户。

7. 对嵌套列表的支持（Supporting Nested Lists）

在嵌套邮件列表层级中，作为另一列表的子列表（sublist）的列表 MUST（必须）不修改 List-Id 信头字段；然而，这只有在嵌套邮件列表知晓其与"父"邮件列表之间的关系时才可能实现。如果邮件列表处理器遇到来自任何非预期来源的 List-Id 信头字段，它 SHOULD NOT（应当不）将其透传给列表。这意味着邮件列表处理器可能必须更新，以正确支持嵌套列表的 List-Id。

8. 安全考虑（Security Considerations）

本提案带来的全新安全关注极少。邮件信头是一项既有标准，设计上易于容纳新类型。可能存在对信头被伪造的担忧，但此问题内在于互联网电子邮件，而非本文件所描述信头所特有。此外，其影响相对无害。

如上所述，邮件列表处理器 SHOULD NOT（应当不）允许任何源自用户的 List-Id 字段透传至其列表，以免混淆用户并有潜在地制造安全问题。

在客户端一侧，一个被伪造的列表标识符可能会破坏自动化处理。列表标识符（以其当前形式）SHOULD NOT（应当不）被用作对邮件真实性的指示。

9. 致谢（Acknowledgements）

List-Header [LISTHEADER] 与 ListMom-Talk [LISTMOM] 邮件列表的众多参与者为本文件的形成与结构做出了诸多贡献。

Grant Neufeld <grant@acm.org> 聚焦了早期讨论的许多内容，因而对本文件的创建至关重要。

参考文献（References）

[LISTHEADER] "List-Header" 邮件列表。list-header@list.nisto.com
<http://www.nisto.com/listspec/mail/>
<http://www.nisto.com/listspec/>

[LISTMOM] "ListMom-Talk" 邮件列表。listmom-talk@skyweyr.com
<http://cgi.skyweyr.com/ListMom.Home>

[MSGID] J. Zawinski, M. Curtin，"Recommendations for generating Message IDs"，Work in Progress。

[RFC822] Crocker, D.，"Standard for the Format of ARPA Internet Text Messages"，RFC 822，1982 年 8 月。

[RFC1750] Eastlake, D.，Crocker S. and J. Schiller，"Randomness Recommendations for Security"，RFC 1750，1994 年 12 月。

[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF"，RFC 2234，1997 年 11 月。

[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，1998 年 7 月。

[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names"，BCP 32，RFC 2606，1999 年 6 月。

[RFC2822] Resnick, P., Editor，"Internet Message Format Standard"，STD 11，RFC 2822，2001 年 3 月。

作者地址（Authors' Addresses）

Ravinder Chandhok
QUALCOMM, Inc.
5775 Morehouse Drive
San Diego, CA 92121 USA

EMail: chandhok@qualcomm.com

Geoffrey Wenger
QUALCOMM, Inc.
5775 Morehouse Drive
San Diego, CA 92121 USA

EMail: gwenger@qualcomm.com

完整版权声明（Full Copyright Statement）

Copyright (C) The Internet Society (2001). 保留所有权利。

本文件及其译本可被复制并提供给他人，且可不经任何限制地准备、复制、出版与分发对其加以评论或以其他方式加以解释、或有助于其实现的衍生作品，整体或部分均可，前提是上述版权声明与本段须包含在所有此类副本与衍生作品中。然而，本文件本身不得以任何方式修改，例如删除版权声明或对互联网协会或其他互联网组织的引用，除非为制定互联网标准之目的所需（在此情形下必须遵循互联网标准流程中定义的版权程序），或为将其翻译成英语以外的语言所需。

上述授予的有限许可是永久性的，且不会被互联网协会或其继承者或受让人撤销。

本文件及其中包含的信息按"AS IS（原样）"基础提供，互联网协会与互联网工程任务组（IETF）否认所有明示或暗示的担保，包括但不限于任何关于使用此处信息不会侵犯任何权利的担保，或任何关于适销性（MERCHANTABILITY）或特定用途适用性（FITNESS FOR A PARTICULAR PURPOSE）的暗示担保。

致谢（Acknowledgement）

目前，RFC Editor 职能的资金由互联网协会提供。