RFC 2369《邮件列表命令信头（List-* 系列）》中文译本

IETF · RFC 2369 · 标准跟踪（Standards Track）· 1998 年 7 月

本备忘录状态（Status of this Memo）

本文档为互联网团体规定了一种互联网标准跟踪（Standards Track）协议，并征求讨论与改进建议。有关该协议的标准化状态与状况，请参阅现行版《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。

版权声明（Copyright Notice）

版权所有 (C) 互联网协会（1998）。保留所有权利。

摘要（Abstract）

邮件列表命令规范信头字段是一组结构化字段，用于添加到由电子邮件分发列表发出的邮件中。每个字段通常包含一个 URL（通常为 mailto [RFC2368]），用于定位相关信息或直接执行命令。本文档描述的三个核心信头字段为 List-Help、List-Subscribe 与 List-Unsubscribe。

此外还有三个在此描述的信头字段，虽然适用范围不及前者广泛，但对于足够数量的邮件列表而言仍具实用价值，因而在此形式化。它们是 List-Post、List-Owner 与 List-Archive。

通过包含这些信头字段，列表服务器可使邮件客户端为用户提供自动化工具有以执行列表功能。其形式可以是菜单项、按钮或其他用户界面元素。其意图在于简化用户体验，为那些往往晦涩且各异的邮件列表管理器命令提供一个通用接口。

本文档中的关键词 “MUST（必须）”、“MUST NOT（必须不）”、“REQUIRED（要求）”、“SHALL（应）”、“SHALL NOT（不应）”、“SHOULD（应该）”、“SHOULD NOT（不应该）”、“RECOMMENDED（推荐）”、“MAY（可以）” 与 “OPTIONAL（可选）” 应按 RFC 2119 中的描述解释。

1. 引言（Introduction）

这是一项关于向电子邮件分发列表发出的邮件中添加额外信头字段的提案。每个新字段的内容通常是一个 URL——通常为 mailto [RFC2368]——用于定位相关信息或直接执行命令。生成这些信头字段的 MTA 通常应该（SHOULD）在所使用的其他协议之外，包含一个基于 mailto 的命令，以支持那些无法使用非邮件协议的用户。

对这些字段的实现将是可选的。然而，包含它们可以获得显著的功能与便利。许多列表管理器——特别是在本提案最初被接受时——可以（MAY）选择仅实现其中一两个字段。List-Help 字段是最有用的单个字段，因为它提供了通向详细用户支持信息的访问入口，并能容纳几乎所有现有列表管理器的命令集。List-Subscribe 与 List-Unsubscribe 字段也非常有用，但目前尚无法描述某些列表管理器的语法（那些需要变量替换的语法）。相关解释见附录 A.5。

这些字段所提供的命令语法描述，可被邮件客户端应用程序用来为用户提供简化且一致的电子邮件分发列表功能访问。其形式可以是菜单项、按钮或其他用户界面元素。其意图在于简化用户体验，为那些往往晦涩且各异的邮件列表管理器命令提供一个通用接口。

已考虑避免创建过多字段，同时避免单个字段被过度重载，并保持语法清晰简洁。

使用这些字段并不免除对邮件列表 -Request 命令地址 [RFC2142] 的支持要求。

2. 命令语法（The Command Syntax）

列表信头字段须遵守 [RFC822] 中所述的邮件信头编码与字符限制。此外，URL 内容进一步被限制在 URL 安全字符集 [RFC1738] 之内。

列表信头字段的内容主要由尖括号（‘<’、‘>’）括起的 URL 构成，内部空白被忽略。MTA 不得（MUST NOT）在括号内插入空白，但客户端应用程序应将行为不端的 MTA 可能插入的任何空白视为应忽略的字符。

可以通过逗号分隔的尖括号括起 URL 列表来指定多个备选 URL。URL 按从左到右的顺序表示偏好。客户端应用程序应使用其支持的、或知道如何通过独立应用程序访问的最左侧协议。通过此机制，可以指定 http 等协议，同时为那些无法访问非邮件协议的客户端提供基本的 mailto 支持。客户端只应使用其中一个可用 URL 执行命令，仅当首次使用的 URL 失败时再使用另一个。

URL 的使用使得该语法可以配合支持现有 URL 的应用程序。随着 URL 标准的扩展，列表信头字段将从中受益。此外，URL 的使用提供了对多种传输协议（如 ftp 与 http）的访问，尽管预期 “mailto” 协议 [RFC2368] 将是列表信头字段的主要使用对象。对非 mailto 协议的使用，应考虑到那些无法访问所指定机制（仅有电子邮件、无 Web 访问）的用户。

