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
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
摘要
This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.
本文档描述了一种方法，用于为列表取消订阅电子邮件标题字段发送一次单击功能信号。之所以需要这样做，是因为邮件软件有时会在邮件头字段中获取URL，因此在列表取消订阅头字段的情况下会意外触发取消订阅。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8058.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8058.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Mail Senders . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Mail Receivers . . . . . . . . . . . . . . . . . . . . . 5
4. Additional Requirements . . . . . . . . . . . . . . . . . . . 5
5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Complex . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Complex with 'multipart/form-data' . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Mail Senders . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Mail Receivers . . . . . . . . . . . . . . . . . . . . . 5
4. Additional Requirements . . . . . . . . . . . . . . . . . . . 5
5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Complex . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Complex with 'multipart/form-data' . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
A List-Unsubscribe email header field [RFC2369] can contain HTTPS [RFC7230] URIs. In that header field, the HTTPS URI is intended to unsubscribe the recipient of the message from the list. But anti-spam software often fetches all resources in mail header fields automatically, without any action by the user, and there is no mechanical way for a sender to tell whether a request was made automatically by anti-spam software or manually requested by a user. To prevent accidental unsubscriptions, senders return landing pages with a confirmation step to finish the unsubscribe request. A live user would recognize and act on this confirmation step, but an automated system would not. That makes the unsubscription process more complex than a single click.
列表取消订阅电子邮件标题字段[RFC2369]可以包含HTTPS[RFC7230]URI。在该标头字段中，HTTPS URI用于从列表中取消订阅邮件收件人。但反垃圾邮件软件通常会自动获取邮件标题字段中的所有资源，而用户无需采取任何行动，而且发件人也无法机械地判断请求是由反垃圾邮件软件自动发出的，还是由用户手动发出的。为了防止意外取消订阅，发件人返回带有确认步骤的登录页以完成取消订阅请求。实时用户会识别并执行此确认步骤，但自动化系统不会。这使得退订过程比单击一次更复杂。
Operators of broadcast marketing lists tend to be primarily concerned about deliverability of their mail: whether the mail is delivered to the recipients and how the messages are presented, e.g., whether in the primary inbox or in a junk folder. Many mail systems allow recipients to report mail as spam or junk, and mail streams from senders whose mail is often reported as junk tend to have poor deliverability. Hence, the mailers want to make it as easy as possible for recipients to unsubscribe; if an unsubscription process is too difficult, the recipient's alternative is to report mail from the sender as junk until the mail no longer appears in the recipient's inbox.
广播营销列表的运营商往往主要关注其邮件的可交付性：邮件是否交付给收件人以及邮件的呈现方式，例如，是在主收件箱中还是在垃圾邮件文件夹中。许多邮件系统允许收件人将邮件报告为垃圾邮件或垃圾邮件，而来自其邮件经常报告为垃圾邮件的发件人的邮件流往往具有较差的可交付性。因此，邮递员希望尽可能方便收件人退订；如果取消订阅过程太困难，收件人的替代方法是将发件人的邮件报告为垃圾邮件，直到该邮件不再出现在收件人的收件箱中。
Operators of recipient mail systems are aware that their users do not make a clear distinction between unsubscription and junk. In some cases, they allow trustworthy mailers to request notification when
收件人邮件系统的运营商知道，他们的用户没有明确区分退订和垃圾邮件。在某些情况下，它们允许可靠的邮件发送人在需要时请求通知
their mail is reported as junk so they can unsubscribe the recipient, but the process of identifying trustworthy mailers and notifying them does not scale well to large numbers of small mailers. This specification provides a way for recipient systems to notify the mailer automatically, using only information within the mail message, and without prearrangement. Some recipient systems might wish to send an unsubscription notice to mailers whenever a user reports a message as junk, or they might offer the user the option of reporting and unsubscribing.
他们的邮件被报告为垃圾邮件，因此他们可以取消订阅收件人，但识别值得信任的邮件并通知他们的过程并不能很好地扩展到大量小型邮件。本规范为收件人系统提供了一种自动通知邮件发送人的方法，只使用邮件消息中的信息，无需预先安排。当用户将邮件报告为垃圾邮件时，某些收件人系统可能希望向邮件发送取消订阅通知，或者他们可能会向用户提供报告和取消订阅的选项。
If a mail recipient is unsubscribing manually and the unsubscription process requires confirmation, the resulting web page is presented to the recipient who can then click the appropriate button. But when the unsubscribe action is combined with a user junk report, there is no direct user interaction with the mailer's website. Similarly, if a mail system automatically unsubscribes recipient mailboxes that have been closed or abandoned, there can be no interaction with a user who is not present. In those cases, the unsubscription process has to work without manual intervention, and in particular without requiring that software attempt to interpret the contents of a confirmation page.
如果邮件收件人正在手动取消订阅，并且取消订阅过程需要确认，则生成的网页将显示给收件人，然后收件人可以单击相应的按钮。但是，当取消订阅操作与用户垃圾报告相结合时，用户不会直接与邮件发送者的网站进行交互。类似地，如果邮件系统自动取消订阅已关闭或放弃的收件人邮箱，则无法与不在场的用户进行交互。在这些情况下，取消订阅过程必须在没有人工干预的情况下工作，尤其是在不要求软件尝试解释确认页面内容的情况下。
This document addresses this part of the problem, with an HTTPS POST action for mail receivers. Mail senders can distinguish this action from other unsubscribe requests and handle it as a one-click unsubscription without manual intervention by the mail recipient.
本文档通过邮件接收者的HTTPS POST操作解决了这部分问题。邮件发件人可以将此操作与其他取消订阅请求区分开来，并将其作为一键取消订阅处理，而无需邮件收件人手动干预。
This document has two goals:
本文件有两个目标：
o Allow email senders to signal that a List-Unsubscribe header field [RFC2369] has one-click functionality.
o 允许电子邮件发件人发出信号，表明列表取消订阅标题字段[RFC2369]具有一键式功能。
o Allow MUA (Mail User Agent) users to unsubscribe from mailing lists in a familiar environment and without leaving the MUA context. A receiving system can process an unsubscription request in the background without further interaction and know that it can be fully processed by the mail sender's system.
o 允许MUA（邮件用户代理）用户在熟悉的环境中取消订阅邮件列表，而无需离开MUA上下文。接收系统可以在后台处理取消订阅请求，而无需进一步交互，并且知道邮件发送者的系统可以完全处理该请求。
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] when written in all capital letters.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”在以所有大写字母书写时应按照[RFC2119]中的说明进行解释。
A mail sender that wishes to enable one-click unsubscriptions places one List-Unsubscribe header field and one List-Unsubscribe-Post header field in the message. The List-Unsubscribe header field MUST contain one HTTPS URI. It MAY contain other non-HTTP/S URIs such as MAILTO:. The List-Unsubscribe-Post header MUST contain the single key/value pair "List-Unsubscribe=One-Click". As described below, the message MUST have a valid DomainKeys Identified Mail (DKIM) signature that covers at least the List-Unsubscribe and List-Unsubscribe-Post headers.
希望启用一键取消订阅的邮件发件人在邮件中放置一个列表取消订阅标头字段和一个列表取消订阅邮件标头字段。列表取消订阅标头字段必须包含一个HTTPS URI。它可能包含其他非HTTP/S URI，如MAILTO:。列表取消订阅帖子标题必须包含单个键/值对“列表取消订阅=单击一次”。如下所述，邮件必须具有有效的域密钥标识邮件（DKIM）签名，该签名至少包括列表取消订阅和列表取消订阅邮件标题。
The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically. Since there is no provision for extra POST arguments, any information about the message or recipient is encoded in the URI. In particular, one-click has no way to ask the user what address or from what list the user wishes to unsubscribe.
列表取消订阅标头中的URI必须包含足够的信息，以标识邮件收件人和要从中删除收件人的列表，以便取消订阅过程能够自动完成。由于没有提供额外的POST参数，因此有关消息或收件人的任何信息都编码在URI中。特别是，单击一下无法询问用户希望取消订阅的地址或列表。
The POST request MUST NOT include cookies, HTTP authorization, or any other context information. The unsubscribe operation is logically unrelated to any previous web activity, and context information could inappropriately link the unsubscribe to previous activity.
POST请求不得包含cookie、HTTP授权或任何其他上下文信息。取消订阅操作在逻辑上与任何以前的web活动无关，上下文信息可能会将取消订阅与以前的活动不适当地链接。
The URI SHOULD include an opaque identifier or another hard-to-forge component in addition to, or instead of, the plaintext names of the list and the subscriber. The server handling the unsubscription SHOULD verify that the opaque or hard-to-forge component is valid. This will deter attacks in which a malicious party sends spam with List-Unsubscribe links for a victim list, with the intention of causing list unsubscriptions from the victim list as a side effect of users reporting the spam, or where the attacker does POSTs directly to the mail sender's unsubscription server.
除了列表和订阅者的明文名称之外，URI还应该包含一个不透明的标识符或另一个难以伪造的组件。处理取消订阅的服务器应验证不透明或难以伪造的组件是否有效。这将阻止以下攻击：恶意方通过受害者列表的列表取消订阅链接发送垃圾邮件，意图导致从受害者列表取消订阅列表，作为用户报告垃圾邮件的副作用，或者攻击者直接向邮件发件人的取消订阅服务器发送邮件。
The mail sender needs to provide the infrastructure to handle POST requests to the specified URI in the List-Unsubscribe header, and to handle the unsubscribe requests that its mail will provoke.
邮件发送者需要提供基础结构来处理对列表取消订阅标头中指定URI的POST请求，并处理其邮件将引发的取消订阅请求。
The mail sender MUST NOT return an HTTPS redirect, since redirected POST actions have historically not worked reliably, and many browsers have turned redirected HTTP POSTs into GETs.
邮件发送者不能返回HTTPS重定向，因为重定向的POST操作在历史上并不可靠，而且许多浏览器已经将重定向的HTTP POST转换为GET。
This document does not update [RFC2369], so the usage of List-Unsubscribe URIs other than for one-click remains unchanged.
本文档不更新[RFC2369]，因此除单击外，列表取消订阅URI的用法保持不变。
A mail receiver can do a one-click unsubscription by performing an HTTPS POST to the HTTPS URI in the List-Unsubscribe header. It sends the key/value pair in the List-Unsubscribe-Post header as the request body.
邮件接收者可以通过对列表Unsubscribe标头中的HTTPS URI执行HTTPS POST来执行一键取消订阅。它发送列表Unsubscribe Post头中的键/值对作为请求主体。
The POST content SHOULD be sent as 'multipart/form-data' [RFC7578] or MAY be sent as 'application/x-www-form-urlencoded'. These encodings are the ones used by web browsers when sending forms. The target of the POST action is the same as the one in the GET action for a manual unsubscription, so this is intended to allow the same server code to handle both.
帖子内容应以“多部分/表单数据”[RFC7578]的形式发送，也可以以“application/x-www-form-urlencoded”的形式发送。这些编码是web浏览器在发送表单时使用的编码。POST操作的目标与手动取消订阅的GET操作中的目标相同，因此这是为了允许相同的服务器代码处理这两者。
The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent. When and how the user consent is obtained is not part of this specification.
未经用户同意，邮件接收方不得在HTTPS URI上执行POST。何时以及如何获得用户同意不属于本规范的一部分。
The message needs at least one valid authentication identifier. In this version of the specification, the only supported identifier type is DKIM [RFC6376]. Hence, senders MUST apply at least one valid DKIM signature to the message.
消息至少需要一个有效的身份验证标识符。在此版本的规范中，唯一支持的标识符类型是DKIM[RFC6376]。因此，发件人必须对邮件应用至少一个有效的DKIM签名。
The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.
“列表取消订阅”和“列表取消订阅帖子”标题必须包含在签名中，并包含在有效DKIM签名标题字段的“h=”标记中。
If the message does not have the required DKIM signature, the mail receiver SHOULD NOT offer a one-click unsubscribe for that message.
如果邮件没有所需的DKIM签名，邮件接收者不应为该邮件提供一键取消订阅。
The following ABNF imports fields, WSP, and CRLF from [RFC5322].
以下ABNF从[RFC5322]导入字段、WSP和CRLF。
fields =/ list-unsubscribe-post
字段=/列出取消订阅帖子
list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF
list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF
postarg = "List-Unsubscribe=One-Click"
postarg=“列表取消订阅=单击一次”
The List-Unsubscribe header can contain a plaintext or encoded version of the recipient address, but that address is usually also in the To: header. This specification allows anyone with access to a
List Unsubscribe标头可以包含收件人地址的纯文本或编码版本，但该地址通常也位于To:标头中。本规范允许任何人访问
message to unsubscribe the recipient of the message, but that's typically the case with existing List-Unsubscribe, just with more steps.
“邮件”以取消订阅邮件收件人，但这通常是现有列表取消订阅的情况，只需执行更多步骤。
A malicious mailer could send spam with content intended to provoke large numbers of unsubscriptions and with suitably crafted headers to send POST requests to servers that perhaps don't want them. But it's been possible to provoke GET requests in a similar way for a long time (and much easier, due to spam filter auto-fetches), so the chances of significantly increased annoyance seem low. The content of the List-Unsubscribe-Post header is limited to a single known key/ value pair to prevent an attacker from creating malicious messages where the POST operation could simulate a user filling in an arbitrary form on a victim website.
恶意邮件发送者可以发送垃圾邮件，内容旨在引发大量的取消订阅，并使用精心编制的标题将POST请求发送到可能不需要它们的服务器。但是在很长一段时间内，以类似的方式引发GET请求是可能的（而且由于垃圾邮件过滤器自动抓取，这种方式更加容易），因此显著增加烦恼的可能性似乎很低。List Unsubscribe Post标头的内容仅限于单个已知密钥/值对，以防止攻击者创建恶意消息，其中Post操作可能会模拟用户在受害者网站上填写任意表单。
The unsubscribe operation provides a strong hint to the mailer that the address to which the message was sent was valid, and could in principle be used as a way to test whether an email address is valid. In practice, though, there are simpler ways such as embedding image links into the HTML of a message and seeing whether the recipient fetches the images.
“取消订阅”操作向邮件发送者提供了一个强烈的提示，表明邮件发送到的地址是有效的，原则上可以用作测试电子邮件地址是否有效的方法。但实际上，有更简单的方法，比如将图像链接嵌入到邮件的HTML中，并查看收件人是否获取图像。
Since the mailer's server that receives the POST request cannot in general tell where the request is coming from, the URI SHOULD contain an opaque identifier or another hard-to-forge component to identify the list and recipient address. That can ensure that the request originated from the List-Unsubscribe and List-Unsubscribe-Post headers in a message the mailer sent. Also, the request MUST NOT include cookies or other context information to prevent the server from associating the request with previous web requests.
由于接收POST请求的邮件服务器通常无法分辨请求来自何处，因此URI应包含不透明标识符或另一个难以伪造的组件，以标识列表和收件人地址。这可以确保请求源于邮件发送者发送的邮件中的List Unsubscribe和List Unsubscribe Post头。此外，请求不得包含cookie或其他上下文信息，以防止服务器将请求与以前的web请求关联。
IANA has added a new entry to the "Permanent Message Header Field Names" registry.
IANA在“永久消息头字段名”注册表中添加了一个新条目。
Header field name: List-Unsubscribe-Post
标题字段名称：列表取消订阅帖子
Applicable protocol: mail
适用协议：邮件
Status: standard
状态：标准
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: RFC 8058
规范文件：RFC 8058
Header in Email
电子邮件中的标题
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Resulting POST request
结果POST请求
POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-Click
列表取消订阅=单击一次
Header in Email
电子邮件中的标题
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Resulting POST request
结果POST请求
POST /unsubscribe.html?opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
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
列表取消订阅=单击一次
Header in Email
电子邮件中的标题
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe:
<mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html/opaque123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Resulting POST request
结果POST请求
POST /unsubscribe.html/opaque=123456789 HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---FormBoundaryjWmhtjORrn
Content-Length: 124
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"
---FormBoundaryjWmhtjORrn
Content-Disposition: form-data; name="List-Unsubscribe"
One-Click
---FormBoundaryjWmhtjORrn--
One-Click
---FormBoundaryjWmhtjORrn--
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC2369, July 1998, <http://www.rfc-editor.org/info/rfc2369>.
[RFC2369]Neufeld，G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，DOI 10.17487/RFC2369，1998年7月<http://www.rfc-editor.org/info/rfc2369>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<http://www.rfc-editor.org/info/rfc6376>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, <http://www.rfc-editor.org/info/rfc7578>.
[RFC7578]Masinter，L.“从表单返回值：多部分/表单数据”，RFC 7578，DOI 10.17487/RFC7578，2015年7月<http://www.rfc-editor.org/info/rfc7578>.
Authors' Addresses
作者地址
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States of America
John Levine Taughannock Networks美国纽约州杜鲁曼斯堡727号邮政信箱14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Tobias Herkula optivo GmbH Wallstrasse 16 Berlin 10179 Germany
Tobias Herkula optivo GmbH Wallstrasse 16柏林10179德国
Phone: +49 30 768078 129
Email: t.herkula@optivo.com
URI: https://www.optivo.com
Phone: +49 30 768078 129
Email: t.herkula@optivo.com
URI: https://www.optivo.com