非官方中文译本声明：本页为 IETF RFC 8058《Signaling One-Click Functionality for List Email Headers》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8058。

RFC 8058《邮件列表一键退订（List-Unsubscribe-Post）》中文译本

IETF · RFC 8058 · 标准跟踪（Standards Track）· 2017 年 1 月

文档信息

Internet Engineering Task Force (IETF)                         J. Levine
Request for Comments: 8058                          Taughannock Networks
Category: Standards Track                                     T. Herkula
ISSN: 2070-1721                                              optivo GmbH
                                                            January 2017

        Signaling One-Click Functionality for List Email Headers

摘要（Abstract）

本文档描述了一种为 List-Unsubscribe 邮件信头字段标示"一键（one-click）"功能的方法。之所以需要这种机制，是因为邮件软件有时会自动抓取邮件信头字段中的 URL，从而在 List-Unsubscribe 信头字段的场景下意外触发退订。

备忘录状态（Status of This Memo）

本文档是 Internet 标准跟踪（Internet Standards Track）文档。

本文档是互联网工程任务组（IETF）的产物，代表了 IETF 社区的共识。它已经过公开评议，并获得互联网工程指导组（IESG）批准发布。关于 Internet 标准的更多信息参见 RFC 7841 第 2 节。

关于本文档当前状态、任何勘误以及如何对其提供反馈的信息，可从 http://www.rfc-editor.org/info/rfc8058 获取。

Copyright (c) 2017 IETF Trust 及被认定为文档作者的人员。保留所有权利。

本文档受 BCP 78 以及 IETF Trust 在本文档发布之日生效的《IETF 文档法律条款》（http://trustee.ietf.org/license-info）约束。请仔细阅读这些文档，其中说明了您对本文档所享有的权利与所受的限制。从本文档中提取的代码组件必须包含《IETF Trust 法律条款》第 4.e 节所述的 Simplified BSD License 文本，且这些组件按 Simplified BSD License 的规定不附带任何担保。

1. 引言与动机（Introduction and Motivation）

List-Unsubscribe 邮件信头字段 [RFC2369] 可以包含 HTTPS [RFC7230] URI。在该信头字段中，HTTPS URI 的用途是把消息的收件人从邮件列表中退订。但反垃圾邮件软件常常会自动抓取邮件信头字段中的所有资源，整个过程无需用户执行任何操作；而发送方也没有任何机械化手段可以判断某次请求究竟是反垃圾邮件软件自动发起的，还是用户手动请求的。为防止意外退订，发送方通常会返回一个带确认步骤的落地页，要求完成确认才算完成退订请求。真人用户能够识别并完成这一确认步骤，而自动化系统则不能。这就使退订过程比"单击一次"要复杂得多。

大规模营销列表的运营者往往最关心其邮件的可送达性（deliverability）：邮件是否投递到了收件人，以及消息如何呈现，例如是进入主收件箱还是被放入垃圾邮件文件夹。许多邮件系统允许收件人将邮件举报为垃圾邮件（spam 或 junk），而经常被举报为垃圾邮件的发送方，其邮件流的可送达性往往较差。因此，发送方希望让收件人尽可能容易地完成退订；如果退订过程过于困难，收件人的替代做法就是不断把该发送方的邮件举报为垃圾邮件，直到这些邮件不再出现在自己的收件箱中。

收件方邮件系统的运营者也清楚，他们的用户并不会明确区分"退订"和"垃圾邮件举报"。在某些情况下，他们允许可信的发送方申请在其邮件被举报为垃圾邮件时收到通知，以便其为收件人办理退订；但"识别可信发送方并向其发送通知"这一流程，在面对大量小型发送方时难以规模化。本规范提供了一种方式，使收件方系统仅凭邮件消息内部的信息、无需事先约定，即可自动通知发送方。有些收件方系统可能希望在用户把某条消息举报为垃圾邮件时就向发送方发送退订通知，也可能向用户提供"举报并退订"的选项。