需要客户端设置变量字段的命令行语法（例如在命令中包含用户电子邮件地址）未被本实现所支持。然而，使用此类语法的系统仍应该（SHOULD）利用 List-Help 字段，按需为用户提供详细说明，或者——也许更有用——提供对某些结构化命令接口（如基于 HTML 的表单）的访问。

支持命令行语法中变量字段所带来的额外复杂性，被判定为过于难以由本协议支持，并将损害软件作者实现的可能性。

为允许未来扩展，客户端应用程序必须（MUST）遵守以下处理本文档所描述信头字段内容的准则：

1. 除特定字段另有说明外，如果字段内容（在任意前导空白之后，包括注释）以除左尖括号 ‘<’ 之外的任何字符开头，则该字段应该（SHOULD）被忽略。
2. 尖括号括起的 URL 之后的任何字符应该（SHOULD）被忽略，除非在右尖括号之后的第一个非空白/注释字符是逗号。
3. 如果字段内的子项（逗号分隔项）不是尖括号括起的 URL，则该字段的剩余部分（当前及所有后续子项）应该（SHOULD）被忽略。

3. 列表信头字段（The List Header Fields）

本文档给出信头字段，为大多数电子邮件分发列表的“核心”及关键辅助功能提供命令语法描述。在给定的列表上实现的字段应该（SHOULD）包含在该列表分发的全部邮件中（包括对单个用户的命令响应），以及明显适用于某一明确列表的其他邮件中。任何给定邮件中不得（MUST NOT）出现同一字段超过一个。

这些字段必须（MUST）仅由邮件列表生成，而非终端用户。

六个 List-* 信头字段的用途对照如下：

信头字段	用途	说明
List-Help	获取帮助信息	最重要，应指向全部命令的详细说明，可容纳几乎所有列表管理器的命令集
List-Unsubscribe	退订	直接移除用户（最好使用邮件）
List-Subscribe	订阅	请求加入列表（最好使用邮件）
List-Post	投稿	向列表发信；不允许投稿时字段值为 NO
List-Owner	联系管理员	联系列表的人工管理员或邮件系统管理员
List-Archive	访问归档	描述如何访问列表的归档

3.1 List-Help

List-Help 字段是本文档所描述信头字段中最重要的一个。列表管理器仅包含此字段是可接受的，因为按照定义，它应该（SHOULD）将用户指引至所有其他命令的完整说明。通常，所指定的 URL 会请求帮助文件（或许内嵌用于列表命令的 HTML 表单），并另提供对指导性网站的访问。

示例：

List-Help: <mailto:list@host.com?subject=help> (List Instructions)
List-Help: <mailto:list-manager@host.com?body=info>
List-Help: <mailto:list-info@host.com> (Info about the list)
List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
List-Help: <ftp://ftp.host.com/list.txt> (FTP),
    <mailto:list@host.com?subject=help>

3.2 List-Unsubscribe

List-Unsubscribe 字段描述用于直接退订用户（将其从列表中移除）的命令（最好使用邮件）。

示例：

List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
List-Unsubscribe: (Use this command to get off the list)
    <mailto:list-manager@host.com?body=unsubscribe%20list>
List-Unsubscribe: <mailto:list-off@host.com>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
    <mailto:list-request@host.com?subject=unsubscribe>

3.3 List-Subscribe

List-Subscribe 字段描述用于直接订阅用户（请求加入列表）的命令（最好使用邮件）。

示例：

List-Subscribe: <mailto:list@host.com?subject=subscribe>
List-Subscribe: <mailto:list-request@host.com?subject=subscribe>
List-Subscribe: (Use this command to join the list)
    <mailto:list-manager@host.com?body=subscribe%20list>
List-Subscribe: <mailto:list-on@host.com>
List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
    <mailto:list-manager@host.com?body=subscribe%20list>

3.4 List-Post

List-Post 字段描述向列表投稿的方法。这通常是列表的地址，但可能（MAY）是审核者，或某种其他形式的提交。对于不允许投稿的特殊列表（例如公告列表），List-Post 字段可以包含特殊值 “NO”。

示例：

List-Post: <mailto:list@host.com>
List-Post: <mailto:moderator@host.com> (Postings are Moderated)
List-Post: <mailto:moderator@host.com?subject=list%20posting>
List-Post: NO (posting not allowed on this list)

3.5 List-Owner

List-Owner 字段标识联系列表人工管理员的途径。URL 可能（MAY）包含列表管理员、邮件系统管理员或任何其他能处理列表用户联系事宜的人的地址。如果其与邮件系统管理员（postmaster）为同一人，则无需指定 List-Owner。

