Network Working Group K. Moore
Request for Comments: 3834 University of Tennessee
Category: Standards Track August 2004
Network Working Group K. Moore
Request for Comments: 3834 University of Tennessee
Category: Standards Track August 2004
Recommendations for Automatic Responses to Electronic Mail
自动回复电子邮件的建议
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders.
此备忘录建议使用自动响应传入电子邮件的软件，包括“外出”或“休假”响应生成器、邮件过滤软件、基于电子邮件的信息服务和其他自动响应程序。这些建议的目的是阻止由此类软件引起或加剧的不良行为，鼓励自动邮件响应者之间的统一行为（如适用），并消除自动邮件响应者实施者之间的一些混淆源。
Many programs which automatically respond to email are currently in use. Although these programs vary widely in their function, several problems with this class of programs have been observed, including: significant numbers of useless or unwanted response and responses sent to inappropriate addresses, and occasional incidences of mail loops or "sorcerer's apprentice" mode. This memo recommends behavior for programs that automatically respond to electronic mail in order to reduce the number of problems caused by such programs.
许多自动回复电子邮件的程序目前正在使用。尽管这些程序在功能上差异很大，但这类程序存在一些问题，包括：大量无用或不必要的响应和发送到不适当地址的响应，以及偶尔出现的邮件循环或“巫师学徒”模式。此备忘录建议自动响应电子邮件的程序的行为，以减少此类程序引起的问题数量。
(Note: the term "sorcerer's apprentice mode" is defined as a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug.) (From [I1.JARGON])
（注：术语“巫师学徒模式”被定义为协议中的一个bug，在某些情况下，接收消息会导致发送多个消息，每个消息在接收时都会触发相同的bug。）（来自[I1.行话]）
This document is limited in scope to Internet electronic mail messages and many of its recommendations are specifically tailored for the protocol elements and data models used in Internet electronic mail messages and SMTP transport envelopes. Use of these recommendations in other messaging contexts such as instant messaging, SMS, or Usenet has not been considered, and is outside of the scope of this document.
本文件的范围仅限于互联网电子邮件，其许多建议是专门针对互联网电子邮件和SMTP传输信封中使用的协议元素和数据模型而制定的。未考虑在即时消息、SMS或Usenet等其他消息传递上下文中使用这些建议，不在本文档范围内。
There are several different types of automatic responses. At least two types of automatic responses have been defined in IETF standards - Delivery Status Notifications [I2.RFC3464] which are intended to report the status of a message delivery by the message transport system, and Message Disposition Notifications [I3.RFC3798] which are intended to report of the disposition of a message after it reaches a recipient's mailbox. These responses are defined elsewhere and are generally not within the purview of this document, except that this document recommends specific cases where they should or should not be used.
有几种不同类型的自动响应。IETF标准中至少定义了两种类型的自动响应-传递状态通知[I2.RFC3464]，用于报告消息传输系统的消息传递状态，以及消息处置通知[I3.RFC3798]用于报告邮件到达收件人邮箱后的处理情况。这些响应在其他地方定义，通常不在本文件的范围内，但本文件建议使用或不使用这些响应的具体情况除外。
Other types of automatic response in common use include:
其他常用的自动响应类型包括：
- "Out of office" or "vacation" notices, which are intended to inform the sender of a message that the message is unlikely to be read, or acted on, for some amount of time,
- “离职”或“休假”通知，旨在通知消息发送者消息在一段时间内不太可能被阅读或执行，
- "Change of address" notices, intended to inform the sender of a message that the recipient address he used is obsolete and that a different address should be used instead (whether or not the subject message was forwarded to the current address),
- “地址变更”通知，旨在通知邮件发送者他使用的收件人地址已过时，应使用不同的地址（无论主题邮件是否转发到当前地址），
- "Challenges", which require the sender of a message to demonstrate some measure of intelligence and/or willingness to agree to some conditions before the subject message will be delivered to the recipient (often to minimize the effect of "spam" or viruses on the recipient),
- “挑战”，要求邮件的发件人在将主题邮件发送给收件人之前，展示一定程度的智慧和/或同意某些条件的意愿（通常是为了尽量减少“垃圾邮件”或病毒对收件人的影响），
- Email-based information services, which accept requests (presumably from humans) via email, provide some service, and issue responses via email also. (Mailing lists which accept subscription requests via email fall into this category),
- 基于电子邮件的信息服务，通过电子邮件接受请求（可能来自人类），提供一些服务，并通过电子邮件发出回复。（通过电子邮件接受订阅请求的邮件列表属于此类），
- Information services similar to those mentioned above except that they are intended to accept messages from other programs, and
- 与上述信息服务类似的信息服务，但它们旨在接受来自其他程序的消息，以及
- Various kinds of mail filters (including "virus scanners") which act on behalf of a recipient to alter the content of messages before forwarding them to that recipient, and issue responses in the event a message is altered.
- 各种邮件过滤器（包括“病毒扫描器”），它们代表收件人在将邮件转发给收件人之前更改邮件内容，并在邮件被更改时发出响应。
Recognizing the wide variety of response types in use, these recommendations distinguish between several classes of automatic responders according to the party or service on whose behalf the responder acts:
鉴于使用的响应类型多种多样，这些建议根据响应者代表的一方或服务区分了几类自动响应者：
- "Service Responders" exist to provide access to some service via email requests and responses. These are permanently associated with one or more email addresses, and when sending to such an address the sender presumably expects an automatic response. An email-based file retrieval service is an example of a Service Responder. A calendar service that allows appointment requests to be made via email, and which responds to such requests, would be another example of a Service Responder.
- “服务响应者”通过电子邮件请求和响应提供对某些服务的访问。这些邮件与一个或多个电子邮件地址永久关联，当发送到这样一个地址时，发件人可能希望收到自动回复。基于电子邮件的文件检索服务是服务响应者的一个示例。服务响应者的另一个例子是日历服务，该服务允许通过电子邮件发出预约请求，并响应此类请求。
- "Personal Responders" exist to make automatic responses on behalf of a single recipient address, in addition to, or in lieu of, that recipient reading the message. These responders operate according to criteria specified on a per-recipient basis. The UNIX "vacation" program is an example of a Personal Responder. A responder that accepts mail sent to a single address, attempts to analyze and classify the contents, and then issues a response which is dependent on that classification, is also a Personal Responder.
- “个人响应者”的存在是为了代表单个收件人地址，除了或代替该收件人阅读邮件之外，自动做出响应。这些响应者根据每个接收者指定的标准进行操作。UNIX“休假”程序是个人响应程序的一个示例。接受发送到单个地址的邮件，尝试分析和分类内容，然后根据该分类发布响应的响应者也是个人响应者。
- "Group Responders" exist to make automatic responses on behalf of any of a significant set of recipient addresses (say, every recipient in a particular DNS domain), in advance of, or in lieu of, a response from the actual recipient. Group Responders are similar to Personal Responders except that in the case of a Group Responder the criteria for responding are not set on a per-recipient basis. A "virus scanner" program that filtered all mail sent to any recipient on a particular server, and sent responses when a message was rejected or delivered in an altered form, might be an example of a Group Responder.
- “组响应者”的存在是为了在实际接收者的响应之前或代替实际接收者的响应，代表任何一组重要的接收者地址（例如，特定DNS域中的每个接收者）进行自动响应。团体响应者与个人响应者相似，不同之处在于，对于团体响应者，响应标准不是基于每个接收者设置的。一个“病毒扫描程序”可以过滤发送给特定服务器上任何收件人的所有邮件，并在邮件被拒绝或以更改的形式传递时发送响应，这可能是组响应程序的一个示例。
Appropriate behavior for a responder varies from one class to another. A behavior which might be appropriate from a Service Responder (where the sender is expecting an automatic response) might not be appropriate from a Personal Responder. For example, a Service Responder might send a very long response to a request, or one that is not in a human-readable format, according to the needs of that
响应者的适当行为因类而异。服务响应者可能适合的行为（发送者期望自动响应）可能不适合个人响应者。例如，服务响应者可能会根据请求的需要，向请求发送很长的响应，或者发送非人类可读格式的响应
service. However a Personal Responder should assume that a human being is reading the response and send only brief responses in plain text.
服务然而，个人回复者应该假设有人在阅读回复，并且只发送简短的纯文本回复。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in [N1.RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”、“建议”、“不建议”和“可能”应按照[N1.RFC2119]中所述进行解释。
The term "subject message" is used to refer to a message which causes a response to be sent.
术语“主题消息”用于指导致发送响应的消息。
The term "response" refers to a message that is automatically issued on receipt of a subject message by a responder.
术语“响应”是指响应者在收到主题消息时自动发出的消息。
A "responder" is a process that automatically responds to subject messages under some well-defined set of conditions.
“响应者”是一个过程，它在一些定义良好的条件下自动响应主题消息。
Unless specified otherwise, the term "recipient" refers to the email addresses to which a subject message was delivered (rather than, for instance, the address to which the response was sent). A "recipient" address might be permanently associated with a responder, or it might be the address of a human being whose mail is, under some conditions, answered by a responder.
除非另有规定，否则术语“收件人”指的是主题邮件发送到的电子邮件地址（而不是，例如，响应发送到的地址）。“收件人”地址可能与响应者永久关联，也可能是在某些情况下其邮件由响应者应答的人的地址。
An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks.
自动应答器不得盲目地为收到的每条消息发送响应。在实践中，总是有理由拒绝回复某些类型的收到的邮件，例如，为了防止循环，为了避免回复“垃圾邮件”或病毒，为了避免被用作清洗或放大滥用邮件的手段，为了避免不适当地泄露收件者的个人信息（例如，避免自动显示收件人最近未阅读其邮件），并阻止针对响应者的拒绝服务攻击。根据响应者的目的，决定是否响应的标准因响应者而异。一般而言，应注意避免发送无用或冗余的响应，并避免造成邮件循环或促进拒绝服务大头钉。
Here are some broad guidelines:
以下是一些广泛的指导原则：
- Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field (see below), where that field has any value other than "no".
- 对于包含自动提交的标题字段（见下文）的任何消息，如果该字段具有除“否”以外的任何值，则不应发出自动响应。
- Personal and Group responses that are intended to notify the sender of a message of the recipient's inability to read or reply to the message (e.g., "away from my mail" or "too busy" notifications) SHOULD NOT issue the same response to the same sender more than once within a period of several days, even though that sender may have sent multiple messages. A 7-day period is RECOMMENDED as a default.
- 旨在通知发件人收件人无法阅读或回复邮件的个人和组响应（例如，“远离我的邮件”或“太忙”通知）不应在几天内多次向同一发件人发出相同的响应，即使该发件人可能已发送多条消息。建议默认为7天。
- Personal and Group responses whose purpose is to notify the sender of a message of a temporary absence of the recipient (e.g., "vacation" and "out of the office" notices) SHOULD NOT be issued unless a valid address for the recipient is explicitly included in a recipient (e.g., To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc) field of the subject message. Since a recipient may have multiple addresses forwarded to the same mailbox, recipients SHOULD be able to specify a set of addresses to the responder which it will recognize as valid for that recipient.
- 除非收件人中明确包含收件人的有效地址（如收件人、抄送、密件抄送、转发至、转发抄送或转发密件抄送），否则不应发布旨在通知发件人收件人暂时不在的个人和团体回复（如“休假”和“外出”通知）主题消息的字段。由于收件人可能有多个地址转发到同一邮箱，因此收件人应该能够向响应者指定一组地址，并将其识别为对该收件人有效。
Note: RFC 2822 section 3.6.3 permits varying uses of the Bcc field, some of which would allow the sender of the subject message to explicitly specify the recipient's address as a "Bcc" recipient without a Bcc field appearing in the message as delivered, or without the Bcc field in the delivered message containing the recipient's address. However, perhaps because Bcc's are rarely used, the heuristic of not responding to messages for which the recipient was not explicitly listed in a To, CC, or Bcc header field has been found to work well in practice.
注：RFC 2822第3.6.3节允许对密件抄送字段进行不同的使用，其中一些允许主题邮件的发件人明确指定收件人的地址为“密件抄送”收件人，而在传递的邮件中不显示密件抄送字段，或者在包含收件人地址的传递邮件中不显示密件抄送字段。然而，可能是因为很少使用密件抄送，在实践中发现，不响应收件人未在收件人、抄送或密件抄送标头字段中明确列出的邮件的启发式方法效果良好。
- Personal and Group Responders MAY refuse to generate responses except to known correspondents or addresses of otherwise "trusted" individuals. Such responders MAY also generate different kinds of responses for "trusted" vs. "untrusted" addresses. This might be useful, for instance, to avoid inappropriate disclosure of personal information to arbitrary addresses.
- 个人和团体响应者可拒绝生成响应，但已知的通信者或其他“受信任”个人的地址除外。此类响应者还可以针对“受信任”和“不受信任”地址生成不同类型的响应。例如，这可能有助于避免向任意地址不当披露个人信息。
- Responders MUST NOT generate any response for which the destination of that response would be a null address (e.g., an address for which SMTP MAIL FROM or Return-Path is <>), since the response would not be delivered to a useful destination. Responders MAY refuse to generate responses for addresses commonly used as return addresses by responders - e.g., those with local-parts matching "owner-*", "*-request", "MAILER-DAEMON", etc. Responders are encouraged to check the destination address for validity before generating the response, to avoid generating responses that cannot be delivered or are unlikely to be useful.
- 响应者不得生成响应目的地为空地址的任何响应（例如，SMTP邮件来源或返回路径为<>）的地址，因为响应不会传递到有用的目的地。响应者可能会拒绝为响应者通常用作返回地址的地址生成响应，例如，那些本地部分与“owner-*”、“*-请求”、“MAILER-DAEMON”等匹配的地址。鼓励响应者在生成响应之前检查目标地址的有效性，避免产生无法交付或不太可能有用的响应。
- In order to avoid responding to spam and to certain kinds of attacks, automatic responses from Service Responders SHOULD NOT be sent for extremely malformed requests. This may include checking that the subject message has a content-type and content appropriate to that service.
- 为了避免对垃圾邮件和某些类型的攻击做出响应，对于格式极其错误的请求，不应发送来自服务响应者的自动响应。这可以包括检查主题消息是否具有适合于该服务的内容类型和内容。
- Because the vast majority of email is unauthenticated, and return addresses are easily forged, in order to avoid being used as a means of denial-of-service attacks (i.e., to flood mailboxes with unwanted content) Service Responders SHOULD NOT return large responses (say, more than a few kilobytes) without specific knowledge that the request was actually authorized by the party associated with the address to which the response will be sent. Similarly, Service Responders SHOULD NOT cause unwanted side-effects (such as subscribing the sender to a mailing list) without reasonable assurance that the request was authorized by the affected party.
- 由于绝大多数电子邮件都未经身份验证，而且返回地址很容易伪造，为了避免被用作拒绝服务攻击的手段（即用不需要的内容淹没邮箱），服务响应者不应返回大量响应（例如，超过几千字节）不知道请求实际上是由与响应将发送到的地址相关联的一方授权的。类似地，服务响应者不应在没有合理保证请求得到受影响方授权的情况下造成不必要的副作用（例如向发件人订阅邮件列表）。
NOTE: Since each responder has a different purpose and a different set of potential threats to which it might be subjected, whether any particular means of authentication is appropriate for a particular responder is not in scope for this document.
注：由于每个响应者都有不同的目的和可能受到的一组不同的潜在威胁，因此任何特定的身份验证方法是否适用于特定响应者不在本文档的范围内。
- A responder MAY refuse to send a response to a subject message which contains any header or content which makes it appear to the responder that a response would not be appropriate. For instance, if the subject message contained a Precedence header field [I4.RFC2076] with a value of "list" the responder might guess that the traffic had arrived from a mailing list, and would not respond if the response were only intended for personal messages. For similar reasons, a responder MAY ignore any subject message with a List-* field [I5.RFC2369]. (Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.)
- 响应者可以拒绝向主题消息发送响应，该主题消息包含使响应者觉得响应不合适的任何标题或内容。例如，如果主题消息包含值为“list”的优先头字段[I4.rfc276]，则响应者可能会猜测通信量是从邮件列表中到达的，并且如果响应仅用于个人消息，则不会响应。出于类似的原因，响应者可能会忽略带有列表-*字段[I5.RFC2369]的任何主题消息。（由于优先级不是一个标准的头字段，其使用和解释在野外差异很大，因此本规范不建议在存在优先级的情况下使用特定的响应程序行为。）
The following sections specify details of the contents of automatic responses, including the header of the response message, the content of the response, and the envelope in which the response is transmitted to the email transport system.
以下各节详细说明了自动响应的内容，包括响应消息的标题、响应的内容以及将响应传输到电子邮件传输系统的信封。
The fields in the message header should be set as follows:
消息头中的字段应设置如下：
In correspondence between humans, the From field serves multiple purposes: It identifies the author of the message (or in some cases, the party or parties on whose behalf the message was sent), and it is the default destination of replies from humans. Unfortunately, some mail systems still send non-delivery reports and other kinds of automatic responses to the From address.
在人与人之间的通信中，“发件人”字段有多种用途：它标识消息的作者（或在某些情况下，标识消息的发送方），并且它是人回复的默认目的地。不幸的是，一些邮件系统仍然向发件人地址发送未送达报告和其他类型的自动响应。
For automatic responses, the role of the From field in determining the destination of replies to the response from humans is less significant, because in most cases it is not useful or appropriate for a human (or anyone) to reply to an automatic response. One exception is when there is some problem with the response; it should be possible to provide feedback to the person operating the responder.
对于自动响应，“发件人”字段在确定对来自人类的响应的答复的目的地方面的作用不太重要，因为在大多数情况下，人类（或任何人）对自动响应的答复都是无用或不合适的。一个例外是当响应出现问题时；应能够向操作响应者的人员提供反馈。
So in most cases the From address in an automatic response needs to be chosen according to the following criteria:
因此，在大多数情况下，需要根据以下标准选择自动响应中的发件人地址：
- To provide an indication of the party or agent on whose behalf the response was sent,
- 提供代表其发送回复的一方或代理人的指示，
- To provide an address to which a recipient of an inappropriate response can request that the situation be corrected, and
- 提供一个地址，收到不适当回复的收件人可以向该地址请求纠正情况，以及
- To diminish the potential for mail loops.
- 减少邮件循环的可能性。
The following behavior is thus recommended:
因此，建议采取以下行为：
- For responses sent by Service Responders, the From field SHOULD contain an address which can be used to reach the (human) maintainer of that service. The human-readable portion of the From field (the display-name preceding the address) SHOULD contain a name or description of the service to identify the service to humans.
- 对于服务响应者发送的响应，“发件人”字段应包含可用于联系该服务的（人工）维护者的地址。“发件人”字段的人类可读部分（地址前的显示名称）应包含服务的名称或描述，以向人类标识服务。
- For responses sent by Personal Responders, the From field SHOULD contain the name of the recipient of the subject message (i.e., the user on whose behalf the response is being sent) and an address chosen by the recipient of the subject message to be recognizable to correspondents. Often this will be the same address that was used to send the subject message to that recipient.
- 对于个人响应者发送的响应，“发件人”字段应包含主题消息接收者的姓名（即代表其发送响应的用户）和主题消息接收者选择的通信者可识别的地址。通常，这将是用于向收件人发送主题邮件的相同地址。
In the case of a recipient having multiple mail addresses forwarded to the same mailbox (and responder), a Personal Responder MAY use heuristics to guess, based on the information available in various message header fields, which of several addresses for that recipient the sender is likely to have used, and use that address in the From field of the response. However it MUST be possible for a recipient on whose behalf the responder is acting to explicitly specify the human-readable name and address to be used in the From header fields of responses.
在收件人具有多个转发到同一邮箱（和响应者）的邮件地址的情况下，个人响应者可以使用试探法，基于各种消息头字段中可用的信息，猜测发件人可能使用了该收件人的多个地址中的哪一个，并在响应的“发件人”字段中使用该地址。但是，响应者代表的收件人必须能够明确指定要在响应的From头字段中使用的人类可读名称和地址。
Note: Due to privacy reasons it may be inappropriate for responders to disclose an address that is derived, say, from the recipient's login information (e.g., POP or IMAP user name or account name on a multiuser computer) or which discloses the specific name of the computer where the response was generated. Furthermore these do not necessarily produce a valid public email address for the recipient. For this reason, Personal Responders MUST allow the From field of a Personal Response to be set by the recipient on whose behalf the responder is acting.
注意：由于隐私原因，响应者可能不适合披露从接收者的登录信息（例如，POP或IMAP用户名或多用户计算机上的帐户名）衍生的地址，或者披露生成响应的计算机的特定名称。此外，这些不一定为收件人生成有效的公共电子邮件地址。因此，个人响应者必须允许响应者代表的接收者设置个人响应的“发件人”字段。
- For Group Responders, the From address SHOULD contain an email address which could be used to reach the maintainer of that Group Responder. Use of the Postmaster address for this purpose is NOT RECOMMENDED.
- 对于组响应者，发件人地址应包含可用于联系该组响应者的维护者的电子邮件地址。不建议为此目的使用邮政局长地址。
The human-readable portion of the From address (the "phrase" before the address, see [N2.RFC2822], section 3.2.6) SHOULD contain an indication of the function performed by the Group Responder and on whose behalf it operates (e.g., "Example Agency virus filter")
发件人地址的人类可读部分（地址前的“短语”，见[N2.RFC2822]，第3.2.6节）应包含由集团响应者执行的功能指示及其代表的操作（例如，“示例机构病毒过滤器”）
If a reply is expected by the responder, the Reply-To field of the response SHOULD be set to the address at which the reply is expected, even if this is the address of the same or another responder. Responders which request replies to be sent to responders MUST prevent mail loops and sorcerer's apprentice mode. Note that since (according to the previous section) the From field of the response SHOULD contain the address of a human, if the Reply-To field of the response is used to direct replies to a responder it will not be the same as the address in the From field.
如果响应者需要回复，则响应的“回复到”字段应设置为需要回复的地址，即使该地址是同一响应者或其他响应者的地址。请求回复发送给回复者的回复者必须防止邮件循环和巫师学徒模式。请注意，由于（根据上一节）响应的“发件人”字段应包含人员的地址，因此，如果响应的“答复”字段用于将答复直接发送给响应者，则它将与“发件人”字段中的地址不同。
Discussion: this assumes that the human recipient's user agent will normally send replies to the Reply-To address (if present), as recommended by [I6.RFC822] since 1982, but that it is still possible
讨论：这假设人类收件人的用户代理通常会按照[I6.RFC822]自1982年以来的建议向回复地址（如果存在）发送回复，但这仍然是可能的
for a recipient to reply to the From address if he or she finds it useful to do so. This is consistent with the intended use of these fields in [I6.RFC822] and [N2.RFC2822].
收件人如果认为回复发件人地址有用，则可以回复发件人地址。这与[I6.RFC822]和[N2.RFC2822]中这些字段的预期用途一致。
The To header field SHOULD indicate the recipient of the response. In general there SHOULD only be one recipient of any automatic response. This minimizes the potential for sorcerer's apprentice mode and denial-of-service attacks.
“收件人”标题字段应指示响应的收件人。一般来说，任何自动响应都应该只有一个接收者。这最大限度地减少了巫师学徒模式和拒绝服务攻击的可能性。
The Date header field SHOULD indicate the date and time at which the response was generated. This MUST NOT be taken as any indication of the delivery date of the subject message, nor of the time at which the response was sent.
日期标题字段应指示生成响应的日期和时间。这不得视为主题消息的交付日期或响应发送时间的任何指示。
The Subject field SHOULD contain a brief indication that the message is an automatic response, followed by contents of the Subject field (or a portion thereof) from the subject message. The prefix "Auto:" MAY be used as such an indication. If used, this prefix SHOULD be followed by an ASCII SPACE character (0x20).
主题字段应包含消息是自动响应的简短指示，然后是主题消息的主题字段（或其一部分）的内容。前缀“Auto:”可用作此类指示。如果使用，此前缀后面应跟一个ASCII空格字符（0x20）。
NOTE: Just as the (Latin-derived) prefix "Re:" that is commonly used to indicate human-generated responses is sometimes translated to other languages by mail user agents, or otherwise interpreted by mail user agents as indication that the message is a reply, so the (Greek) prefix "Auto:" may also be translated or used as a generic indication that the message is an automatic response. However the "Auto:" indication is intended only as an aid to humans in processing the message. Mail processing software SHOULD NOT assume that the presence of "Auto:" at the beginning of a Subject field is an indication that the message was automatically submitted.
注意：正如通常用于表示人工生成的响应的（拉丁语派生的）前缀“Re:”有时被邮件用户代理翻译成其他语言，或者被邮件用户代理解释为表示邮件是回复，因此（希腊语）前缀“Auto:”也可以被翻译或用作消息是自动响应的一般指示。然而，“自动：”指示仅用于帮助人类处理信息。邮件处理软件不应假定主题字段开头出现“自动：”表示邮件已自动提交。
Note that the Subject field of the subject message may contain encoded-words formatted according to [N3.RFC2047] and [N4.RFC2231], and such text MAY be included in the Subject field of a response. In generating responses containing such fields there is rarely a need to decode and re-encode such text. It is usually sufficient to leave those encoded-words as they were in the subject message, merely prepending "Auto: " or other indication. However, it is still necessary to ensure that no line in the resulting Subject field that contains an encoded-word is greater than 76 ASCII characters in length (this refers to the encoded form, not the number of characters
注意，主题消息的主题字段可以包含根据[N3.RFC2047]和[N4.RFC2231]格式化的编码字，并且这种文本可以包括在响应的主题字段中。在生成包含此类字段的响应时，很少需要对此类文本进行解码和重新编码。通常，只需在“Auto:”或其他指示前加上前缀，就可以将这些编码单词保留在主题消息中。但是，仍然需要确保结果主题字段中包含编码字的行长度不超过76个ASCII字符（这是指编码形式，而不是字符数）
in the text being encoded). Also, if the responder truncates the Subject from the subject message it is necessary to avoid truncating Subject text in the middle of an encoded-word.
在正在编码的文本中）。此外，如果响应者从主题消息截断主体，则必须避免在编码词的中间截断主题文本。
The In-Reply-To and References fields SHOULD be provided in the header of a response message if there was a Message-ID field in the subject message, according to the rules in [N2.RFC2822] section 3.6.4.
根据[N2.RFC2822]第3.6.4节中的规则，如果主题消息中有消息ID字段，则应在响应消息的标题中提供In Reply To和References字段。
The Auto-Submitted field, with a value of "auto-replied", SHOULD be included in the message header of any automatic response. See section 5.
自动提交字段的值为“自动回复”，应包含在任何自动响应的消息头中。见第5节。
A response MAY include a Precedence field [I4.RFC2076] in order to discourage responses from some kinds of responders which predate this specification. The field-body of the Precedence field MAY consist of the text "junk", "list", "bulk", or other text deemed appropriate by the responder. Because the Precedence field is non-standard and its interpretation varies widely, the use of Precedence is not specifically recommended by this specification, nor does this specification recommend any particular value for that field.
响应可以包括优先字段[I4.RFC2076]，以阻止本规范之前某些类型响应者的响应。优先字段的字段正文可以由文本“垃圾”、“列表”、“批量”或响应者认为合适的其他文本组成。由于优先级字段是非标准的，其解释差异很大，因此本规范不特别建议使用优先级，本规范也不建议该字段使用任何特定值。
In general, messages sent by Personal or Group Responders SHOULD be brief, and in text/plain format. A multipart/alternative construct MAY be used to communicate responses in multiple languages, especially if in doing so it is desirable to use multiple charsets.
一般来说，个人或团体响应者发送的消息应该简短，并且采用文本/普通格式。多部分/备选构造可用于以多种语言传递响应，特别是在这样做时希望使用多个字符集的情况下。
Response messages SHOULD NOT include significant content from the subject message. In particular, Personal and Group responses SHOULD NOT contain non-text content from the subject message, and they SHOULD NOT include attachments from the subject message. Neither of these conditions applies to responders that specifically exist for the purpose of altering or translating content sent to them (for instance, a FORTRAN-to-C translator); however, such responders MUST employ measures to avoid being used as a means of laundering or forwarding undesirable content, such as spam or viruses.
响应消息不应包含主题消息中的重要内容。特别是，个人和组响应不应包含主题消息中的非文本内容，也不应包含主题消息中的附件。这些条件都不适用于专门为更改或翻译发送给他们的内容而存在的响应者（例如，FORTRAN-to-C翻译程序）；但是，此类响应者必须采取措施，避免被用作洗钱或转发垃圾邮件或病毒等不良内容的手段。
Note that when text from the Subject or other fields from the header of the subject message is included in the body of the response, it is necessary to decode any encoded-words that appeared in those fields
注意，当来自主题消息的标题的主题或其他字段的文本包含在响应的主体中时，有必要对这些字段中出现的任何编码字进行解码
before including in the message body, and to use an appropriate content-type, charset, and content-transfer-encoding. In some cases it may be necessary to transliterate text from the charset(s) used in the header of the subject message, to the charset(s) used in the body of the response. (It is much easier to implement a responder if text from the header of the subject message never needs to appear in the body of the response.)
在包含在消息正文中之前，使用适当的内容类型、字符集和内容传输编码。在某些情况下，可能需要将文本从主题消息头中使用的字符集音译到响应正文中使用的字符集。（如果主题消息标题中的文本不需要出现在响应正文中，那么实现响应者就容易多了。）
In general, it is appropriate to use Delivery Status Notifications (DSNs) for responses that are generated by the mail transport system as a result of attempts to relay, forward, or deliver mail, and only when the purpose of that response is to provide the sender of the subject message with information about the status of that mail delivery. For instance, a "virus scanner" which is activated by a mail delivery process to filter harmful content prior to delivery, could return a DSN with the Action field set to "failed" with a Status code of 5.7.1 (Delivery not authorized, message refused) if the entire message was not delivered due to security reasons; or it could return a DSN with the Action field set to "relayed" or "delivered" (as appropriate) with a Status code set to 2.6.4 (conversion with loss performed) if the message was relayed or delivered with the presumably harmful content removed. The DSN specification [I2.RFC3464], rather than this document, governs the generation and format of DSNs.
通常，对于邮件传输系统由于尝试中继、转发或传递邮件而生成的响应，并且仅当该响应的目的是向主题邮件的发件人提供有关该邮件传递状态的信息时，才适合使用传递状态通知（DSN）。例如，如果由于安全原因整个邮件未发送，邮件发送过程激活的“病毒扫描程序”可在发送前过滤有害内容，返回DSN，操作字段设置为“失败”，状态代码为5.7.1（未授权发送，邮件拒绝）；或者，如果消息是在删除了可能有害的内容的情况下中继或发送的，则它可以返回一个DSN，操作字段设置为“中继”或“已交付”（视情况而定），状态代码设置为2.6.4（执行了丢失转换）。DSN规范[I2.RFC3464]而不是本文档控制DSN的生成和格式。
Similarly, it is appropriate to use Message Disposition Notifications (MDNs) only for responses generated on the recipient's behalf, which are generated on or after delivery to a recipient's mailbox, and for which the purpose of the response is to indicate the disposition of the message. The MDN specification [I3.RFC3798], rather than this document, governs the generation and format of MDNs.
类似地，仅对代表收件人生成的响应使用邮件处置通知（MDN）是合适的，这些响应是在发送到收件人邮箱时或之后生成的，响应的目的是指示邮件的处置。MDN规范[I3.RFC3798]而不是本文档管理MDN的生成和格式。
This document is not intended to alter either the DSN or MDN specifications. Responses that fit within the criteria of DSN or MDN, as defined by the respective specifications, should be generated according to the DSN or MDN specification rather than this document. Responses which do not fit one of these sets of criteria should be generated according to this document.
本文件无意更改DSN或MDN规范。应根据DSN或MDN规范（而非本文件）生成符合DSN或MDN标准（如各规范所定义）的响应。不符合这些标准之一的响应应根据本文件生成。
The SMTP MAIL FROM address, or other envelope return address used to send the message, SHOULD be chosen in such a way as to make mail loops unlikely. A loop might occur, for instance, if both sender and
选择SMTP邮件发件人地址或用于发送邮件的其他信封返回地址时，应避免邮件循环。例如，如果发送方和
recipient of a message each have automatic responders - the recipient's responder sends mail to the sender's responder, which sends mail back to the recipient's responder.
每封邮件的收件人都有自动回复者-收件人的回复者将邮件发送给发件人的回复者，发件人的回复者将邮件发送回收件人的回复者。
The primary purpose of the MAIL FROM address is to serve as the destination for delivery status messages and other automatic responses. Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of <> MAY be used for this purpose. A MAIL FROM address which is specifically chosen for the purpose of sending automatic responses, and which will not automatically respond to any message sent to it, MAY be used instead of <>.
邮件发件人地址的主要用途是作为传递状态消息和其他自动响应的目的地。由于在大多数情况下，不适合对自动响应进行响应，并且响应者对传递状态消息不感兴趣，因此可以使用来自<>地址的邮件来实现此目的。可以使用专门为发送自动回复而选择的邮件发件人地址，但该地址不会自动回复发送给它的任何邮件，而不是<>。
The RCPT TO address will (of course) be the address of the intended recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER parameter of the RCPT command be specified if the SMTP server supports the DSN option [N5.RFC3461].
RCPT TO地址（当然）将是响应的预期收件人的地址。如果SMTP服务器支持DSN选项[N5.RFC3461]，建议指定RCPT命令的NOTIFY=NEVER参数。
In general, automatic responses SHOULD be sent to the Return-Path field if generated after delivery. If the response is generated prior to delivery, the response SHOULD be sent to the reverse-path from the SMTP MAIL FROM command, or (in a non-SMTP system) to the envelope return address which serves as the destination for non-delivery reports.
通常，如果在交付后生成，则应将自动响应发送到返回路径字段。如果响应是在传递之前生成的，则应将响应从SMTP MAIL from命令发送到反向路径，或（在非SMTP系统中）发送到作为未传递报告目的地的信封返回地址。
If the response is to be generated after delivery, and there is no Return-Path field in the subject message, there is an implementation or configuration error in the SMTP server that delivered the message or gatewayed the message outside of SMTP. A Personal or Group responder SHOULD NOT deliver a response to any address other than that in the Return-Path field, even if the Return-Path field is missing. It is better to fix the problem with the mail delivery system than to rely on heuristics to guess the appropriate destination of the response. Such heuristics have been known to cause problems in the past.
如果在传递后生成响应，并且主题邮件中没有返回路径字段，则在传递邮件或将邮件网关化到SMTP之外的SMTP服务器中存在实现或配置错误。个人或组响应者不应向返回路径字段以外的任何地址发送响应，即使返回路径字段缺失。解决邮件传递系统的问题比依靠启发式来猜测响应的适当目的地更好。过去人们知道，这种启发式方法会引起问题。
A Service Responder MAY deliver the response to the address(es) from the >From field, or to another address from the request payload, provided this behavior is precisely defined in the specification for that service. Services responders SHOULD NOT use the Reply-To field for this purpose.
服务响应者可以将响应从>发件人字段发送到地址，或从请求有效负载发送到另一个地址，前提是该服务的规范中精确定义了该行为。服务响应者不应为此目的使用“回复到”字段。
The Reply-To field SHOULD NOT be used as the destination for automatic responses from Personal or Group Responders. In general, this field is set by a human sender based on his/her anticipation of
“回复到”字段不应用作个人或组响应者自动响应的目的地。通常，此字段由人类发送者根据他/她的预期设置
how human recipients will respond to the specific content of that message. For instance, a human sender may use Reply-To to request that replies be sent to an entire mailing list. Even for replies from humans, there are cases where it is not appropriate to respond to the Reply-To address, especially if the sender has asked that replies be sent to a group and/or mailing list. Since a Personal or Group Responder operates on behalf of a human recipient, it is safer to assume that any Reply-To field present in the message was set by a human sender on the assumption that any reply would come from a human who had some understanding of the roles of the sender and other recipients. An automatic responder lacks the information necessary to understand those roles. Sending automatic responses to Reply-To addresses can thus result in a large number of people receiving a useless or unwanted message; it can also contribute to mail loops.
人类收件人将如何响应该邮件的特定内容。例如，人类发送者可以使用Reply To请求将回复发送到整个邮件列表。即使是来自人类的回复，也有不适合回复回复地址的情况，尤其是如果发件人要求将回复发送到组和/或邮件列表。由于个人或组响应者代表人类接收者操作，因此更安全的假设是，消息中存在的任何回复字段都是由人类发送者设置的，前提是任何回复都将来自对发送者和其他接收者的角色有一定了解的人。自动响应者缺乏理解这些角色所需的信息。因此，发送自动回复地址会导致大量人收到无用或不需要的消息；它还可以促进邮件循环。
Use of the From field as the destination for automatic responses has some of the same problems as use of Reply-To. In particular, the From field may list multiple addresses, while automatic responses should only be sent to a single address. In general, the From and Reply-To addresses are used in a variety of ways according to differing circumstances, and for this reason Personal or Group Responders cannot reliably assume that an address in the From or Reply-To field is an appropriate destination for the response. For these reasons the From field SHOULD NOT be used as a destination for automatic responses.
使用“发件人”字段作为自动响应的目标与使用“答复收件人”有一些相同的问题。特别是，“发件人”字段可能会列出多个地址，而自动响应只应发送到单个地址。通常，发件人和回复地址根据不同的情况以多种方式使用，因此个人或组响应者无法可靠地假定发件人或回复地址字段中的地址是响应的适当目的地。由于这些原因，“发件人”字段不应用作自动响应的目标。
Similarly, the Sender field SHOULD NOT be used as the destination for automatic responses. This field is intended only to identify the person or entity that sent the message, and is not required to contain an address that is valid for replies.
同样，发件人字段不应用作自动响应的目标。此字段仅用于标识发送邮件的个人或实体，不需要包含对回复有效的地址。
The Return-Path address is really the only one from the message header that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender.
返回路径地址实际上是来自消息头的唯一一个可以预期的地址，根据协议，它适合于发送方未预期的自动响应。
The purpose of the Auto-Submitted header field is to indicate that the message was originated by an automatic process, or an automatic responder, rather than by a human; and to facilitate automatic filtering of messages from signal paths for which automatically generated messages and automatic responses are not desirable.
Auto Submitted header字段的目的是指示消息是由自动进程或自动响应者发起的，而不是由人工发起的；以及便于从不需要自动生成消息和自动响应的信号路径中自动过滤消息。
The syntax of Auto-Submitted is as follows, using the ABNF notation of [N6.RFC2234]:
自动提交的语法如下，使用[N6.RFC2234]的ABNF符号：
auto-submitted-field = "Auto-Submitted:" [CFWS] auto-submitted [CFWS] CRLF
自动提交字段=“自动提交：”[CFWS]自动提交[CFWS]CRLF
auto-submitted = ( "no" / "auto-generated" /
"auto-replied" / extension )
opt-parameter-list
auto-submitted = ( "no" / "auto-generated" /
"auto-replied" / extension )
opt-parameter-list
extension = token
extension = token
opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
The symbols "CFWS" and "CRLF" are defined in [N2.RFC2822]. The symbols "token", and "parameter" are as defined in [N7.RFC2045] (as amended by [N4.RFC2231]).
符号“CFWS”和“CRLF”在[N2.RFC2822]中定义。符号“令牌”和“参数”如[N7.RFC2045]（经[N4.RFC2231]修订）所定义。
The maximum number of Auto-Submitted fields that may appear in a message header is 1.
邮件标题中可能出现的自动提交字段的最大数量为1。
The Auto-Submitted header field SHOULD NOT be supplied for messages that were manually submitted by a human. (However, user agents that allow senders to specify arbitrary fields SHOULD NOT prevent humans from setting the Auto-Submitted field, because it is sometimes useful for testing.)
对于人工提交的邮件，不应提供自动提交的标题字段。（但是，允许发件人指定任意字段的用户代理不应阻止用户设置自动提交字段，因为它有时对测试有用。）
The auto-generated keyword:
自动生成的关键字：
- SHOULD be used on messages generated by automatic (often periodic) processes (such as UNIX "cron jobs") which are not direct responses to other messages,
- 应用于自动（通常是定期）进程（如UNIX“cron作业”）生成的消息，这些进程不是对其他消息的直接响应，
- MUST NOT be used on manually generated messages,
- 不得用于手动生成的消息，
- MUST NOT be used on a message issued in direct response to another message,
- 不得用于直接响应另一条消息发出的消息，
- MUST NOT be used to label Delivery Status Notifications (DSNs) [I2.RFC3464], or Message Disposition Notifications (MDNs) [I3.RFC3798], or other reports of message (non)receipt or (non)delivery. Note: Some widely-deployed SMTP implementations currently use "auto-generated" to label non-delivery reports. These should be changed to use "auto-replied" instead.
- 不得用于标记传递状态通知（DSN）[I2.RFC3464]或邮件处置通知（MDN）[I3.RFC3798]或其他邮件（未）接收或（未）传递报告。注意：一些广泛部署的SMTP实现目前使用“自动生成”来标记未送达报告。这些应该改为使用“自动回复”。
The auto-replied keyword:
自动回复关键字：
- SHOULD be used on messages sent in direct response to another message by an automatic process,
- 应用于自动进程直接响应另一条消息而发送的消息，
- MUST NOT be used on manually-generated messages,
- 不得用于手动生成的消息，
- MAY be used on Delivery Status Notifications (DSNs) and Message Disposition Notifications (MDNs),
- 可用于传递状态通知（DSN）和邮件处置通知（MDN），
- MUST NOT be used on messages generated by automatic or periodic processes, except for messages which are automatic responses to other messages.
- 不得用于自动或定期流程生成的消息，但自动响应其他消息的消息除外。
The "no" keyword MAY be used to explicitly indicate that a message was originated by a human, if for some reason this is found to be appropriate.
如果出于某种原因认为“否”是合适的，则可以使用“否”关键字明确表示消息是由人发出的。
Extension keywords may be defined in the future, though it seems unlikely. The syntax and semantics of such keywords must be published as RFCs and approved using the IETF Consensus process [N8.RFC2434]. Keywords beginning with "x-" are reserved for experiments and use among consenting parties. Recipients of messages containing an Auto-Submitted field with any keyword other than "no" MAY assume that the message was not manually submitted by a human.
扩展关键字可能会在将来定义，尽管看起来不太可能。这些关键字的语法和语义必须以RFC的形式发布，并使用IETF协商一致流程进行批准[N8.RFC2434]。以“x-”开头的关键字保留供双方同意的实验和使用。包含自动提交字段且带有除“否”以外的任何关键字的邮件的收件人可能会认为该邮件不是由人工提交的。
Optional parameters may also be defined by an IETF Consensus process. The syntax of optional parameters is given here to allow for future definition should they be needed. Implementations of Auto-Submitted conforming to this specification MUST NOT fail to recognize an Auto-Submitted field and keyword that contains syntactically valid optional parameters, but such implementations MAY ignore those parameters if they are present. Parameter names beginning with "x-" are reserved for experiments and use among consenting parties.
可选参数也可由IETF共识过程定义。这里给出了可选参数的语法，以便将来需要时进行定义。符合本规范的自动提交的实现必须能够识别自动提交的字段和关键字，该字段和关键字包含语法上有效的可选参数，但此类实现可能会忽略这些参数（如果存在）。以“x-”开头的参数名称保留供实验和同意方使用。
The "comment" syntactical construct from [N2.RFC2822] can be used to indicate a reason why this message was automatically submitted.
[N2.RFC2822]中的“comment”语法结构可用于指示自动提交此消息的原因。
Automatic responders introduce the potential for several kinds of attack, including:
自动应答器引入了几种攻击的可能性，包括：
- Use of such responders to relay harmful or abusive content (worms, viruses, spam, and spymail) for the purpose of wider distribution of the content or masking the source of such content;
- 使用此类响应者传播有害或滥用内容（蠕虫、病毒、垃圾邮件和间谍邮件），以便更广泛地传播内容或掩盖此类内容的来源；
- Use of such responders to mount denial-of-service attacks by using responders to relay messages to large numbers of addresses, or to flood individual mailboxes with a large amount of unwanted content, or both;
- 使用此类响应者通过使用响应者将消息中继到大量地址，或用大量不需要的内容淹没单个邮箱，或两者兼而有之，来发起拒绝服务攻击；
- Deliberate or accidental use of such responders to construct mail loops or "sorcerer's apprentice mode", thus taxing the resources of the mail transport system;
- 故意或意外使用此类响应者构建邮件循环或“巫师学徒模式”，从而对邮件传输系统的资源征税；
- Use of such responders to determine whether recipient addresses are valid, especially when such information is not otherwise provided (e.g., SMTP RCPT or VRFY command responses) and is not intended to be disclosed;
- 使用此类响应者来确定收件人地址是否有效，尤其是当此类信息未另行提供（例如SMTP RCPT或VRFY命令响应）且不打算披露时；
- Use of such responders to obtain personal information about recipients, including information about recipients' recent usage of his mailbox or recent activity;
- 使用此类响应者获取收件人的个人信息，包括收件人最近使用其邮箱或最近活动的信息；
- In addition, the responder itself may be subject to attack by sending it large numbers of requests.
- 此外，响应者本身可能会通过向其发送大量请求而受到攻击。
This document attempts to reduce the vulnerability of responders to such attack, in particular by
本文件试图降低响应者对此类攻击的脆弱性，特别是通过
- Recommending that responders not relay significant content from the subject message (thus minimizing the potential for use of responders to launder or amplify attacker-chosen content)
- 建议响应者不要转发主题消息中的重要内容（从而最大限度地降低使用响应者清洗或放大攻击者选择的内容的可能性）
- Recommending that responders clearly mark responses with the "Auto-Submitted: auto-replied" header field to distinguish them from messages originated by humans (in part, to minimize the potential for loops and denial-of-service attacks),
- 建议响应者使用“自动提交：自动回复”标题字段清楚地标记响应，以将其与人类发出的消息区分开来（部分是为了最大限度地降低循环和拒绝服务攻击的可能性），
- Recommending that Personal and Group Responders limit the number of responses sent to any individual per period of time (also limiting the potential damage caused by loops),
- 建议个人和团体响应者限制每个时间段发送给任何个人的响应数量（同时限制环路造成的潜在损害），
- Recommending that responders respond to at most one address per incoming message (to minimize the potential for deliberate or accidental denial-of-service via "multiplication" or sorcerer's apprentice mode),
- 建议响应者对每个传入消息最多响应一个地址（通过“乘法”或巫师学徒模式将故意或意外拒绝服务的可能性降至最低），
- Recommending that responses from Personal and Group Responders should be brief and in plain text format (to minimize the potential for mail responders to be used as mechanisms for transmitting harmful content and/or disguising the source of harmful content).
- 建议个人和团体回复者的回复应简短且采用纯文本格式（以尽量减少邮件回复者被用作传输有害内容和/或掩盖有害内容来源的机制的可能性）。
However, because email addresses are easily forged, attacks are still possible for any email responder which does not limit access and require authentication before issuing a response. The above measures attempt to limit the damage which can be done, but they cannot entirely prevent attacks.
但是，由于电子邮件地址很容易伪造，因此任何电子邮件响应者都有可能受到攻击，因为他们不限制访问，并且在发出响应之前需要身份验证。上述措施试图限制可能造成的损害，但不能完全防止攻击。
This section describes vulnerabilities inherent in automatically responding to mail. Other vulnerabilities are associated with some mail-based services which automatically respond to email messages, but these are not caused by the fact that the server automatically responds to incoming messages. In general, any network-based service (including those accessed by email) needs to provide security that is sufficient to prevent the service from being used as a means to inappropriately or destructively access the resources that are accessible by the service.
本节介绍自动响应邮件时固有的漏洞。其他漏洞与一些自动响应电子邮件的基于邮件的服务相关，但这些漏洞不是由服务器自动响应传入邮件造成的。一般来说，任何基于网络的服务（包括通过电子邮件访问的服务）都需要提供足够的安全性，以防止该服务被用作不当或破坏性地访问该服务可访问的资源的手段。
It has also been noted that Personal and Group Responders sometimes inappropriately disclose recipients' personal information. This might happen automatically (as when a Group Responder automatically supplies a recipient's personal or mobile telephone number as alternate contact information) or "manually". Automatically-generated information SHOULD NOT include personal information about the recipient which is not already known to, or easily available to, the sender of the subject message. User interfaces which allow recipients to supply response text SHOULD make it clear to the user that this information will be made available not only to local colleagues but also to the entire Internet, including potential attackers.
还注意到，个人和团体响应者有时不适当地披露接收者的个人信息。这可能会自动发生（例如，当组响应者自动提供收件人的个人或移动电话号码作为备用联系信息时）或“手动”。自动生成的信息不应包括收件人的个人信息，这些信息对于主题邮件的发件人来说是未知的或不容易获得的。允许收件人提供响应文本的用户界面应向用户明确，该信息不仅可供本地同事使用，也可供整个互联网（包括潜在攻击者）使用。
This section illustrates how these recommendations might apply to a hypothetical "vacation" program that had the purpose of responding to a single recipient's mail during periods in which that recipient was busy or absent and unable to respond personally. This is intended as illustration only and is not a normative part of this standard.
本节说明了这些建议如何适用于假设的“休假”计划，该计划的目的是在收件人忙碌或缺席且无法亲自回复期间回复单个收件人的邮件。本标准仅用于说明，并非本标准的规范性部分。
The vacation program is a Personal Responder.
假期计划是一个个人响应者。
The vacation program refuses to respond to any message which:
休假计划拒绝回复以下任何消息：
- appears to be spam (for instance, if it has been labelled as advertising by the sender or as potential spam by some intermediary),
- 似乎是垃圾邮件（例如，如果发件人将其标记为广告或某些中介将其标记为潜在垃圾邮件），
- appears to contain a virus (for instance, if it contains an executable attachment),
- 似乎包含病毒（例如，如果它包含可执行附件），
- contains an Auto-Submitted header field,
- 包含自动提交的标题字段，
- has been sent a response within the previous 7 days,
- 已在前7天内收到回复，
- does not contain one of the recipient's addresses in a To, CC, Bcc, Resent-To, Resent-CC, or Resent-Bcc field,
- “收件人”、“抄送”、“密件抄送”、“重新发送至”、“重新发送抄送”或“重新发送密件抄送”字段中不包含收件人的地址之一，
- contains a Precedence field with a value of "list", "junk", or "bulk",
- 包含值为“列表”、“垃圾”或“批量”的优先级字段，
- does not have a Return-Path address, or
- 没有返回路径地址，或
- has a Return-Path address of <>, or a Return-Path address of a form that is frequently used by non-delivery reports.
- 返回路径地址为<>，或非送达报告经常使用的表单的返回路径地址。
The format of the vacation response is as follows:
休假回复的格式如下：
- The From header field is set to a name and email address specified by the user on whose behalf the responses are being sent. (On some systems it may be reasonable to have a default setting for the From field of vacation responses that is based on the user's account name and the domain name of the system.)
- “发件人标头”字段设置为由代表其发送响应的用户指定的名称和电子邮件地址。（在某些系统上，根据用户的帐户名和系统的域名为休假响应的“发件人”字段设置默认值可能是合理的。）
- The Reply-To field is set only if explicitly configured by the user on whose behalf the responses are being sent. For example, a user might direct replies to a secretary or co-worker who has been delegated to handle important matters during his absence.
- 仅当由代表其发送响应的用户明确配置时，才会设置“回复到”字段。例如，用户可以直接向秘书或同事回复，秘书或同事在他不在时被授权处理重要事务。
- The To field contains the address of the recipient of the response, as obtained from the Return-Path field of the subject message.
- “收件人”字段包含从主题消息的“返回路径”字段获得的响应收件人的地址。
- The Date field contains the date and time at which the response was generated.
- 日期字段包含生成响应的日期和时间。
- The Subject field contains Auto: followed by a string chosen by the user on whose behalf the responses are being sent. A default setting of something like "away from my mail" might be appropriate. If the Subject field contains non-ASCII characters these are encoded per [N3.RFC2047].
- “主题”字段包含Auto:，后跟由代表其发送响应的用户选择的字符串。默认设置为“远离我的邮件”可能是合适的。如果主题字段包含非ASCII字符，则根据[N3.RFC2047]对其进行编码。
- The In-Reply-To and References fields are generated from the subject message per [N2.RFC2822].
- 根据[N2.RFC2822]从主题消息生成In Reply To和References字段。
- The Auto-Submitted field has the value "auto-replied".
- “自动提交”字段的值为“自动回复”。
- The message body contains some text specified by the user on whose behalf the response is being sent. A brief summary of the subject message is also included, consisting of From, To, Subject, Date, and a few lines of message text from the subject message. No attachments or non-text bodyparts are included in the response.
- 消息正文包含由代表其发送响应的用户指定的一些文本。还包括主题消息的简要摘要，包括从、到、主题、日期以及主题消息中的几行消息文本。响应中不包含任何附件或非文本正文部分。
The SMTP MAIL FROM address of the message envelope is <>. The RCPT TO address in the message envelope is the address of the user to whom the response is being sent. NOTIFY=NEVER is also set in the RCPT TO line if permitted by the SMTP server.
邮件信封的SMTP邮件发件人地址为<>。消息信封中的RCPT TO address是响应发送到的用户的地址。如果SMTP服务器允许，则在RCPT TO行中也设置NOTIFY=NEVER。
Section 5 of this document defines two new extension mechanisms - new keywords for the Auto-Submitted header field, and new optional parameters for the Auto-Submitted field. If at any point in the future new keywords or parameters are approved (through an IETF Consensus process) it may be appropriate for IANA to create a registry of such keywords or parameters.
本文档第5节定义了两种新的扩展机制—自动提交标题字段的新关键字和自动提交字段的新可选参数。如果在未来的任何时候新的关键字或参数得到批准（通过IETF共识流程），IANA可能适合创建此类关键字或参数的注册表。
In the mid-1990s Jeroen Houttuin of TERENA authored a series of internet-drafts on "Behavior of Mail Based Servers", and in particular, one document on "Answering Servers". While these documents were (to this author's knowledge) never formally published, they provided the first well-reasoned argument (known to this author) as to the best way for such servers to interface with email systems and protocols.
20世纪90年代中期，特里娜的杰伦·霍图因（Jeroen Houttuin）撰写了一系列关于“基于邮件的服务器的行为”的互联网草稿，特别是一份关于“应答服务器”的文档。虽然这些文件（据作者所知）从未正式发布，但它们提供了第一个合理的论据（作者所知），即此类服务器与电子邮件系统和协议接口的最佳方式。
The idea for the Auto-Submitted field comes from the X.400/MHS mail system [I7.X420]. [I8.RFC2156] defined an "Autosubmitted" field for use when gatewaying between X.400 and Internet mail. Jacob Palme wrote an internet-draft defining use of the "Auto-Submitted" field for Internet mail, which made it through Last Call without significant objections, but got stalled in an attempt to resolve non-substantial objections. The definition of Auto-Submitted in this document is derived (i.e., slightly simplified) from the one in that document, with some text stolen outright.
自动提交字段的想法来自于X.400/MHS邮件系统[I7.X420]。[I8.RFC2156]定义了一个“自动提交”字段，用于在X.400和Internet邮件之间进行网关连接时使用。雅各布·帕尔姆（Jacob Palme）撰写了一份互联网草案，定义了互联网邮件“自动提交”字段的使用，该字段在没有重大反对意见的情况下通过了最后一次通话，但在试图解决非实质性反对意见时被搁置。本文件中“自动提交”的定义源自该文件中的定义（即稍微简化），其中一些文本被完全窃取。
Thanks are also due to those who contributed suggestions to this document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield, Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera, Dan Kohn, Bruce Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg, Richard Rognlie, Markus Stumpf, Florian Weimer, and Dan Wing.
感谢为本文件提供建议的人：Russ Allbery、Adam Costello、Ned Freed、Lawrence Greenfield、Arnt Gulbrandsen、Eric Hall、Tony Hansen、Vivek Khera、Dan Kohn、Bruce Lilly、Charles Lindsey、der Mouse、Lyndon Nerenberg、Richard Rognlie、Markus Stumpf、Florian Weimer和Dan Wing。
[N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1.RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[N2.RFC2822]Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[N3.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[N3.RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[N4.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[N4.RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[N5.RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[N6.RFC2234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 22342997年11月。
[N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[N7.RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[N8.RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N8.RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA考虑因素部分的指南”，BCP 26，RFC 2434，1998年10月。
[I1.JARGON] "Sorcerer's apprentice mode", originally from the Jargon file once maintained at MIT-AI and SAIL; now collected at various places on the net. See e.g., http://www.jargon.net/
[I1.行话]“巫师学徒模式”，最初来源于MIT-AI和SAIL保存的行话文件；现在收集在网上的各个地方。参见，例如。，http://www.jargon.net/
[I2.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[I2.RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.
[I3.RFC3798]Hansen，T.和G.Vaudreuil，编辑，“消息处置通知”，RFC 3798，2004年5月。
[I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[I4.RFC2076]Palme，J.，“通用互联网消息头”，RFC2076，1997年2月。
[I5.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, July 1998.
[I5.RFC2369]Neufeld，G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，1998年7月。
[I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[I6.RFC822]Crocker，D.，“ARPA互联网文本消息格式标准”，STD 11，RFC 822，1982年8月。
[I7.X420] CCITT Recommendation X.420 (1992 E). Information technology - Message Handling Systems (MHS): Interpersonal messaging system, 1992.
[I7.X420]CCITT建议X.420（1992 E）。信息技术.信息处理系统（MHS）：人际信息系统，1992。
[I8.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[I8.RFC2156]Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
Author's Address
作者地址
Keith Moore Innovative Computing Laboratory University of Tennessee, Knoxville 1122 Volunteer Blvd, #203 Knoxville, TN 37996-3450
田纳西大学基思穆尔创新计算实验室，诺克斯维尔1122志愿者BLVD，诺克斯维尔203，TN37
EMail: moore@cs.utk.edu
EMail: moore@cs.utk.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。