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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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 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に必要な使用で定義されたアクションを、「拒絶します」。
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トランザクション中に拒否されることを可能にするアクションを「拒否」の定義を更新し、可能な場合は、SMTPトランザクション中に拒否されるメッセージを必要とするように、「ereject」アクションを定義します。
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」アクションは可能な限り「拒否」アクションを置き換えることを目的としています。 「ereject」アクションは、「拒否」に似ていますが、常にプロトコルレベルのメッセージ拒否を好むだろう。
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
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.
「拒否」アクションは、メッセージを破棄し、説明のメッセージと一緒にエンベロープ送信者へのメッセージ気質通知[MDN]を送信しなければならないことを指定ふるいメールフィルタリング言語、当初RFC 3028 [RFC3028]で定義されました、。ふるいメールフィルタリング言語は、RFC 5228 [SIEVE]で更新され、したがって、それが本書の目的で、任意の「拒否」アクションを定義していません。
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トランザクション中にメッセージの拒否を可能にするために、「拒否」アクションの定義を更新し、可能な場合は、SMTPトランザクション中にメッセージの拒否を必要とする新しい「ereject」アクションを定義します。
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.
このドキュメントの重要な目標は、MDNがその非配信のメッセージの送信者に通知送られ、「ジョー・ジョブ」スパムの実行を、犯すために使用されているSieveスクリプトのリスクを軽減することである実際に無実の3分の1に送られ、 -パーティー。オリジナルのふるいは、このようにジョー・ジョブの犠牲者へのジョー・ジョブスパムの洪水に貢献したメッセージを拒否するための開封通知のRFC 3028に必要な使用で定義されたアクションを、「拒絶します」。プロトコルレベルでメッセージを拒否することで、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.
メール転送エージェント（MTA）、メール配送エージェント（MDA）、およびメールユーザエージェント（MUA）：この文書は、電子メール・スタック内のポイントを変更することで、「拒否」/「ereject」を使用する方法について説明します。これらの環境の包括的な議論については[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].
生成開封通知プロトコルレベル拒否の利点のリスクを強調さらなる議論は[ジョー-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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Conventions for notations are as in Section 1.1 of RFC 5228 [SIEVE].
表記の規則は、RFC 5228 [SIEVE]のセクション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>
使用法：ereject <理由：文字列>
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]文字列です。メッセージが拒否されたどのようにSieveスクリプトを実行し、メールコンポーネント（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上5XX応答コードを送信することによって、メッセージの配信を拒否ローカルメール転送プロトコル（LMTP）LMTP]。詳細は、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.エンベロープ送信者に配信不能レポートを送信する（[REPORT] [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"];
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文字を許可しないことに注意してください。非US-ACSII文字は「理由」列に表示された場合は、クライアントとサーバが非-US-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.)
実装は、サーバーによって承認されたことには複数のRCPTを持っているSMTP経由でメッセージを受信し、少なくとも一つではなく、それらのすべてが拒否をふるい「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]および[レポート]の要件に従わなければなりません。 [DSN]で定義されたアクション値フィールド、2.3.3項では、値を含まなければならない「失敗しました」。配信不能レポートの人間が読める部分が「ereject」アクションから「理由」の文字列が含まれなければならないとメッセージは、メールフィルタによって拒否されたことが明らかに元の送信者に警告する追加のテキストを含める必要があります。次のように報告書のこの部分が表示されることがあります：
------------------------------------------------------------
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!
------------------------------------------------------------
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で「拒否」アクションの定義を更新し、[SIEVE]へのオプションの拡張機能です。
Usage: reject <reason: string>
使用方法：<理由：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参照）。しかし、実装は、以下の条件がすべて満たされている場合に限り、（セクション2.5に詳述されるように）SMTP / LMTPプロトコルを介して配信を拒否することができます。
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およびクライアントとサーバーの両方のサポートが含まれており、UTF-8の応答を送信するためのSMTP / LMTP拡張の使用を交渉のみで構成されています。
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プロトコルが使用されている、メッセージが複数の受信者を有し、それらの全ては、（ふるいが使用されているか否か）メッセージの配信を拒否しました。
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. . ; }
サイズ場合：100K上{テキストを拒否：あなたのメッセージは大きすぎます。あなたは私に大きな添付ファイルを送信する場合は、公共のウェブサイト上で、それを入れて、私にURLを送信します。 。 ; }
(Pretend that the "reason" string above contains some non-US-ACSII text.)
（「理由」の文字列は、上記のいくつかの非US-ASCIIテキストが含まれていることをふりをします。）
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.
「拒否」アクションは、それが受信者によって拒否されたことを説明し、「拒否」の形でそれを包む、（またはリターンパス）MAIL FROMアドレスで指定された封筒の送信者に受信したメッセージを再送信します。
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! . ; }
ヘッダがあれば：「coyote@desert.example.org」「から」が含ま{テキストを拒否：私はあなたからのメールを取っていない、と私はどちらか、あなたのbirdseedをしたくありません！ 。 ; }
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:
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.
実装は静かに、これはスクリプトの所有者が期待できない行動の不快な変化をもたらす可能性があるため、Sieveスクリプト内のアクションに「ereject」アクションを「拒否」にアップグレードしてはなりません。
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.
一般的な拒否のオプションを提示し、Sieveスクリプトの出力を生成するユーザインタフェースは、スクリプトの所有者のための混乱の変化を作成しないそうする限り、「ereject」アクションに「拒否」を生成するから切り替えることができます。
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」アクションにも同様に適用されます。このセクションでアクションを「拒否」へのすべての参照は、「ereject」アクションに置き換えることができます。
A "reject" action cancels the implicit keep.
「拒否」アクションは暗黙のキープをキャンセルします。
Implementations MUST prohibit the execution of more than one "reject" in a Sieve script.
実装はSieveスクリプトで複数の「拒否」の実行を禁止しなければなりません。
"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".
「拒否」[VACATION]アクション「休暇」と互換性がなければなりません。実装は、このような、「のfileinto」を「維持」、および「リダイレクト」などのメール配信を引き起こす行為、と「拒否」の使用を許可することはお勧めできません。
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 /開封通知の内容には何の影響もあってはなりません。
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"];
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.
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の例では、DATAコマンドへの応答は以下のようになります。
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」はすぐに拒否の理由を開示することを望まない場合（例えば、それはスパムメールを検出したこと）、それは最初の試みで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.
以下のセクションでは、この文書で指定されたSieve拡張のために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」アクションを追加します。拒否は可能な限り早期に（例えば、プロトコルレベルで）起こるべきし、それが非US-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]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[ENHANCED-CODES]、RFC 2034、1996年10月 "拡張エラーコードを返すためのSMTPサービス拡張"、N.、フリード。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[REPORT]ヴォードルイユ、G.、「メールシステム管理メッセージの報告のための複合/レポートのコンテンツタイプ」、RFC 3462、2003年1月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.およびT.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年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.
[VACATION]ショーウォルター監督、T.およびN.フリード、 "ふるいメールフィルタリング：休暇延長"、RFC 5230、2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[EMAIL-ARCH]クロッカー、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>.
[ジョー-DOS]フレイ、S.、シルベストリ、I.、およびG. Ollman、 "メール配信不能通知攻撃"、2004年4月、<のhttp：// www.techzoom.net/papers/ mail_non_delivery_notice_attacks_2004.pdf>。
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[RFC3028]ショーウォルター監督、T.、 "ふるい：メールフィルタ言語"、RFC 3028、2001年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]ムーア、K.、 "電子メールへの自動応答のための提言"、RFC 3834、2004年8月。
[SPAMTEST] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.
[はspamtest] Daboo、C.、 "ふるいメールフィルタリング：はspamtestとVirustest拡張機能"、RFC 5235、2008年1月。
[UTF8-RESP] Melnikov, A., "SMTP Language Extension", Work in Progress, June 2007.
[UTF8-RESP]メルニコフ、A.、 "SMTP言語拡張"、進歩、2007年6月に作業。
Appendix A. Acknowledgements
付録A.謝辞
Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, Mark E. Mallett, Philip Guenther, Michael Haardt, and Randy Gellens for comments and corrections.
コメントと修正のためのネッド・フリード、サイラスDaboo、ARNT Gulbrandsenの、クリスティン・ヒューブナー、マーク・E.マレット、フィリップ・ギュンター、マイケルHaardt、およびランディGellensに感謝します。
The authors gratefully acknowledge the extensive work of Tim Showalter as the author of the RFC 3028, which originally defined the "reject" action.
作者は感謝して、もともと「拒否」アクションを定義したRFC 3028、の著者としてティム・ショーウォルター監督の大規模な作品を認めます。
Appendix B. Contributors
付録B.協力者
Matthew Elvey The Elvey Partnership, LLC 1819 Polk Street, Suite 133 San Francisco, CA 94109 USA
マシュー・Elveyザ・Elveyパートナーシップ、LLC 1819ポークストリート、スイート133サンフランシスコ、CA 94109 USA
EMail: matthew@elvey.com
メールアドレス：matthew@elvey.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Author's Address
著者のアドレス
Aaron Stone (editor) Serendipity 260 El Verano Ave Palo Alto, CA 94306 USA
アーロン・ストーン（エディタ）セレンディピティ260夏アベニューパロアルト、CA 94306 USA
EMail: aaron@serendipity.palo-alto.ca.us
メールアドレス：aaron@serendipity.palo-alto.ca.us