示例：

List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
List-Owner: <mailto:grant@foo.bar> (Grant Neufeld)
List-Owner: <mailto:josh@foo.bar?Subject=list>

3.6 List-Archive

List-Archive 字段描述如何访问列表的归档。

示例：

List-Archive: <mailto:archive@host.com?subject=index%20list>
List-Archive: <ftp://ftp.host.com/pub/list/archive/>
List-Archive: <http://www.host.com/list/archive/> (Web Archive)

4. 支持嵌套列表（Supporting Nested Lists）

在嵌套邮件列表层次中作为另一列表子列表（sublist）的列表，需要修改部分 List- 信头字段，同时保留父列表所设置的其余字段不变。

子列表应该（SHOULD）移除父列表的 List-Help、List-Subscribe、List-Unsubscribe 与 List-Owner 字段，并应该（SHOULD）插入其自身的这些字段版本。

如果子列表提供自己的归档，它应该（SHOULD）用自己的 List-Archive 替换。否则，它必须（MUST）保持 List-Archive 字段不变。

取决于对列表投稿的处理方式，子列表可以（MAY）替换 List-Post 字段。是否替换 List-Post 的适宜性由各个列表管理器自行判定。如果意图是投稿应分发给主列表的所有成员，子列表就不应当以仅将投稿分发给子列表成员的方式修改 List-Post。

5. 安全考虑（Security Considerations）

本提案所带来的新安全问题极少。邮件信头是一个既有的标准，设计上易于容纳新类型。可能存在对插入多个字段或伪造信头的担忧，但这些都是互联网电子邮件固有的问题，并非本文档所描述协议所特有。此外，其影响相对无害。

邮件列表处理程序不应允许任何用户发起的列表信头字段通过并进入其列表，以免混淆用户并可能产生安全问题。

在客户端一侧，可能对误发投稿或命令有所担忧。要求用户在执行任何操作前有机会进行确认。在 mailto 的情况下，可以不发送而创建格式正确的邮件，使用户能够准确看到正在发生的情况，并给予用户在发送前批准或丢弃该邮件的机会。

使用 URL [RFC1738] 的所有安全考虑同样适用于本协议。邮件客户端应用程序不应支持可能危及用户系统安全的列表信头字段 URL。这包括 “file://” URL 类型，在某些用户系统上它可能潜在地用于触发本地应用程序的执行。

6. 致谢（Acknowledgements）

List-Header [5]、ListMom-Talk [6]、List-Managers 与 MIDA-Mail 邮件列表的众多参与者为本文档的形成与结构作出了很大贡献。

Keith Moore <moore@cs.utk.edu> 与 Christopher Allen <ChristopherA@consensus.com> 就标准流程提供了指导。

附录 A. 背景讨论（Background Discussion）

本提案起源于在 ListMom-Talk 讨论列表 [6] 上发起的讨论。当讨论达到一定深度后，为深入讨论本提案而成立了单独的列表——List Headers 邮件列表 [5]。我们收录了所提出关键问题的摘要，以展示所考察的部分备选方案及我们作出决定的理由。

附录 A.1 多个信头字段与单个信头字段（Multiple header fields vs. a single header field）

出于若干原因，拒绝了使用单个信头字段来承载命令元语法。

这样的字段需要创建新的元语法来描述列表命令（而非本实现所选用的、已广泛部署的 URL 语法）。每一层额外的复杂性与新异性都会降低实际实现的可能性，因为这需要额外的工作来支持。此外，通过使用既有的 URL 语法，我们还能受益于终端用户对那种语法的了解与使用能力，即使其客户端应用程序不支持列表信头字段。

将元语法的承载限制于单个信头字段，还会带来信头字段大小限制的复杂性。大多数单个命令都能轻松地在单行中描述，但描述大量命令可能会占用该字段中的多行，并更有可能在传输途中被现有服务器修改。

使用多个字段时，客户端实现也更简单，因为每个命令都可以彼此完全独立地单独支持与实现。因此，某些列表管理器或邮件客户端可以基于其各自列表的具体需求，选择实现字段的子集。

最后，本文档所描述的格式简单且广为人知，这降低了实现与解析出错的可能性。

附录 A.2 URL 与参数列表（URLs vs. parameter lists）

URL 已经是一种既定的语法，灵活、定义良好且被广泛使用。随着其定义的成熟与扩展，列表字段的能力也将随之增长，而无需修改本提案。URL 已为未来的协议与发展做好准备，并能轻松描述 mailto、http 与 ftp 等不同既有访问协议。