如果邮件收件人是手动退订，并且退订过程需要确认，那么生成的网页会呈现给收件人，收件人随后可以点击相应按钮。但当退订动作与用户的垃圾邮件举报合并在一起时，用户与发送方网站之间并不存在直接交互。类似地，如果某个邮件系统自动为已关闭或已废弃的收件人邮箱办理退订，那么根本不存在可供交互的用户。在这些情形下，退订过程必须在无人工干预的情况下完成，尤其不能要求软件去尝试解读确认页面的内容。

本文档针对该问题的这一部分，为邮件接收方定义了一个 HTTPS POST 动作。邮件发送方能够将该动作与其他退订请求区分开来，并将其作为一次一键退订处理，无需邮件收件人的人工干预。

本文档有两个目标：

2. 术语定义（Definitions）

本文档中的关键词"MUST（必须）"、"MUST NOT（禁止）"、"REQUIRED（必需）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应当）"、"SHOULD NOT（不应当）"、"RECOMMENDED（推荐）"、"MAY（可以）"和"OPTIONAL（可选）"，当以全大写形式书写时，应按 [RFC2119] 中的描述来解释。

3. 实现（Implementation）

3.1. 邮件发送方（Mail Senders）

希望启用一键退订的邮件发送方，应在消息中放置一个 List-Unsubscribe 信头字段和一个 List-Unsubscribe-Post 信头字段。List-Unsubscribe 信头字段必须（MUST）包含一个 HTTPS URI。它可以（MAY）包含其他非 HTTP/S 的 URI，例如 MAILTO:。List-Unsubscribe-Post 信头必须（MUST）包含唯一的键/值对 "List-Unsubscribe=One-Click"。如下文所述，该消息必须（MUST）具备一个有效的 DKIM（DomainKeys Identified Mail）签名，且该签名至少覆盖 List-Unsubscribe 与 List-Unsubscribe-Post 这两个信头。

List-Unsubscribe 信头中的 URI 必须（MUST）包含足够的信息，以标识邮件收件人以及该收件人将被移出的列表，从而使退订过程能够自动完成。由于并未提供额外 POST 参数的机制，任何关于消息或收件人的信息都要编码在 URI 之中。特别地，一键机制无法询问用户希望退订哪个地址、或希望从哪个列表退订。

该 POST 请求禁止（MUST NOT）包含 cookie、HTTP 授权信息或任何其他上下文信息。退订操作在逻辑上与此前的任何 Web 活动无关，而上下文信息可能会不恰当地把此次退订与以往的活动关联起来。

该 URI 应当（SHOULD）在列表名与订阅者名称的明文之外（或取而代之）包含一个不透明标识符（opaque identifier）或其他难以伪造的成分。处理退订的服务器应当（SHOULD）校验该不透明或难以伪造的成分是否有效。这样可以遏制以下攻击：恶意方发送携带某受害列表 List-Unsubscribe 链接的垃圾邮件，意图借用户举报垃圾邮件的副作用造成该受害列表的批量退订；或者攻击者直接向邮件发送方的退订服务器发起 POST。

邮件发送方需要提供相应基础设施，以处理发往 List-Unsubscribe 信头所指定 URI 的 POST 请求，并处理其邮件将引发的退订请求。

邮件发送方禁止（MUST NOT）返回 HTTPS 重定向，因为被重定向的 POST 动作在历史上一直不能可靠工作，而且许多浏览器会把被重定向的 HTTP POST 变成 GET。

本文档不更新 [RFC2369]，因此 List-Unsubscribe URI 在一键场景之外的用法保持不变。

3.2. 邮件接收方（Mail Receivers）

邮件接收方可以通过向 List-Unsubscribe 信头中的 HTTPS URI 执行一次 HTTPS POST 来完成一键退订。它将 List-Unsubscribe-Post 信头中的键/值对作为请求体发送。

POST 内容应当（SHOULD）以 'multipart/form-data' [RFC7578] 发送，也可以（MAY）以 'application/x-www-form-urlencoded' 发送。这两种编码正是 Web 浏览器提交表单时所使用的编码。POST 动作的目标与手动退订时 GET 动作的目标相同，其用意是让同一套服务器端代码能够同时处理两者。

邮件接收方禁止（MUST NOT）在未获得用户同意的情况下对该 HTTPS URI 执行 POST。何时以及如何取得用户同意，不属于本规范的范围。

