Network Working Group A. Stone, Ed.
Request for Comments: 5429 Serendipity
Obsoletes: 3028 March 2009
Updates: 5228
Category: Standards Track
Network Working Group A. Stone, Ed.
Request for Comments: 5429 Serendipity
Obsoletes: 3028 March 2009
Updates: 5228
Category: Standards Track
Sieve Email Filtering: Reject and Extended Reject Extensions
筛选电子邮件筛选：拒绝和扩展拒绝扩展
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.
此备忘录更新了最初在RFC 3028中定义的筛邮件过滤语言“拒绝”扩展的定义。
A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with
“Joe job”是一种伪造的垃圾邮件，看起来像来自无辜的一方，然后通常会被自动跳转、邮件处理通知（MDN）和带有
complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.
抱怨。RFC 3028中定义的原始筛选“拒绝”操作要求使用MDN拒绝消息，从而导致Joe job垃圾邮件泛滥到Joe job的受害者。
This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.
此备忘录更新了“拒绝”操作的定义，以允许在SMTP事务期间拒绝邮件，并定义了“ereject”操作，以要求在SMTP事务期间拒绝邮件（如果可能）。
The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection.
“ereject”操作旨在尽可能取代“reject”操作。“ereject”操作类似于“reject”，但总是倾向于协议级消息拒绝。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Sieve "reject" and "ereject" Extensions . . . . . . . . . . . 4
2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level . 5
2.1.2. Rejecting a Message by Sending a DSN . . . . . . . . . 5
2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Rejecting a Message by Sending an MDN . . . . . . . . 7
2.3. Silent Upgrade from "reject" to "ereject" . . . . . . . . 8
2.4. Compatibility with Other Actions . . . . . . . . . . . . . 9
2.5. Details of Protocol-Level Refusal . . . . . . . . . . . . 9
3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. "reject" Extension Registration . . . . . . . . . . . . . 11
5.2. "ereject" Extension Registration . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Sieve "reject" and "ereject" Extensions . . . . . . . . . . . 4
2.1. Action ereject . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Rejecting a Message at the SMTP/LMTP Protocol Level . 5
2.1.2. Rejecting a Message by Sending a DSN . . . . . . . . . 5
2.2. Action reject . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Rejecting a Message by Sending an MDN . . . . . . . . 7
2.3. Silent Upgrade from "reject" to "ereject" . . . . . . . . 8
2.4. Compatibility with Other Actions . . . . . . . . . . . . . 9
2.5. Details of Protocol-Level Refusal . . . . . . . . . . . . 9
3. Changes from RFC 3028 . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. "reject" Extension Registration . . . . . . . . . . . . . 11
5.2. "ereject" Extension Registration . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14
The Sieve mail filtering language, as originally defined in RFC 3028 [RFC3028], specified that the "reject" action shall discard a message and send a Message Disposition Notification [MDN] to the envelope sender along with an explanatory message. The Sieve mail filtering language, as updated in RFC 5228 [SIEVE], does not define any "reject" action, hence that is the purpose of this document.
最初在RFC 3028[RFC3028]中定义的筛选邮件过滤语言规定，“拒绝”操作应丢弃邮件，并向信封发送者发送邮件处置通知[MDN]以及解释性邮件。RFC 5228[筛]中更新的筛邮件过滤语言未定义任何“拒绝”操作，因此这是本文档的目的。
This document updates the definition of the "reject" action to permit refusal of the message during the SMTP transaction, if possible, and defines a new "ereject" action to require refusal of the message during the SMTP transaction, if possible.
本文档更新了“拒绝”操作的定义，以允许在SMTP事务期间拒绝邮件（如果可能），并定义了新的“ereject”操作，以要求在SMTP事务期间拒绝邮件（如果可能）。
An important goal of this document is to reduce the risk of Sieve scripts being used to perpetrate "Joe-job" spam runs, where the MDN is sent notifying the sender of a message of its non-delivery is in fact sent to an innocent third-party. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. By rejecting the message at the protocol level, it is less likely that an MDN will be needed, and thus less likely that an MDN will be misdirected at an innocent third-party.
本文档的一个重要目标是降低筛脚本被用于实施“Joe job”垃圾邮件运行的风险，在这种情况下，发送MDN通知发件人其未送达的消息实际上是发送给无辜的第三方。RFC 3028中定义的原始筛选“拒绝”操作要求使用MDN拒绝消息，从而导致Joe job垃圾邮件泛滥到Joe job的受害者。通过在协议级别拒绝消息，就不太可能需要MDN，从而也就不太可能将MDN错误地指向无辜的第三方。
Implementations are further encouraged to use spam-detection systems to determine the level of risk associated with sending an MDN, and this document allows implementations to silently drop the MDN if the rejected message is deemed likely to be spam.
进一步鼓励实现使用垃圾邮件检测系统来确定与发送MDN相关的风险级别，并且本文档允许实现在被拒绝的消息被认为可能是垃圾邮件时自动删除MDN。
This document also describes how to use "reject"/"ereject" at varying points in the email stack: Mail Transfer Agent (MTA), Mail Delivery Agent (MDA), and Mail User Agent (MUA). See [EMAIL-ARCH] for a comprehensive discussion of these environments.
本文档还描述了如何在电子邮件堆栈中的不同位置使用“拒绝”/“ereject”：邮件传输代理（MTA）、邮件传递代理（MDA）和邮件用户代理（MUA）。有关这些环境的全面讨论，请参见[EMAIL-ARCH]。
In general, an MDN is generated by an MUA, and can be used to indicate the status of a message with respect to its recipient, while a Delivery Status Notification (DSN) [DSN] is generated by an MTA, and can be used to indicate whether or not a message was received and delivered by the mail system.
通常，MDN由MUA生成，可用于指示邮件相对于其收件人的状态，而传递状态通知（DSN）[DSN]由MTA生成，可用于指示邮件系统是否接收和传递邮件。
Further discussion highlighting the risks of generating MDNs and the benefits of protocol-level refusal can be found in [Joe-DoS].
有关生成MDN的风险和协议级拒绝的好处的进一步讨论，请参见[Joe DoS]。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Conventions for notations are as in Section 1.1 of RFC 5228 [SIEVE].
符号惯例见RFC 5228[筛]第1.1节。
This document does not attempt to define spam or how it should be identified, nor does it attempt to define an email virus or how it should be detected. Implementors are advised to follow best practices and keep abreast of current research in these fields.
本文档不尝试定义垃圾邮件或如何识别垃圾邮件，也不尝试定义电子邮件病毒或如何检测垃圾邮件。建议实施者遵循最佳实践并跟上这些领域的最新研究。
Usage: ereject <reason: string>
Usage: ereject <reason: string>
Sieve implementations that implement the "ereject" action must use the "ereject" capability string.
实现“ereject”操作的筛实现必须使用“ereject”功能字符串。
The "ereject" action cancels the implicit keep and refuses delivery of a message. The "reason" string is a UTF-8 [UTF-8] string specifying the reason for refusal. How a message is refused depends on the capabilities of the mail component (MDA or MTA) executing the Sieve script. The Sieve interpreter MUST carry out one of the following actions (listed in order from most to least preferred), MUST carry out the most preferable action possible, and MUST fall back to lesser actions if a preferred action fails.
“ereject”操作取消隐式保留并拒绝传递消息。“原因”字符串是指定拒绝原因的UTF-8[UTF-8]字符串。邮件被拒绝的方式取决于执行筛选脚本的邮件组件（MDA或MTA）的功能。筛解释器必须执行以下操作之一（按从最优先到最不优先的顺序列出），必须执行可能的最优先操作，如果首选操作失败，必须返回到较小的操作。
1. Refuse message delivery by sending a 5XX response code over SMTP [SMTP] or Local Mail Transfer Protocol (LMTP) [LMTP]. See Section 2.1.1 for more details.
1. 通过SMTP[SMTP]或本地邮件传输协议（LMTP）[LMTP]发送5XX响应代码来拒绝邮件传递。详见第2.1.1节。
2. Send a non-delivery report to the envelope sender ([REPORT] [DSN]), unless the envelope sender address is determined to be a forged or otherwise invalid address.
2. 向信封寄件人发送未送达报告（[报告][DSN]），除非信封寄件人地址被确定为伪造或其他无效地址。
Note that the determination of whether or not an envelope sender is a forgery may be performed by site-specific and implementation-specific heuristic techniques, such as "return-path verification", details of which are outside the scope of this document. Implementations SHOULD log instances when a non-delivery report is not sent and the reason for not sending the report (e.g., content was spam, return-path invalid, etc.).
注意，可以通过特定于站点和特定于实现的启发式技术（例如“返回路径验证”）来确定信封发送者是否是伪造的，其细节不在本文档的范围内。未发送未送达报告时，实施应记录实例以及未发送报告的原因（例如，内容为垃圾邮件、返回路径无效等）。
The "ereject" action MUST NOT be available in environments that do not support protocol-level rejection, e.g., an MUA, and MUST be available in all other environments that support the "reject" action.
“ereject”操作不得在不支持协议级拒绝的环境中可用，例如MUA，并且必须在支持“拒绝”操作的所有其他环境中可用。
Example: require ["ereject"];
示例：要求[“ereject”]；
if address "from" "someone@example.com" {
ereject "I no longer accept mail from this address";
}
if address "from" "someone@example.com" {
ereject "I no longer accept mail from this address";
}
Sieve implementations that are able to reject messages at the SMTP/ LMTP level MUST do so and SHOULD use the 550 response code. Note that if a message is arriving over SMTP and has multiple recipients, some of whom have accepted the message, Section 2.1.2 defines how to reject such a message.
能够在SMTP/LMTP级别拒绝邮件的筛选实现必须这样做，并且应该使用550响应代码。请注意，如果邮件通过SMTP到达并且有多个收件人，其中一些收件人已接受邮件，则第2.1.2节定义了如何拒绝此类邮件。
The risk that these actions will generate blowback spam are minimized but cannot be eliminated completely even in the case of "ereject", so caution is advised when using these actions to deal with messages determined to be spam.
这些操作将产生反作用垃圾邮件的风险降至最低，但即使在“ereject”的情况下也无法完全消除，因此在使用这些操作处理确定为垃圾邮件的邮件时，建议谨慎。
Note that SMTP [SMTP] does not allow non-US-ACSII characters in the SMTP response text. If non-US-ACSII characters appear in the "reason" string, they can be sent at the protocol level if and only if the client and the server use an SMTP extension that allows for transmission of non-US-ACSII reply text. (One example of such an SMTP extension is described in [UTF8-RESP].) In the absence of such an SMTP extension, the Sieve engine MUST replace any "reason" string being sent at the protocol level and containing non-US-ACSII characters with an implementation-defined US-ACSII-only string.
请注意，SMTP[SMTP]不允许在SMTP响应文本中使用非US ACSII字符。如果“原因”字符串中出现非美国ACSII字符，则只有当且仅当客户端和服务器使用允许传输非美国ACSII回复文本的SMTP扩展时，才能在协议级别发送这些字符。（此类SMTP扩展的一个示例在[UTF8-RESP]中进行了描述。）在没有此类SMTP扩展的情况下，筛选引擎必须将在协议级别发送且包含非US ACSII字符的任何“原因”字符串替换为实现定义的US ACSII纯字符串。
Users who don't like this behavior should consider using the "reject" action described in Section 2.2, if available.
不喜欢这种行为的用户应该考虑使用第2.2节中描述的“拒绝”动作，如果可用的话。
See Section 2.5 for the detailed instructions about performing protocol-level rejection.
有关执行协议级拒绝的详细说明，请参见第2.5节。
An implementation may receive a message via SMTP that has more than one RCPT TO that has been accepted by the server, and at least one but not all of them are refusing delivery (whether the refusal is caused by a Sieve "ereject" action or for some other reason). In this case, the server MUST accept the message and generate DSNs for all recipients that are refusing it. Note that this exception does not apply to LMTP, as LMTP is able to reject messages on a per-recipient basis. (However, the LMTP client may then have no choice but to generate a DSN to report the error, which may result in blowback spam.)
一个实现可能通过SMTP接收到一条消息，该消息包含多个已被服务器接受的RCPT TO，并且至少有一个（但不是全部）拒绝传递（无论拒绝是由筛选“ereject”操作或其他原因引起的）。在这种情况下，服务器必须接受邮件并为拒绝邮件的所有收件人生成DSN。请注意，此例外情况不适用于LMTP，因为LMTP能够根据每个收件人拒绝邮件。（但是，LMTP客户端可能别无选择，只能生成DSN以报告错误，这可能会导致反吹垃圾邮件。）
Note that according to [DSN], Delivery Status Notifications MUST NOT be generated if the MAIL FROM (or Return-Path) is empty.
请注意，根据[DSN]，如果来自（或返回路径）的邮件为空，则不得生成传递状态通知。
The DSN message MUST follow the requirements of [DSN] and [REPORT]. The action-value field defined in [DSN], Section 2.3.3, MUST contain the value "failed". The human-readable portion of the non-delivery report MUST contain the "reason" string from the "ereject" action and SHOULD contain additional text alerting the apparent original sender that the message was refused by an email filter. This part of the report might appear as follows:
DSN消息必须符合[DSN]和[REPORT]的要求。[DSN]第2.3.3节中定义的操作值字段必须包含值“失败”。未送达报告的可读部分必须包含来自“ereject”操作的“reason”字符串，并应包含其他文本，提醒明显的原始发件人邮件已被电子邮件筛选器拒绝。报告的这一部分可能如下所示：
------------------------------------------------------------
Your message was refused by the recipient's mail filtering program.
The reason given is as follows:
------------------------------------------------------------
Your message was refused by the recipient's mail filtering program.
The reason given is as follows:
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
This section updates the definition of the "reject" action in Section 4.1 of RFC 3028 [RFC3028] and is an optional extension to [SIEVE].
本节更新了RFC 3028[RFC3028]第4.1节中“拒绝”操作的定义，是[SIFE]的可选扩展。
Usage: reject <reason: string>
Usage: reject <reason: string>
Sieve implementations that implement the "reject" action must use the "reject" capability string.
实现“拒绝”操作的筛实现必须使用“拒绝”功能字符串。
The "reject" action cancels the implicit keep and refuses delivery of a message. The "reason" string is a UTF-8 [UTF-8] string specifying the reason for refusal. Unlike the "ereject" action described above, this action would always favor preserving the exact text of the refusal reason. Typically, the "reject" action refuses delivery of a message by sending back an MDN to the sender (see Section 2.2.1). However, implementations MAY refuse delivery over SMTP/LMTP protocol (as detailed in Section 2.5), if and only if all of the following conditions are true:
“拒绝”操作取消隐式保留并拒绝传递消息。“原因”字符串是指定拒绝原因的UTF-8[UTF-8]字符串。与上述“ereject”操作不同，此操作始终有利于保留拒绝原因的确切文本。通常，“拒绝”操作通过向发件人发回MDN来拒绝邮件的传递（参见第2.2.1节）。但是，如果且仅当以下所有条件均为真时，实施可能会拒绝通过SMTP/LMTP协议进行传递（详见第2.5节）：
1. The "reason" string consists of only US-ASCII characters or The "reason" string contains non-US-ASCII and both the client and server support and negotiate use of an SMTP/LMTP extension for sending UTF-8 responses.
1. “原因”字符串仅由US-ASCII字符组成，或“原因”字符串包含非US ASCII字符，客户端和服务器都支持并协商使用SMTP/LMTP扩展来发送UTF-8响应。
2. LMTP protocol is used or SMTP protocol is used and the message has a single recipient or SMTP protocol is used, the message has multiple recipients, and all of them refused message delivery (whether or not Sieve is being used).
2. 使用LMTP协议或SMTP协议，并且邮件只有一个收件人，或者使用SMTP协议，邮件有多个收件人，并且所有收件人都拒绝邮件传递（无论是否正在使用SIVE）。
Example: require ["reject"];
示例：要求[“拒绝”]；
if size :over 100K {
reject text:
Your message is too big. If you want to send me a big attachment,
put it on a public web site and send me a URL.
.
;
}
if size :over 100K {
reject text:
Your message is too big. If you want to send me a big attachment,
put it on a public web site and send me a URL.
.
;
}
(Pretend that the "reason" string above contains some non-US-ACSII text.)
（假设上面的“原因”字符串包含一些非US ACSII文本。）
Implementations may use techniques as described in Section 2.1 to determine if a non-delivery report should not be sent to a forged sender. Implementations SHOULD log instances when a non-delivery report is not sent and the reason for not sending the report.
实施可以使用第2.1节中描述的技术来确定是否不应将未送达报告发送给伪造的发送者。实施应记录未发送未送达报告时的实例以及未发送报告的原因。
The "reject" action resends the received message to the envelope sender specified by the MAIL FROM (or Return-Path) address, wrapping it in a "reject" form, explaining that it was rejected by the recipient.
“拒绝”操作会将收到的邮件重新发送到邮件发件人（或返回路径）地址指定的信封发件人，并将其包装为“拒绝”表单，说明收件人拒绝了该邮件。
Note that according to [MDN], Message Disposition Notifications MUST NOT be generated if the MAIL FROM (or Return-Path) is empty.
请注意，根据[MDN]，如果邮件发件人（或返回路径）为空，则不得生成邮件处置通知。
A reject message MUST take the form of a failure MDN as specified by [MDN]. The human-readable portion of the message, the first component of the MDN, contains the human-readable message describing the error, and it SHOULD contain additional text alerting the apparent original sender that mail was refused by an email filter.
拒绝消息必须采用[MDN]指定的故障MDN形式。消息的人类可读部分（MDN的第一个组件）包含描述错误的人类可读消息，并且应该包含额外的文本，提醒明显的原始发件人邮件已被电子邮件筛选器拒绝。
The MDN disposition-field as defined in the MDN specification MUST be "deleted" and MUST have the "MDN-sent-automatically" and "automatic-action" modes set (see Section 3.2.6 of [MDN]).
MDN规范中定义的MDN处置字段必须“删除”，并且必须设置“自动发送MDN”和“自动操作”模式（见[MDN]第3.2.6节）。
In the following script, a message is rejected and returned to the sender.
在下面的脚本中，消息被拒绝并返回给发件人。
Example: require ["reject"];
示例：要求[“拒绝”]；
if header :contains "from" "coyote@desert.example.org" {
reject text:
I am not taking mail from you, and I don't
want your birdseed, either!
.
;
}
if header :contains "from" "coyote@desert.example.org" {
reject text:
I am not taking mail from you, and I don't
want your birdseed, either!
.
;
}
For this script, the first part of the MDN might appear as follows:
对于此脚本，MDN的第一部分可能如下所示：
------------------------------------------------------------
The message was refused by the recipient's mail filtering program.
The reason given was as follows:
------------------------------------------------------------
The message was refused by the recipient's mail filtering program.
The reason given was as follows:
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
Implementations MUST NOT silently upgrade "reject" actions to "ereject" actions in a Sieve script because this might lead to unpleasant changes of behavior not expected by the script owner.
实现不能将筛选脚本中的“拒绝”操作静默升级为“删除”操作，因为这可能会导致脚本所有者不期望的令人不快的行为更改。
User interfaces that present a generic rejection option, and generate Sieve script output, MAY switch from generating "reject" to "ereject" actions, so long as doing so does not create a confusing change for the script owner.
提供通用拒绝选项并生成筛选脚本输出的用户界面可以从生成“拒绝”操作切换到“eject”操作，只要这样做不会给脚本所有者造成混乱的更改。
Script generators SHOULD ensure that a rejection action being executed as a result of an anti-spam/anti-virus positive test be done using the "ereject" action, as it is more suitable for such rejections.
脚本生成器应确保由于反垃圾邮件/反病毒阳性测试而执行的拒绝操作使用“ereject”操作，因为它更适合此类拒绝。
Script generators MAY automatically upgrade scripts that previously used the "reject" action for anti-spam/anti-virus related rejections. Note that such generators MUST make sure that the target environment can support the "ereject" action.
脚本生成器可以自动升级以前使用“拒绝”操作进行反垃圾邮件/反病毒相关拒绝的脚本。请注意，此类生成器必须确保目标环境能够支持“ereject”操作。
This section applies equally to "reject" and "ereject" actions. All references to the "reject" action in this section can be replaced with the "ereject" action.
本节同样适用于“拒绝”和“删除”操作。本节中对“拒绝”操作的所有引用都可以替换为“ereject”操作。
A "reject" action cancels the implicit keep.
“拒绝”操作取消隐式保留。
Implementations MUST prohibit the execution of more than one "reject" in a Sieve script.
实现必须禁止在筛选脚本中执行多个“拒绝”。
"reject" MUST be incompatible with the "vacation" [VACATION] action. It is NOT RECOMMENDED that implementations permit the use of "reject" with actions that cause mail delivery, such as "keep", "fileinto", and "redirect".
“拒绝”必须与“休假”[休假]操作不兼容。不建议实现允许将“拒绝”与导致邮件传递的操作（如“保留”、“文件导入”和“重定向”）一起使用。
Making "reject" compatible with actions that cause mail delivery violates the RFC 5321 [SMTP] principle that a message is either delivered or bounced back to the sender. So bouncing a message back (rejecting) and delivering it will make the sender believe that the message was not delivered.
使“拒绝”与导致邮件传递的操作兼容违反了RFC 5321[SMTP]原则，即邮件要么被传递，要么被退回给发件人。因此，将邮件退回（拒绝）并发送会使发件人认为邮件未发送。
However, there are existing laws requiring certain organizations to archive all received messages, even the rejected ones. Also, it can be quite useful to save copies of rejected messages for later analysis.
然而，现有法律要求某些组织归档所有收到的邮件，甚至是被拒绝的邮件。此外，保存被拒绝消息的副本以供以后分析也是非常有用的。
Any action that would modify the message body will not have an effect on the body of any message refused by "reject" using an SMTP response code and MUST NOT have any effect on the content of generated DSN/ MDNs.
任何修改邮件正文的操作都不会对使用SMTP响应代码被“拒绝”拒绝的任何邮件正文产生影响，并且不得对生成的DSN/MDN的内容产生任何影响。
If the "reason" string consists of multiple CRLF separated lines, then the reason text MUST be returned as a multiline SMTP/LMTP response, per Section 4.2.1 of [SMTP]. Any line MUST NOT exceed the SMTP limit on the maximal line length. To make the "reason" string conform to any such limits, the server MAY insert CRLFs and turn the response into a multiline response.
如果“原因”字符串由多个CRLF分隔行组成，则根据[SMTP]第4.2.1节，原因文本必须作为多行SMTP/LMTP响应返回。任何行都不得超过最大行长度的SMTP限制。为了使“原因”字符串符合任何此类限制，服务器可以插入CRLF并将响应转换为多行响应。
In the following script (which assumes support for the "spamtest" [SPAMTEST] and "fileinto" extensions), messages that test highly positive for spam are refused.
在下面的脚本（假定支持“spamtest”[spamtest]和“fileinto”扩展）中，对垃圾邮件测试为高度阳性的消息将被拒绝。
Example: require ["ereject", "spamtest", "fileinto", "comparator-i;ascii-numeric"];
示例：要求[“ereject”、“spamtest”、“fileinto”、“comparator-i；ascii数字”]；
if spamtest :value "ge"
:comparator "i;ascii-numeric" "6" {
ereject text:
AntiSpam engine thinks your message is spam.
It is therefore being refused.
Please call 1-900-PAY-US if you want to reach us.
.
;
} elsif spamtest :value "ge"
:comparator "i;ascii-numeric" "4" {
fileinto "Suspect";
}
if spamtest :value "ge"
:comparator "i;ascii-numeric" "6" {
ereject text:
AntiSpam engine thinks your message is spam.
It is therefore being refused.
Please call 1-900-PAY-US if you want to reach us.
.
;
} elsif spamtest :value "ge"
:comparator "i;ascii-numeric" "4" {
fileinto "Suspect";
}
The following excerpt from an SMTP session shows it in action.
下面是SMTP会话的摘录，显示了它的作用。
...
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
C: .
S: 550-AntiSpam engine thinks your message is spam.
S: 550-It is therefore being refused.
S: 550 Please call 1-900-PAY-US if you want to reach us.
...
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
C: .
S: 550-AntiSpam engine thinks your message is spam.
S: 550-It is therefore being refused.
S: 550 Please call 1-900-PAY-US if you want to reach us.
If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES], it MUST prepend an appropriate Enhanced Error Code to the "reason" text. Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. With an Enhanced Error Code, the response to a DATA command in the SMTP example below will look like:
如果SMTP/LMTP服务器支持RFC 2034[ENHANCED-CODES]，则必须在“原因”文本前添加适当的增强错误代码。建议使用增强的错误代码5.7.1或更通用的5.7.0。对于增强的错误代码，下面SMTP示例中对数据命令的响应如下所示：
S: 550-5.7.1 AntiSpam engine thinks your message is spam.
S: 550-5.7.1 It is therefore being refused.
S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us.
S: 550-5.7.1 AntiSpam engine thinks your message is spam.
S: 550-5.7.1 It is therefore being refused.
S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us.
if the server selected "5.7.1" as appropriate.
如果服务器根据需要选择“5.7.1”。
If a Sieve implementation that supports "ereject" does not wish to immediately disclose the reason for rejection (for example, that it detected spam), it may delay immediately sending of the 550 error code by sending a 4XX error code on the first attempt to receive the message.
如果支持“ereject”的Sieve实现不希望立即披露拒绝的原因（例如，它检测到垃圾邮件），它可能会在第一次尝试接收消息时发送4XX错误代码，从而延迟立即发送550错误代码。
Clarified that the "reject" action cancels the implicit keep. Extended the list of allowable actions on "reject" to include protocol-level message rejection.
阐明“拒绝”操作取消隐式保留。扩展了“拒绝”的允许操作列表，以包括协议级消息拒绝。
Added the "ereject" action that is similar to "reject", but will always favor protocol-level message rejection.
添加了类似于“拒绝”的“ereject”操作，但始终支持协议级消息拒绝。
The introduction to this document discusses why rejecting messages before delivery is better than accepting and bouncing them.
本文档的导言讨论了为什么在传递之前拒绝邮件要比接受并跳转邮件好。
While the details of techniques that can be used to determine when to silently drop a non-delivery report are outside the scope of this document, the explicit permission this document gives to take such action may enable denial-of-service situations. Techniques such as spam-checking, return-path verification, and others, can and do have false-positives. Care should be exercised to prevent the loss of legitimate messages by failing to notify the sender of non-delivery.
虽然可用于确定何时以静默方式删除未送达报告的技术细节不在本文档范围内，但本文档授予的采取此类操作的明确权限可能会导致拒绝服务情况。垃圾邮件检查、返回路径验证等技术可能也确实存在误报。应注意避免因未通知发件人未送达而丢失合法邮件。
Security issues associated with email auto-responders are fully discussed in the Security Considerations section of [RFC3834]. This document is not believed to introduce any additional security considerations in this general area.
[RFC3834]的安全注意事项部分详细讨论了与电子邮件自动应答器相关的安全问题。本文件不会在这一一般领域引入任何额外的安全注意事项。
The "ereject" extension does not raise any other security considerations that are not already present in the base [SIEVE] specification, and these issues are discussed in [SIEVE].
“ereject”扩展不会引起任何其他安全注意事项，而这些安全注意事项在基本[SIEVE]规范中尚未出现，这些问题将在[SIEVE]中讨论。
The following section provides the IANA registrations for the Sieve extensions specified in this document.
以下章节提供了本文件中规定的筛网扩展的IANA注册。
IANA is requested to update the registration for the Sieve "reject" extension as detailed below:
请IANA更新筛“拒绝”扩展的注册，详情如下：
Capability name: reject Description: adds the "reject" action for refusing delivery of a message. The exact reason for refusal is conveyed back to the client. RFC number: RFC 5429 Contact address: the Sieve discussion list <ietf-mta-filters@imc.org>
功能名称：拒绝描述：添加拒绝消息传递的“拒绝”操作。拒绝的确切原因会反馈给客户。RFC编号：RFC 5429联系地址：筛讨论列表<ietf mta-filters@imc.org>
IANA is requested to replace the preliminary registration of the Sieve refuse extension with the following registration:
IANA被要求用以下登记取代筛渣延期的初步登记：
Capability name: ereject Description: adds the "ereject" action for refusing delivery of a message. The refusal should happen as early as possible (e.g., at the protocol level) and might not preserve the exact reason for refusal if it contains non-US-ASCII text. RFC number: RFC 5429 Contact address: the Sieve discussion list <ietf-mta-filters@imc.org>
功能名称：ereject描述：添加拒绝消息传递的“ereject”操作。拒绝应尽早发生（例如，在协议级别），如果拒绝包含非美国ASCII文本，则可能不会保留拒绝的确切原因。RFC编号：RFC 5429联系地址：筛讨论列表<ietf mta-filters@imc.org>
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[ENHANCED-CODES]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LMTP] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[LMTP]迈尔斯，J.，“本地邮件传输协议”，RFC 2033，1996年10月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[MDN]Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[报告]Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.和T.Showalter，“筛：电子邮件过滤语言”，RFC 52282008年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[假期]Showalter，T.和N.Freed，“筛选电子邮件过滤：假期延长”，RFC 5230，2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[EMAIL-ARCH]Crocker，D.，“互联网邮件架构”，正在进行的工作，2008年10月。
[Joe-DoS] Frei, S., Silvestri, I., and G. Ollman, "Mail Non-Delivery Notice Attacks", April 2004, <http:// www.techzoom.net/papers/ mail_non_delivery_notice_attacks_2004.pdf>.
[Joe DoS]Frei，S.，Silvestri，I.，和G.Ollman，“邮件未送达通知攻击”，2004年4月，<http://www.techzoom.net/papers/Mail\u Non\u Delivery\u Notice\u Attacks\u 2004.pdf>。
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[RFC3028]Showalter，T.，“筛选：邮件过滤语言”，RFC3028，2001年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 38342004年8月。
[SPAMTEST] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.
[SPAMTEST]Daboo，C.，“筛选电子邮件过滤：SPAMTEST和Virustest扩展”，RFC 52352008年1月。
[UTF8-RESP] Melnikov, A., "SMTP Language Extension", Work in Progress, June 2007.
[UTF8-RESP]Melnikov，A.，“SMTP语言扩展”，正在进行的工作，2007年6月。
Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens for comments and corrections.
感谢Ned Freed、Cyrus Daboo、Arnt Gulbrandsen、Kristin Hubner、Mark E.Mallett、Philip Guenther、Michael Haardt和Randy Gellens的评论和更正。
The authors gratefully acknowledge the extensive work of Tim Showalter as the author of the RFC 3028, which originally defined the "reject" action.
作者感谢Tim Showalter作为RFC 3028的作者所做的大量工作，RFC 3028最初定义了“拒绝”行为。
Matthew Elvey The Elvey Partnership, LLC 1819 Polk Street, Suite 133 San Francisco, CA 94109 USA
马修埃尔维的埃尔维伙伴关系，LLC 1819波尔克街，套房133旧金山，CA 94109美国
EMail: matthew@elvey.com
EMail: matthew@elvey.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Author's Address
作者地址
Aaron Stone (editor) Serendipity 260 El Verano Ave Palo Alto, CA 94306 USA
艾伦·斯通（编辑）美国加利福尼亚州帕洛阿尔托韦拉诺大街260号《意外发现》94306
EMail: aaron@serendipity.palo-alto.ca.us
EMail: aaron@serendipity.palo-alto.ca.us