[要約] RFC 5429は、Sieveメールフィルタリングの「Reject」と「Extended Reject」拡張機能に関する規格です。このRFCの目的は、Sieveスクリプトでのメールの拒否と拡張的な拒否を可能にするための仕様を提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.
このメモは、元々RFC 3028で定義されていたSieve Mailフィルタリング言語の定義を「拒否」拡張機能を更新します。
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.
「Joe-Job」は、あたかも無実のパーティーから来たように見えるスパムランであり、その後、自動化されたバウンス、メッセージ処分通知（MDNS）、および苦情を伴う個人的なメッセージによって一般的に浸水します。RFC 3028で定義された元のふるいは、メッセージを拒否するためにMDNを使用する必要があるため、ジョージョブの犠牲者にジョージョブスパムの洪水に貢献しました。
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トランザクション中にメッセージを拒否することを要求する「EREEFR」アクションを定義します。
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.
RFC 3028 [RFC3028]で最初に定義されているように、シーブメールのフィルタリング言語は、「拒否」アクションがメッセージを破棄し、メッセージの気質通知[MDN]をエンベロープ送信者に送信し、説明メッセージとともに指定することを指定しました。RFC 5228 [Sieve]で更新されたSieve Mailフィルタリング言語は、「拒否」アクションを定義していないため、このドキュメントの目的です。
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.
このドキュメントの重要な目標は、「Joe-Job」スパムランを実行するために使用されるふるいスクリプトのリスクを減らすことです。ここでは、MDNが送信者にその非配信のメッセージを通知して、実際には無実の3番目に送信されます-パーティ。RFC 3028で定義された元のふるいは、メッセージを拒否するためにMDNを使用する必要があるため、ジョージョブの犠牲者にジョージョブスパムの洪水に貢献しました。プロトコルレベルでメッセージを拒否することにより、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）について説明します。これらの環境の包括的な議論については、[メールアーチ]を参照してください。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
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>
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]またはローカルメール転送プロトコル（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. Envelope Senderアドレスが偽造またはその他の無効なアドレスであると判断されない限り、封筒送信者（[レポート] [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.).
エンベロープ送信者が偽造であるかどうかの決定は、「リターンパス検証」などのサイト固有の実装固有のヒューリスティックテクニックによって実行される可能性があることに注意してください。その詳細は、このドキュメントの範囲外です。実装は、配送のないレポートが送信されない場合、およびレポートを送信しない理由を記録する必要があります（たとえば、コンテンツはスパム、Return-Path無効など）。
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";
}
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レベルでメッセージを拒否できるSiveの実装は、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拡張の1つの例は、[UTF8-RESP]で説明されています。）このようなSMTP拡張機能がない場合、シーブエンジンはプロトコルレベルで送信され、非US-ACSIIを含む「理由」文字列を置き換える必要があります。実装定義のUS-Acsii-Only文字列を持つ文字。
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.) Note that according to [DSN], Delivery Status Notifications MUST NOT be generated if the MAIL FROM (or Return-Path) is empty.
実装は、SMTPを介して複数のRCPTを搭載したメッセージをサーバーによって受け入れているメッセージを受信する場合があり、少なくとも1つではなく、すべてではありませんが、配信を拒否しています（拒否がふるいの「ereject」アクションによって引き起こされるか、他の理由）。この場合、サーバーはメッセージを受け入れ、それを拒否しているすべての受信者のDSNを生成する必要があります。LMTPはレシピエントごとにメッセージを拒否できるため、この例外はLMTPには適用されないことに注意してください。（ただし、LMTPクライアントは、エラーを報告するためにDSNを生成する以外に選択肢がない場合があります。これにより、ブローバックスパムが発生する可能性があります。）[DSN]によれば、メール（または）からのメールが生成されないことに注意してください。return-path）は空です。
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>
Sieve implementations that implement the "reject" action must use the "reject" capability string.
「拒否」アクションを実装するSiveの実装は、「拒否」機能文字列を使用する必要があります。
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が含まれ、クライアントとサーバーの両方が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プロトコルが使用され、メッセージには複数の受信者があり、それらはすべてメッセージ配信を拒否しました（Sieveが使用されているかどうか）。
Example: require ["reject"];
例：["" rexect "]を要求します。
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-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.
「拒否」アクションは、受信したメッセージを（またはReturn-Path）アドレスからのメールで指定したEnvelope Senderへのメッセージを再送信し、「拒否」フォームに包み、受信者によって拒否されたことを説明します。
Note that according to [MDN], Message Disposition Notifications MUST NOT be generated if the MAIL FROM (or Return-Path) is empty.
[MDN]によれば、メッセージ（またはReturn-Path）からのメールが空である場合、メッセージ処分通知は生成しないでください。
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-Sent-Automatical」および「自動アクション」モードが設定されている必要があります（[MDN]のセクション3.2.6を参照）。
In the following script, a message is rejected and returned to the sender.
次のスクリプトでは、メッセージが拒否され、送信者に返されます。
Example: require ["reject"];
例：["" rexect "]を要求します。
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:
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.
一般的な拒否オプションを提示し、ふるいスクリプト出力を生成するユーザーインターフェイスは、「拒否」から「拒否」アクションに切り替えることができます。
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.
このセクションでは、「拒否」および「reject」アクションに等しく適用されます。このセクションの「拒否」アクションへのすべての参照は、「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".
「拒否」は、「休暇」[休暇]アクションと両立しない必要があります。実装は、「Keep」、「FileInto」、「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.
次のスクリプト（「スパムテスト」[スパムテスト]および「fileInto」拡張機能のサポートを想定しています）では、スパムを非常に陽性にするメッセージは拒否されます。
Example: require ["ereject", "spamtest", "fileinto", "comparator-i;ascii-numeric"];
例：["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例のデータコマンドへの応答は次のようになります。
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].
「eReeject」拡張機能は、ベース[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」アクションを追加します。拒否はできるだけ早く（たとえば、プロトコルレベルで）発生する必要があり、非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] 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] Myers、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.
[Sieve] Guenther、P。and T. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、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.
[休暇] Showalter、T。and N. Freed、「Sieve Emailフィルタリング：休暇拡張」、RFC 5230、2008年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[メールアーチ] 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、「Mail Non-Slivery Notice Attacks」、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] Showalter、T。、「Sieve：A Mail Filtering Language」、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。、「Sieve Emailフィルタリング：スパムテストとVirustest Extensions」、RFC 5235、2008年1月。
[UTF8-RESP] Melnikov, A., "SMTP Language Extension", Work in Progress, June 2007.
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.
Matthew Elvey The Elvey Partnership, LLC 1819 Polk Street, Suite 133 San Francisco, CA 94109 USA
マシューエルベイエルベイパートナーシップ、LLC 1819ポークストリート、スイート133サンフランシスコ、カリフォルニア94109 USA
EMail: matthew@elvey.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Author's Address
著者の連絡先
Aaron Stone (editor) Serendipity 260 El Verano Ave Palo Alto, CA 94306 USA
アーロン・ストーン（編集者）セレンディピティ260エルヴェラノアベロパロアルト、カリフォルニア94306 USA
EMail: aaron@serendipity.palo-alto.ca.us