4. 附加要求（Additional Requirements）

消息至少需要一个有效的认证标识（authentication identifier）。在本版本规范中，唯一受支持的标识类型是 DKIM [RFC6376]。因此，发送方必须（MUST）为消息应用至少一个有效的 DKIM 签名。

List-Unsubscribe 与 List-Unsubscribe-Post 信头必须（MUST）被该签名覆盖，并被包含在有效 DKIM-Signature 信头字段的 "h=" 标签中。

如果消息不具备所要求的 DKIM 签名，邮件接收方不应当（SHOULD NOT）为该消息提供一键退订。

5. 信头语法（Header Syntax）

以下 ABNF 从 [RFC5322] 中导入 fields、WSP 和 CRLF。

fields =/ list-unsubscribe-post

list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF

postarg = "List-Unsubscribe=One-Click"

6. 安全性考虑（Security Considerations）

List-Unsubscribe 信头可能包含收件人地址的明文或编码形式，但该地址通常也出现在 To: 信头中。本规范允许任何能够访问该消息的人为消息收件人办理退订，不过对于既有的 List-Unsubscribe 而言，情况通常也是如此，只是步骤更多一些。

恶意发送方可能发送内容意在诱发大量退订、且信头经过精心构造的垃圾邮件，从而向那些也许并不想接收 POST 请求的服务器发起 POST。但长期以来，以类似方式诱发 GET 请求一直是可能的（而且由于垃圾邮件过滤器的自动抓取，还要容易得多），因此骚扰显著增加的可能性看起来很低。List-Unsubscribe-Post 信头的内容被限制为单一的已知键/值对，以防止攻击者构造恶意消息，使 POST 操作能够模拟用户在受害网站上填写任意表单。

退订操作向发送方提供了一个强烈暗示：该消息所发往的地址是有效的，因此原则上可被用作检测某个电子邮件地址是否有效的手段。不过在实践中，存在更简单的方法，例如在消息的 HTML 中嵌入图片链接，并观察收件人是否抓取这些图片。

由于邮件发送方接收 POST 请求的服务器通常无法判断请求来自何处，该 URI 应当（SHOULD）包含一个不透明标识符或其他难以伪造的成分，用以标识列表和收件人地址。这样可以确保请求确实源自发送方所发消息中的 List-Unsubscribe 与 List-Unsubscribe-Post 信头。此外，请求禁止（MUST NOT）包含 cookie 或其他上下文信息，以防止服务器把该请求与以往的 Web 请求相关联。

7. IANA 考虑（IANA Considerations）

IANA 已在 "Permanent Message Header Field Names"（永久性消息信头字段名）注册表中新增一条条目。

注册项取值
Header field name（信头字段名）List-Unsubscribe-Post
Applicable protocol（适用协议）mail
Status（状态）standard
Author/Change controller（作者／变更控制者）IETF
Specification document（规范文档）RFC 8058

8. 示例（Examples）

8.1. 简单示例（Simple）

邮件中的信头：

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

由此产生的 POST 请求：

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

8.2. 复杂示例（Complex）

邮件中的信头：

List-Unsubscribe:
    <mailto:listrequest@example.com?subject=unsubscribe>,
    <https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

由此产生的 POST 请求：

POST /unsubscribe.html?opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

8.3. 使用 'multipart/form-data' 的复杂示例（Complex with 'multipart/form-data'）

邮件中的信头：

List-Unsubscribe:
    <mailto:listrequest@example.com?subject=unsubscribe>,
    <https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

由此产生的 POST 请求：

POST /unsubscribe.html/opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn
Content-Length: 124

---FormBoundaryjWmhtjORrn
Content-Disposition: form-data; name="List-Unsubscribe"

One-Click
---FormBoundaryjWmhtjORrn--

9. 规范性引用文件（Normative References）

作者地址（Authors' Addresses）

John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY  14886
United States of America

Phone: +1 831 480 2300
Email: standards@taugh.com
URI:   http://jl.ly


Tobias Herkula
optivo GmbH
Wallstrasse 16
Berlin  10179
Germany

Phone: +49 30 768078 129
Email: t.herkula@optivo.com
URI:   https://www.optivo.com