许多客户端已经具备识别、解析与求值 URL 的功能，无论内部实现还是通过将请求传递给辅助应用程序。这使得实现更容易、更现实。例如，这种既有的 URL 解析支持使得我们能够在无需修改其源代码的情况下，向现有邮件客户端（Macintosh 上的 Eudora 与 Emailer）添加原型列表信头功能。

附录 A.3 为何不直接创建标准命令语言？（Why not just create a standard command language?）

一种由所有电子邮件列表服务支持的标准命令语言，将极大缓解当前困扰既有服务的列表访问问题。它将减少终端用户所需的学习量，并使得一批通用支持工具的开发成为可能。

然而，这样的标准化确实在多语言支持与各个邮件列表的定制需求方面存在问题。此类标准的制定预计也会遭遇软件开发者和列表服务提供者的缓慢采纳。

这些观点并不排除此类标准的开发（事实上，它们暗示我们应当尽早而非推迟开始），但我们确实需要一种能被当前列表服务广泛支持的解决方案。

无需标准命令语言，我们就能支持大多数既有的列表管理器命令行语法。通过使用 URL，我们允许标准命令语言可能无法实现的备访问方法，例如基于 Web 的控制。

最后，客户端对标准命令语言的支持尚不清晰，或实现未必简单。当今存在的命令种类繁多、数量庞大，需要复杂的用户界面，这可能令人困惑且难以实现。通过将本提案限制于核心功能，客户端实现得以大幅简化，从而显著提高了实现的可能性（已有若干客户端与服务器应用程序作者宣布支持即为佐证）。

附录 A.4 国际化（Internationalization）

多语言支持取决于 URL 标准。如果 URL 支持，那么 List- 信头字段就支持。这是使用 URL 作为列表信头字段构建块的又一优势。

附录 A.5 变量替换（Variable Substitution）

变量将允许 List- 信头字段容纳几乎每一个既有的列表管理器。然而，它将使整个提案的复杂性无限增加，并可能涉及重新定义 URL 标准，或迫使我们使用比 URL 更复杂（因而更难实现）的东西来描述命令语法。

参数要么必须是强制的（即，如果用户代理不知道要替换什么文本，它就不提交邮件），要么你需要一种方式来表示“如果你知道此参数，在此处加入其文本；否则，执行此操作”，其中“此操作”要么是：(a) 替换一个常量字符串，要么是 (b) 失败。

你需要此类设施的原因是，某些列表服务器应用程序坚持要求某些参数（如用户姓名），而用户代理可能知道也可能不知道。例如，listserv 坚持要求如果你提供了姓或名中的任意一个，就必须同时提供名与姓。

这可能导致类似 UNIX shell 语法的情况，其中 ${foo-bar} 表示若 “foo” 已定义则替换参数 “foo” 的值，否则替换字符串 “bar”。或许 $foo 表示“若参数 foo 已定义则替换其值，否则替换空字符串”。

相比于所带来的收益，这一切似乎过于复杂，尤其是因为变量的使用往往可以避免。

列表服务命令语法中变量的使用似乎正在减少，且无论如何并不适用于所有命令。虽然退订与订阅命令信头字段可能无法被那些需要变量使用的系统所使用，但帮助字段仍将向终端用户提供一致的访问入口，通过它他们可以获得关于使用列表的支持。

附录 A.6 为何不使用专门的 MIME 部分而非信头字段？（Why not use a specialized MIME part instead of header fields?）

曾考虑过 MIME 部分，但由于当前大多数邮件客户端要么不支持 MIME，要么不具备处理此类专门部分的能力——这样的实现会给终端用户带来问题。对许多列表服务器而言，实现 MIME 也不如实现新的信头字段容易。

然而，我们正在研究一个 MIME 部分的设计，以更完整地描述列表命令语法，并设法使其获得相关软件的支持。

附录 A.7 为何要包含订阅命令？（Why include a Subscribe command?）

订阅与退订是几乎每个列表都所需的关键命令。其他命令（如摘要模式）则未被广泛支持。

此外，已退订的用户（在度假前，或出于任何其他原因）可能希望重新订阅某个列表。或者，邮件可能从订阅者转发/退信给非订阅者。或者，用户可能更换地址并希望从其新地址订阅。在这些情况下，提供 List-Subscribe 字段无疑会有所帮助。

附录 A.8 信头膨胀的危险（The Dangers of Header Bloat）

在什么情况下信头字段才算过多？这确实因列表而异。在某些列表上，除非客户端软件提供某种替代用户界面（类似于 Reply-To 字段），否则大多数用户永远不会察觉某个字段。在其他列表上，用户会经常看到邮件的信头字段，并能识别其中所含 URL 的功能。

本文档所描述协议所提供的灵活性（信头字段可按需酌情单独实现）为列表管理员提供了足够的“机动空间”以满足其各自需求。

附录 B. 客户端实现（Client Implementation）

附录 B.1 准则（Guidelines）

对于基于 ‘mailto’ URL 的命令，邮件客户端应用程序可以选择提供专门的反馈（如呈现一个对话框或告警），而非实际的命令邮件，以向用户请求命令确认。反馈应在更具描述性的解释中标识邮件目的地与命令。例如：

"Do you want to send the unsubscription command 'unsubscribe
somelist' to 'somelist-request@some.host.com'?  Sending the command
will result in your removal from the associated list."

如果用户拥有邮件客户端所支持的多个电子邮件地址，当订阅或执行其他无法确定具体使用哪个地址的操作时，客户端应用程序应提示用户使用哪个地址。在退订等情况下，应使用已订阅的地址，除非应用程序未知该地址且无法从邮件信头中确定。

附录 B.2 实现选项（Implementation Options）

此处建议以下实现可能性，以使读者对其为何有用以及可以如何被支持有所了解。

在大多数情况下，当命令不适用于当前所选择的邮件时，禁用该命令的界面可能有所帮助。

附录 B.2.1 组合键与命令行（Key combinations and command lines）

在使用命令行或组合键的基于文本的系统上，每个字段可以实现为一个单独的命令。因此一个组合键用于订阅用户，另一个用于退订，第三个用于请求帮助，等等。这些命令仅在包含列表信头字段的邮件上可用。

附录 B.2.2 菜单项（Menu items）

在带有菜单的图形系统上，这些命令可以采取菜单或子菜单项的形式。例如，在查看包含信头字段的邮件时，可能出现一个名为 “Lists” 的菜单，其项名为 “Subscribe”、“Unsubscribe”、“Get Help”、“Post Message to List”、“Contact List Owner” 与 “Access List Archive”。当不适用于当前邮件时，此菜单可被禁用或完全消失。

附录 B.2.3 按钮与调色板（Push Buttons and Pallettes）

在图形窗口系统上，按钮可置于邮件窗口、工具栏或独立的浮动调色板中。每个按钮可对应一个命令，名称为 “Subscribe”、“Unsubscribe”、“Get Help”、“Post to List”、“List Owner” 与 “Archive”。当不适用于当前邮件时，这些按钮或调色板可被禁用或完全消失。

附录 B.2.4 对用户的反馈（Feedback to the User）

如果使用对话框界面（或其他反馈元素），客户端应用程序必须（MUST）包含供用户在发送前审阅（并可能修改）邮件的选项。应用程序还可能会发现，提供指向关于邮件列表访问的更详细上下文相关帮助的链接很有用。

参考文献（References）

• [RFC822] Crocker, D., “Standard for the Format of ARPA Internet Text Messages”, STD 11, RFC 822, 1982 年 8 月。
• [RFC1738] Berners-Lee, T., Masinter, L., 与 M. McCahill, “Uniform Resource Locators (URL)” RFC 1738, 1994 年 12 月。
• [RFC2142] Crocker, D., “Mailbox Names for Common Services, Roles and Functions”, RFC 2142, 1997 年 5 月。
• [RFC2368] Hoffman, P., Masinter, L., 与 J. Zawinski, “The mailto URL scheme”, RFC 2368, 1998 年 7 月。
• [5] “List-Header” 邮件列表。list-header@list.nisto.com <URL:http://www.nisto.com/listspec/mail/> <URL:http://www.nisto.com/listspec/>
• [6] “ListMom-Talk” 邮件列表。listmom-talk@skyweyr.com <URL:http://cgi.skyweyr.com/ListMom.Home>

编者地址（Editors' Addresses）

Joshua D. Baer
Box 273
4902 Forbes Avenue
Pittsburgh, PA 15213-3799
USA
EMail: josh@skyweyr.com

Grant Neufeld
Calgary, Alberta
Canada
EMail: grant@acm.org
Web: http://www.nisto.com/

完整版权声明（Full Copyright Statement）

版权所有 (C) 互联网协会（1998）。保留所有权利。

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

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

本文档及其中包含的信息按“原样（AS IS）”提供，互联网协会与互联网工程任务组否认所有明示或暗示的担保，包括但不限于任何关于使用本文信息不侵犯任何权利的担保，或任何关于适销性或特定用途适用性的暗示担保。