[要約] RFC 5435は、Sieveメールフィルタリングの拡張であり、通知機能を提供することを目的としています。このRFCは、Sieveスクリプトを使用してメールフィルタリングを行う際に、通知を送信するための仕組みを定義しています。
Network Working Group A. Melnikov, Ed.
Request for Comments: 5435 Isode Limited
Category: Standards Track B. Leiba, Ed.
W. Segmuller
IBM T.J. Watson Research Center
T. Martin
Endless Crossword
January 2009
Sieve Email Filtering: Extension for Notifications
Sieve Emailフィルタリング：通知用の拡張機能
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 (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent.
ユーザーは、新しいメールを受け取ったことを可能な限り迅速に通知するために非常に長く進みます。これらの方法のほとんどは、定期的に新しいメッセージをチェックするためのポーリングを伴います。最終配信エージェントによって処理されるプッシュメソッドは、ユーザーがより迅速な通知を提供し、サーバーリソースを保存します。このドキュメントでは、通知方法は指定されていませんが、拡張可能なメッセージングとプレゼンスプロトコル（XMPP）などの既存のインスタントメッセージングインフラストラクチャ、またはモバイルコミュニケーション用のグローバルシステム（GSM）ショートメッセージサービス（SMS）メッセージが一般的になることが予想されます。このドキュメントでは、ユーザーが通知を送信する方法と時期について特定のルールを提供できるようにするSive Mailフィルタリング言語の拡張機能について説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Capability Identifier ...........................................3
3. Notify Action ...................................................3
3.1. Notify Action Syntax and Semantics .........................3
3.2. Notify Parameter "method" ..................................3
3.3. Notify Tag ":from" .........................................4
3.4. Notify Tag ":importance" ...................................4
3.5. Notify Tag ":options" ......................................5
3.6. Notify Tag ":message" ......................................5
3.7. Examples ...................................................6
3.8. Requirements on Notification Methods Specifications ........7
4. Test valid_notify_method ........................................8
5. Test notify_method_capability ...................................9
6. Modifier encodeurl to the 'set' Action .........................10
7. Interactions with Other Sieve Actions ..........................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................13
9.1. Registration of Sieve Extension ...........................13
9.2. New Registry for Sieve Notification Mechanisms ............14
9.3. New Registry for Notification-Capability Parameters .......14
10. Acknowledgements ..............................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
This is an extension to the Sieve language defined by [Sieve] for providing instant notifications. It defines the new action "notify".
これは、インスタント通知を提供するために[シーブ]によって定義されたふるい言語の拡張です。新しいアクション「Notify」を定義します。
This document does not specify the notification methods. Examples of possible notification methods are email and XMPP. To allow for the portability of scripts that use notifications, implementation of the [MailTo] method is mandatory. Other available methods shall depend upon the implementation and configuration of the system.
このドキュメントでは、通知方法は指定されていません。可能な通知方法の例は、電子メールとXMPPです。通知を使用するスクリプトの移植性を可能にするために、[MailTo]メソッドの実装が必須です。他の利用可能な方法は、システムの実装と構成に依存するものとします。
Conventions for notations are as in [Sieve], Section 1.1, including the use of [ABNF].
表記の規則は、[Sieve]、セクション1.1のように[ABNF]の使用を含む。
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 [Kwds].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[kwds]で説明されているように解釈されます。
The capability string associated with the extension defined in this document is "enotify".
このドキュメントで定義されている拡張機能に関連付けられている機能文字列は「enotify」です。
Usage: notify [":from" string]
[":importance" <"1" / "2" / "3">]
[":options" string-list]
[":message" string]
<method: string>
The "notify" action specifies that a notification should be sent to a user. The format of the notification is implementation-defined and is also affected by the notification method used (see Section 3.2). However, all content specified in the ":message" parameter SHOULD be included.
「Notify」アクションは、通知をユーザーに送信する必要があることを指定します。通知の形式は実装定義であり、使用される通知方法の影響も受けます（セクション3.2を参照）。ただし、「：メッセージ」パラメーターで指定されたすべてのコンテンツを含める必要があります。
The "method" positional parameter identifies the notification method that will be used; it is a URI [URI]. For example, the notification method can be a tel URI [TEL-URI] with a phone number to send SMS messages to, or an XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI].
「メソッド」位置パラメーターは、使用される通知方法を識別します。それはuri [uri]です。たとえば、通知方法は、SMSメッセージを送信する電話番号を備えたTel URI [Tel-URI]、またはXMPP識別子[XMPP-URI]を含むXMPP [XMPP] URIです。
The supported URI values will be site-specific, but support for the [MailTo] method is REQUIRED in order to ensure interoperability. If a URI schema is specified that the implementation does not support, the notification MUST cause an error condition at run time. Sieve scripts can check the supported methods using the valid_notify_method test to be sure that they only use supported ones, to avoid such error conditions.
サポートされているURI値はサイト固有ですが、相互運用性を確保するために[MailTo]メソッドのサポートが必要です。実装がサポートしていないことをURIスキーマが指定されている場合、通知は実行時にエラー条件を引き起こす必要があります。Sieve Scriptsは、valid_notify_methodテストを使用してサポートされているメソッドをチェックして、サポートされているもののみを使用して、そのようなエラー条件を回避することができます。
If the "method" parameter contains a supported URI schema, then the URI MUST be checked for syntactic validity. Invalid URI syntax or an unsupported URI extension MUST cause an error. An implementation MAY enforce other semantic restrictions on URIs -- for example, to restrict phone numbers in a tel: URI to a particular geographical region -- and will treat violations of such semantic restrictions as errors.
「メソッド」パラメーターにサポートされているURIスキーマが含まれている場合、URIに構文の妥当性がないか確認する必要があります。無効なURI構文またはサポートされていないURI拡張はエラーを引き起こす必要があります。実装は、たとえば、特定の地理的地域への電話番号を制限するために、URIの他のセマンティック制限を強制する場合があり、そのような意味制限の違反をエラーとして扱います。
A ":from" tag may be used to specify an author of the notification. The syntax of this parameter's value is method-specific. Implementations SHOULD check the syntax according to the notification method specification and generate an error when a syntactically invalid ":from" tag is specified.
a "：from"タグを使用して、通知の著者を指定できます。このパラメーターの値の構文はメソッド固有です。実装は、通知方法の仕様に従って構文を確認し、構文的に無効な "：from"タグが指定されている場合、エラーを生成する必要があります。
In order to minimize/prevent forgery of the author value, implementations SHOULD impose restrictions on what values can be specified in a ":from" tag. For example, an implementation may restrict this value to be a member of a list of known author addresses or to belong to a particular domain. It is suggested that values that don't satisfy such restrictions simply be ignored rather than causing the "notify" action to fail.
著者価値の偽造を最小限に抑える/防止するために、実装は "：from"で指定できる値に制限を課す必要があります。たとえば、実装は、この値を既知の著者アドレスのリストのメンバーに制限するか、特定のドメインに属することになります。そのような制限を満たさない値は、「通知」アクションを失敗させるのではなく、単に無視されることが示唆されています。
The ":importance" tag specifies the importance of quick delivery of the notification, as perceived by the Sieve script owner. The ":importance" tag is followed by a numeric value represented as a string: "1" (high importance), "2" (normal importance), and "3" (low importance). If no importance is given, the default value "2" SHOULD be assumed. A notification method MAY treat the importance value as a transport indicator. For example, it might deliver notifications of high importance quicker than notifications of normal or low importance. Some notification methods allow users to specify their state of activity (for example, "busy" or "away from keyboard"). If the notification method provides this information, it SHOULD be used to selectively send notifications. If, for example, the user marks herself as "busy", a notification method can require that a notification with importance of "3" is not to be sent; however, the user might be notified of a notification with higher importance.
「：重要」タグは、Sieve Scriptの所有者が知覚するように、通知の迅速な配信の重要性を指定します。「：重要」タグの後には、文字列として表される数値の値： "1"（高い重要性）、「2」（正常重要）、および「3」（重要性が低い）が続きます。重要性が与えられない場合、デフォルト値「2」を想定する必要があります。通知方法は、重要な値を輸送指標として扱う場合があります。たとえば、通常または低い重要性の通知よりも速い重要性の通知を提供する場合があります。一部の通知方法により、ユーザーはアクティビティ状態を指定できます（たとえば、「ビジー」または「キーボードから離れて」）。通知方法がこの情報を提供する場合、通知を選択的に送信するために使用する必要があります。たとえば、ユーザーが自分自身を「忙しい」とマークする場合、通知方法では、「3」の重要性を持つ通知を送信する必要があります。ただし、ユーザーは、より重要な通知を通知される場合があります。
If the notification method allows users to filter messages based upon certain parameters in the message, users SHOULD be able to filter based upon importance. If the notification method does not support importance, then this parameter MUST be ignored. An implementation MAY include the importance value in the default message, Section 3.6, if one is not provided.
通知方法により、ユーザーがメッセージ内の特定のパラメーターに基づいてメッセージをフィルタリングできる場合、ユーザーは重要性に基づいてフィルタリングできる必要があります。通知方法が重要性をサポートしていない場合、このパラメーターは無視する必要があります。実装には、提供されていない場合は、デフォルトメッセージの重要性値、セクション3.6を含めることができます。
The ":options" tag is used to send additional parameters to the notification method. Interpretation of the parameters is method-specific. This document doesn't specify any such additional parameter.
「：Options」タグは、追加のパラメーターを通知方法に送信するために使用されます。パラメーターの解釈は方法固有です。このドキュメントは、このような追加パラメーターを指定しません。
Each string in the options string list has the following syntax: "<optionname>=<value>" where optionname has the following ABNF [ABNF]:
オプション文字列リストの各文字列には、次の構文があります。 "<OptionName> = <value>" OptionNameには次のABNF [ABNF]があります。
l-d = ALPHA / DIGIT
l-d-p = l-d / "." / "-" / "_"
optionname = l-d *l-d-p
value = *(%x01-09 / %x0B-0C / %x0E-FF)
The ":message" tag specifies the message data to be included in the notification. The entirety of the string SHOULD be sent, but implementations MAY shorten the message for technical or aesthetic reasons. If the ":message" parameter is absent, a default implementation-specific message is used. Unless otherwise specified by a particular notification mechanism, an implementation default containing at least the value of the "From" header field and the value of the "Subject" header field is RECOMMENDED.
「：メッセージ」タグは、通知に含まれるメッセージデータを指定します。文字列全体を送信する必要がありますが、実装により、技術的または審美的な理由でメッセージが短くなる場合があります。「：メッセージ」パラメーターが存在しない場合、デフォルトの実装固有のメッセージが使用されます。特定の通知メカニズムで特に指定されていない限り、少なくとも「From」ヘッダーフィールドの値と「サブジェクト」ヘッダーフィールドの値を含む実装デフォルトが推奨されます。
In order to construct more complex messages, the notify extension can be used together with the Sieve variables extension [Variables], as shown in the examples below.
より複雑なメッセージを作成するために、以下の例に示すように、通知変数拡張[変数]と一緒にnotify拡張機能を使用できます。
Example 1: require ["enotify", "fileinto", "variables"];
例1：["enotify"、 "fileinto"、 "変数"を要求];
if header :contains "from" "boss@example.org" {
notify :importance "1"
:message "This is probably very important"
"mailto:alm@example.com";
# Don't send any further notifications
stop;
}
if header :contains "to" "sievemailinglist@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the value of the From header
if header :matches "From" "*" {
set "from" "${1}";
}
notify :importance "3"
:message "[SIEVE] ${from}: ${subject}"
"mailto:alm@example.com";
fileinto "INBOX.sieve";
}
Example 2: require ["enotify", "fileinto", "variables", "envelope"];
例2：["enotify"、 "fileinto"、 "valiables"、 "envelope"を要求する];
if header :matches "from" "*@*.example.org" {
# :matches is used to get the MAIL FROM address
if envelope :all :matches "from" "*" {
set "env_from" " [really: ${1}]";
}
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the address from the From header
if address :matches :all "from" "*" {
set "from_addr" "${1}";
}
notify :message "${from_addr}${env_from}: ${subject}"
"mailto:alm@example.com";
}
Example 3: require ["enotify", "variables"];
例3：["enotify"、 "変数"を要求];
set "notif_method"
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
if header :contains "subject" "Your dog" {
set "notif_method" "tel:+14085551212";
}
if header :contains "to" "sievemailinglist@example.org" {
set "notif_method" "";
}
if not string :is "${notif_method}" "" {
notify "${notif_method}";
}
if header :contains "from" "boss@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# don't need high importance notification for
# a 'for your information'
if not header :contains "subject" "FYI:" {
notify :importance "1" :message "BOSS: ${subject}"
"tel:+14085551212";
}
}
This section describes requirements for documents that define specific Sieve notification methods.
このセクションでは、特定のふるい通知方法を定義するドキュメントの要件について説明します。
Notification mechanisms MUST NOT add new Sieve tags to the "notify" action.
通知メカニズムは、「通知」アクションに新しいふるいタグを追加してはなりません。
A notification method MAY allow modification of the final notification text -- for example, truncating it if it exceeds a length limit or modifying characters that can not be represented in the target character set. Characters in the notification text that can't be represented by the notification method SHOULD be replaced with a symbol indicating an unknown character. Allowed modifications MUST be documented in the document describing the notification method.
通知方法では、最終通知テキストの変更を可能にする場合があります。たとえば、ターゲット文字セットで表現できない長さ制限を超えたり、変更されたりする文字を変更する場合、それを切り捨てます。通知テキストの文字は、通知方法で表すことができない文字は、未知の文字を示すシンボルに置き換える必要があります。許可された変更は、通知方法を説明するドキュメントに文書化する必要があります。
A notification method MAY ignore parameters specified in the "notify" action.
通知方法は、「通知」アクションで指定されたパラメーターを無視する場合があります。
A notification method MAY recommend the default message value to be used if the ":message" argument is not specified.
通知方法では、「：メッセージ」引数が指定されていない場合は、デフォルトのメッセージ値を使用することを推奨する場合があります。
Notifications SHOULD include timestamps, if the notification method allows for their transmission outside of the textual message. Implementation methods that can only transmit timestamps in the textual message MAY include them in the textual message.
通知がテキストメッセージの外側に送信を許可する場合、通知にはタイムスタンプを含める必要があります。テキストメッセージにタイムスタンプを送信できる実装方法は、テキストメッセージにそれらを含めることができます。
A notification MUST include means to identify/track its origin in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help with tracking a misconfigured or abusive origin of notifications.
通知には、受信者が通知を停止したり、送信者に連絡する方法を見つけたりできるようにするために、その起源を特定/追跡する手段を含める必要があります。この要件は、通知の誤解または虐待的な起源の追跡を支援することです。
Methods SHOULD NOT include any other extraneous information not specified in parameters to the "notify" action.
方法は、「通知」アクションのパラメーターに指定されていない他の外部情報を含めるべきではありません。
Methods MUST specify which URI parameters (if any) must be ignored, which ones must be used in the resulting notification, and which ones must cause an error.
メソッドは、どのURIパラメーターを無視する必要があるか、どのURIパラメーターを無視する必要があるかを指定する必要があります。
Methods MUST specify what values are returned by the notify_method_capability test, Section 5, in particular for the "online" notification-capability.
方法は、特に「オンライン」通知の能力について、notify_method_capabilityテスト、セクション5で返される値を指定する必要があります。
If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The Sieve interpreter MAY throttle notifications; if it does, a request to send a notification MAY be silently ignored. Documents describing notification methods SHOULD describe how retries, throttling, duplicate suppression (if any), etc. are to be handled by implementations.
通知を送信するエラーがある場合、シーブインタープリターは通知を無視し、無期限に再試行しないでください。シーブインタープリターは通知をスロットルする場合があります。もしそうなら、通知を送信するリクエストは静かに無視される場合があります。通知方法を説明するドキュメントでは、再試行、スロットリング、複製抑制（もしあれば）などを実装によって処理する方法を説明する必要があります。
Usage: valid_notify_method <notification-uris: string-list>
The valid_notify_method test is true if the notification methods listed in the notification-uris argument are supported and they are valid both syntactically (including URI parameters) and semantically (including implementation-specific semantic restrictions). This test MUST perform exactly the same validation as would be performed on the "method" parameter to the "notify" action.
valid_notify_methodテストは、通知-uris引数にリストされている通知方法がサポートされており、構文（URIパラメーターを含む）と意味的に（実装固有のセマンティック制限を含む）両方の有効である場合にTRUEです。このテストは、「メソッド」パラメーターで「通知」アクションに実行されるのとまったく同じ検証を実行する必要があります。
The test is true only if ALL of the listed notification methods are supported and valid.
このテストは、リストされているすべての通知方法がサポートされ、有効である場合にのみ当てはまります。
Example 4 (partial):
if not valid_notify_method ["mailto:",
"http://gw.example.net/notify?test"] {
stop;
}
Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
<notification-uri: string>
<notification-capability: string>
<key-list: string-list>
The notify_method_capability test retrieves the notification capability specified by the notification-capability string that is specific to the notification-uri and matches it to the values specified in the key-list. The test succeeds if a match occurs. The type of match defaults to ":is", and the default comparator is "i;ascii-casemap".
notify_method_capabilityテストは、通知-URIに固有の通知能力文字列によって指定された通知機能を取得し、キーリストで指定された値に一致させます。一致が発生した場合、テストは成功します。一致のタイプは「：IS」にデフォルトで、デフォルトのコンパレータは「I; ASCII-CASEMAP」です。
The notification-capability parameter is case insensitive.
通知の能力パラメーターは、ケースの鈍感です。
The notify_method_capability test MUST fail unconditionally if the specified notification-uri is syntactically invalid (as determined by the valid_notify_method test, Section 4) or specifies an unsupported notification method. However this MUST NOT cause an error.
notify_method_capabilityテストは、指定された通知-uriが構文的に無効である場合（valid_notify_methodテスト、セクション4で決定）、またはサポートされていない通知方法を指定する場合、無条件に失敗する必要があります。ただし、これはエラーを引き起こしてはなりません。
The notify_method_capability test MUST fail unconditionally if the specified notification-capability item is not known to the Sieve interpreter. A script MUST NOT fail with an error if the item does not exist. This allows scripts to be written that handle nonexistent items gracefully.
notify_method_capabilityテストは、指定された通知能力アイテムがシーブインタープリターに知られていない場合、無条件に失敗する必要があります。アイテムが存在しない場合、スクリプトはエラーで失敗してはなりません。これにより、存在しないアイテムを優雅に処理するスクリプトを書くことができます。
This document defines a single notification-capability value "online", which is described below. Additional notification-capability values may be defined by using the procedure defined in Section 9.3.
このドキュメントでは、以下で説明する単一の通知能力値「オンライン」を定義します。セクション9.3で定義されている手順を使用して、追加の通知習慣値を定義できます。
The "relational" extension [Relational] adds a match type called ":count". The count of an notify_method_capability test is 0, if the returned information is the empty string, or 1.
「リレーショナル」拡張[リレーショナル]は、「：count」と呼ばれる一致タイプを追加します。返された情報が空の文字列である場合、notify_method_capabilityテストのカウントは0です。
For the "online" notification-capability, the notify_method_capability test can match one of the following key-list values:
「オンライン」通知の能力の場合、notify_method_capabilityテストは、次のキーリスト値のいずれかと一致します。
o "yes" - the entity identified by the notification-uri can receive a notify notification immediately. Note that even after this value is returned, there is no guarantee that the entity would actually be able to receive any notification immediately or even receive it at all. Transport errors, recipient policy, etc. can prevent that.
o 「はい」 - 通知-URIによって特定されたエンティティは、すぐに通知通知を受信できます。この値が返された後でも、エンティティが実際にすぐに通知を受け取るか、まったく受け取ることさえできるという保証はないことに注意してください。輸送エラー、受信者ポリシーなどは、それを防ぐことができます。
o "no" - the entity identified by the notification-uri is not currently available to receive an immediate notification.
o 「いいえ」 - 通知-URIによって識別されたエンティティは現在、即時の通知を受け取ることができません。
o "maybe" - the Sieve interpreter can't determine if the entity identified by the notification-uri is online or not.
o 「たぶん」 - ふるい通訳者は、通知-URIによって識別されたエンティティがオンラインであるかどうかを判断できません。
Example 5: require ["enotify"];
例5：["enotify"]を要求します。
if notify_method_capability
"xmpp:tim@example.com?message;subject=SIEVE"
"Online"
"yes" {
notify :importance "1" :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
} else {
notify :message "You got mail" "tel:+14085551212";
}
Usage: ":encodeurl"
使用法： "：encodeurl"
When the Sieve script specifies both "variables" [Variables] and "enotify" capabilities in the "require", a new "set" action modifier (see [Variables]) ":encodeurl" becomes available to Sieve scripts. This modifier performs percent-encoding of any octet in the string that doesn't belong to the "unreserved" set (see [URI]). The percent-encoding procedure is described in [URI].
Sieveスクリプトが「変数」[変数]と「要求」の「EnoTify」機能の両方を指定すると、新しい「セット」アクション修飾（[変数]を参照） "：encodeurl"がスクリプトをふるいにかけられます。このモディファイアは、「予約されていない」セットに属さない文字列内のオクテットのパーセントエンコードを実行します（[uri]を参照）。パーセントエンコード手順は[URI]で説明されています。
The ":encodeurl" modifier has precedence 15.
「：encodeurl」修飾子には優先順位があります。
Example 6: require ["enotify", "variables"];
例6：["enotify"、 "変数"を要求];
set :encodeurl "body_param" "Safe body&evil=evilbody";
notify "mailto:tim@example.com?body=${body_param}";
The "notify" action is compatible with all other actions, and does not affect the operation of other actions. In particular, the "notify" action MUST NOT cancel the implicit keep.
「Notify」アクションは、他のすべてのアクションと互換性があり、他のアクションの操作に影響しません。特に、「通知」アクションは、暗黙のキープをキャンセルしてはなりません。
Multiple executed "notify" actions are allowed. Specific notification methods MAY allow multiple notifications from the same script to be collapsed into one.
複数の実行された「通知」アクションが許可されています。特定の通知方法により、同じスクリプトからの複数の通知を1つに崩壊させる場合があります。
Security considerations are discussed in [Sieve]. Additionally, implementations must be careful to follow the security considerations of the specific notification methods.
セキュリティ上の考慮事項については、[ふるい]で説明します。さらに、実装は、特定の通知方法のセキュリティに関する考慮事項に従うように注意する必要があります。
The "notify" action is potentially very dangerous. The path the notification takes through the network may not be secure. An error in the options string may cause the message to be transmitted to someone it was not intended for, or may expose information to eavesdroppers.
「通知」アクションは潜在的に非常に危険です。通知がネットワークを介して取るパスは安全でない場合があります。オプション文字列のエラーにより、メッセージが意図されていない人にメッセージを送信したり、情報を盗聴者に公開する場合があります。
Just because a notification is received doesn't mean that it was sent by the Sieve implementation. It might be possible to forge notifications or modify parts of valid notifications with some notification methods.
通知が受け取られたからといって、ふるいの実装によって送信されたという意味ではありません。いくつかの通知方法を使用して、有効な通知の一部を策定したり、変更したりすることが可能かもしれません。
Forgery of the ":importance" value (for example, by unauthorized script modification) can potentially result in slowdown in notification delivery.
「：重要な」価値（たとえば、許可されていないスクリプトの変更による）の偽造は、通知配信の減速を潜在的に引き起こす可能性があります。
Note that some components of notifications should not be trusted. For example, the timestamp field can be easily forged or modified when some notification transports are used. Even if the timestamp is believed to be correct by the sender and is not modified in transit, it might be misleading on the receiving system due to clock differences.
通知の一部のコンポーネントを信頼しないでください。たとえば、一部の通知トランスポートを使用すると、タイムスタンプフィールドを簡単に偽造または変更できます。タイムスタンプが送信者によって正しいと考えられていても、輸送中に変更されていない場合でも、時計の違いにより受信システムに誤解を招く可能性があります。
An organization may have a policy about the forwarding of classified information to unclassified networks. Unless the policy is also enforced in the module responsible for the generating (or sending) of notifications, users can use the extension defined in this document to extract classified information and bypass the policy.
組織は、分類されたネットワークへの分類情報の転送に関するポリシーを持っている場合があります。ポリシーが通知の生成（または送信）を担当するモジュールにも施行されていない限り、ユーザーはこのドキュメントで定義されている拡張機能を使用して、分類された情報を抽出し、ポリシーをバイパスできます。
Notifications can result in loops and bounces. Also, allowing a single script to notify multiple destinations can be used as a means of amplifying the number of messages in an attack. Moreover, if loop detection is not properly implemented, it may be possible to set up exponentially growing notification loops. Accordingly, Sieve notification methods:
通知はループやバウンスをもたらす可能性があります。また、単一のスクリプトを許可して複数の宛先に通知することは、攻撃のメッセージの数を増幅する手段として使用できます。さらに、ループ検出が適切に実装されていない場合、指数関数的に成長している通知ループを設定することが可能かもしれません。したがって、通知通知方法：
1. MUST provide mechanisms for avoiding notification loops.
1. 通知ループを回避するためのメカニズムを提供する必要があります。
2. MUST provide the means for administrators to limit the ability of users to abuse notify. In particular, it MUST be possible to limit the number of "notify" actions a script can perform. Additionally, if no use cases exist for using "notify" with multiple destinations, this limit SHOULD be set to 1. Additional limits, such as the ability to restrict "notify" to local users, MAY also be implemented.
2. 管理者がユーザーが通知を悪用する能力を制限する手段を提供する必要があります。特に、スクリプトが実行できる「通知」アクションの数を制限することが可能である必要があります。さらに、複数の宛先で「通知」を使用するための使用ケースが存在しない場合、この制限は1に設定する必要があります。
3. MUST provide facilities to log the use of "notify" in order to facilitate tracking down abuse.
3. 虐待の追跡を容易にするために、「通知」の使用を記録する施設を提供する必要があります。
4. MAY use script analysis to determine whether or not a given script can be executed safely. While the Sieve language is sufficiently complex so that full analysis of all possible scripts is computationally infeasible, the majority of real-world scripts are amenable to analysis. For example, an implementation might allow scripts that it has determined to be safe to run unhindered, block scripts that are potentially problematic, and subject unclassifiable scripts to additional auditing and logging.
4. スクリプト分析を使用して、特定のスクリプトを安全に実行できるかどうかを判断できます。ふるい言語は十分に複雑であるため、可能なすべてのスクリプトの完全な分析が計算的に実行不可能になるように、実際のスクリプトの大部分は分析に適しています。たとえば、実装では、妨げられていないこと、潜在的に問題があるブロックスクリプトを実行することが安全であると判断されたスクリプト、および追加の監査とロギングを非分類できないスクリプトをブロックすることができる場合があります。
Allowing "notify" action at all may not be appropriate in situations where Sieve scripts are associated with email accounts that are freely-available and/or not trackable to a human who can be held accountable for creating message bombs or other abuse.
「通知」アクションをまったく許可することは、メッセージ爆弾やその他の虐待の作成に責任を負うことができる人間が自由に利用できる、および/または追跡できない電子メールアカウントにSIVEスクリプトが関連付けられている状況では適切ではない場合があります。
Implementations that construct URIs internally from various notify parameters MUST make sure that all components of such URIs are properly percent-encoded (see [URI]). In particular, this applies to values of the ":from" and ":message" tagged arguments and may apply to the ":options" values.
さまざまなNotifyパラメーターから内部的にURIを構築する実装は、そのようなURIのすべてのコンポーネントが適切にエンコードされていることを確認する必要があります（[URI]を参照）。特に、これは「：from」および「：メッセージ」の引数の値に適用され、「：Options」値に適用される場合があります。
Header/envelope tests [Sieve], together with Sieve variables, can be used to extract the list of users to receive notifications from the incoming email message or its envelope. This is potentially quite dangerous, as this can be used for denial-of-service attacks on recipients controlled by the message sender. For this reason, implementations SHOULD NOT allow the use of variables containing values extracted from the email message in the "method" parameter to the "notify" action. Note that violation of this SHOULD NOT may result in the creation of an open relay, i.e., any sender would be able to create specially crafted email messages that would result in notifications delivered to recipients under the control of the sender. In the worst case, this might result in financial loss by the user controlling the Sieve script and/or by recipients of notifications (e.g., if a notification is an SMS message).
ヘッダー/エンベロープテスト[シーブ]は、ふるい変数と一緒に、ユーザーのリストを抽出して、着信電子メールメッセージまたはそのエンベロープから通知を受け取ることができます。これは、メッセージ送信者によって制御される受信者に対するサービス拒否攻撃に使用できるため、非常に危険です。このため、実装は、「メソッド」パラメーターから「通知」アクションに抽出された値を含む変数を使用することを許可してはなりません。これに違反すると、オープンリレーが作成されない可能性があることに注意してください。つまり、送信者は、送信者の管理下にある受信者に通知が配信される特別に作成された電子メールメッセージを作成できます。最悪の場合、これにより、ユーザーがシーブスクリプトを制御すること、および/または通知の受信者による経済的損失が発生する可能性があります（たとえば、通知がSMSメッセージである場合）。
Note that the last SHOULD NOT is not a generic prohibition of use of variables in the "notify" action, as controlling the target of a notification by extracting it from user-owned data stores (such as user's Lightweight Directory Access Protocol (LDAP) entry) is considered to be useful.
最後のものは、ユーザー所有のデータストア（ユーザーのLightweight Directory Access Protocol（LDAP）エントリなど）から抽出することで通知のターゲットを制御するため、「Notify」アクションで変数の使用を一般的に禁止することではないことに注意してください。）有用であると考えられています。
It is imperative that whatever implementations use to store the user-defined filtering scripts protect them from unauthorized modification, to preserve the integrity of the mail system. An attacker who can modify a script can cause mail to be discarded, rejected, or forwarded to an unauthorized recipient. In addition, it's possible that Sieve scripts might expose private information, such as mailbox names or email addresses of favored (or disfavored) correspondents. Because of that, scripts SHOULD also be protected from unauthorized retrieval.
ユーザー定義のフィルタリングスクリプトを保存するために使用する実装を使用して、メールシステムの整合性を維持するために、不正な変更から保護することが不可欠です。スクリプトを変更できる攻撃者は、許可されていない受信者にメールを破棄、拒否、または転送することができます。さらに、Sieve Scriptsは、メールボックス名や、好まれた（または不利な）特派員の電子メールアドレスなどの個人情報を公開する可能性があります。そのため、スクリプトも許可されていない検索から保護する必要があります。
To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: enotify
Description: adds the "notify" action for notifying user about the
received message. It also provides two new tests:
valid_notify_method checks notification URIs for validity;
notify_method_capability can check recipients capabilities.
RFC number: this RFC
Contact address: The Sieve discussion list
<ietf-mta-filters@imc.org>
This information has been added to the list of Sieve extensions available from http://www.iana.org/.
この情報は、http：//www.iana.org/から入手可能なふるい拡張機能のリストに追加されています。
IANA has created a new registry for Sieve notification mechanisms. This registry contains both vendor-controlled notification mechanism names (beginning with "vnd.") and IETF-controlled notification mechanism names. Vendor-controlled notification mechanism names have the format as defined in the following paragraph and may be registered on a "First Come First Served" basis [IANA-GUIDELINES], by applying to IANA with the form specified later in this section. Registration of notification mechanisms that do not begin with "vnd." are registered using a "Specification Required" policy [IANA-GUIDELINES].
IANAは、ふるい通知メカニズムのための新しいレジストリを作成しました。このレジストリには、ベンダー制御された通知メカニズム名（「VND」から始まる）とIETF制御通知メカニズム名の両方が含まれています。ベンダー制御の通知メカニズム名は、次の段落で定義されている形式を持ち、このセクションで指定されたフォームをIANAに適用することにより、「最初に来る最初の提供」ベース[Iana-Guidelines]に登録できます。「VND」で始まらない通知メカニズムの登録。「必要な仕様」ポリシー[IANA-Guidelines]を使用して登録されています。
Vendor-controlled notification mechanism names MUST have the form "vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as specified in the Application Configuration Access Protocol (ACAP) Vendor Subtree registry [ACAP].
ベンダー制御通知メカニズム名には、「vnd。<vendor-name>。<mechanism-name>」という形式が必要です。ここで、<vendor-name>はアプリケーション構成アクセスプロトコル（ACAP）ベンダーサブツリーレジストリ[ACAP]で指定されています。。
This defines the template for a new registry for Sieve notification mechanisms, which has been created and is available from http://www.iana.org/. There are no initial entries for this registry.
これは、http://www.iana.org/から作成され、入手可能なシーブ通知メカニズムの新しいレジストリのテンプレートを定義します。このレジストリの初期エントリはありません。
To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: [the name of the mechanism]
Mechanism URI: [the RFC number of the document that defines the URI
used by this mechanism. Different mechanisms MUST use different
URI schema.]
Mechanism-specific options: [the names of any Sieve notify options
(as used in the ":options" parameter) that are specific to this
mechanism, or "none"]
Permanent and readily available reference: [the RFC number or an URL
of the document that defines this notification mechanism]
Person and email address to contact for further information: [the
name and email address of the technical contact for information
about this mechanism]
IANA has created a new registry for the notification-capability parameters of the notify_method_capability test. This registry contains both vendor-controlled notification-capability values (beginning with "vnd.") and IETF-controlled notification-capability values. Vendor-controlled notification-capability values have the format as defined in the following paragraph and may be registered on a "First Come First Served" basis [IANA-GUIDELINES], by applying to IANA with the form specified later in this section. Registration of notification-capability values that do not begin with "vnd." are registered using the "Specification Required" policy [IANA-GUIDELINES].
IANAは、notify_method_capabilityテストの通知能力パラメーターの新しいレジストリを作成しました。このレジストリには、ベンダー制御の通知能力値（「VND」から始まる）とIETF制御の通知能力値の両方が含まれています。ベンダー制御通知の能力値は、次の段落で定義されている形式を持ち、このセクションで指定されたフォームをIANAに適用することにより、「最初の来る最初の提供」ベース[IANA-GUIDERINES]に登録される場合があります。「vnd」で始まらない通知能力値の登録。「必要な仕様」ポリシー[IANA-Guidelines]を使用して登録されています。
Vendor-controlled notification-capability values MUST have the form "vnd.<vendor-name>.<capability-name>", where <vendor-name> is as specified in the ACAP Vendor Subtree registry [ACAP].
ベンダー制御通知の能力値は、「vnd。<vendor-name>。<capability-name>」という形式を持っている必要があります。ここで、<vendor-name>はACAPベンダーサブツリーレジストリ[ACAP]で指定されています。
The following template must be used for registering notification-capability parameters:
次のテンプレートは、通知の能力パラメーターを登録するために使用する必要があります。
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: [the name of the notification-capability]
Description: [an explanation of the purpose of the notification-
capability]
Syntax: [formal definition of allowed values and their syntax]
Permanent and readily available reference(s): [the RFC number(s) or
an URL of the document that defines this notification mechanism]
Contact information: [the name and email address of the technical
contact for information about this mechanism]
Below is the registration form for the "online" notification-capability:
以下は、「オンライン」通知の能力の登録フォームです。
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: online
Description: Returns whether the entity identified by the
notification-uri parameter to the notify_method_capability test
can receive a notify notification immediately.
Syntax: Can contain one of three values: "yes", "no", and, "maybe".
Values MUST be in lowercase.
Permanent and readily available reference(s): This RFC
Contact information: The Sieve discussion list
<ietf-mta-filters@imc.org>
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings, and Pasi Eronen for help with this document.
ラリー・グリーンフィールド、サラ・ロブソン、ティム・ショールーター、サイラス・ダブー、ナイジェル・スウィンソン、ケティル・トーグリム・ホム、マイケル・ハード、マーク・E・マレット、ネッド・フリード、リサ・デュッセー、ディリアン・パラウゾフ、アート・ガルブランセン、ピーター・サンアンドレ、この文書を支援してくれたジェニングス、およびパシ・エロネン。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWDS] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, January 2009.
[Mailto] Leiba、B。and M. Haardt、「Sieve Notification Mechanism：Mailto」、RFC 5436、2009年1月。
[Relational] Segmuller, W. and B. Leiba, "Sieve Extension: Relational Tests", RFC 5231, January 2008.
[リレーショナル] Segmuller、W。and B. Leiba、「Sieve Extension：Relational Tests」、RFC 5231、2008年1月。
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[ふるい] Guenther、P.、ed。and T. Showalter、ed。、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[変数] Homme、K。、「Sieve Extension：変数」、RFC 5229、2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[Iana-Guidelines] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[TEL-URI] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[Tel-uri] Schulzrinne、H。、「電話番号のTel URI」、RFC 3966、2004年12月。
[XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP] Saint-Andre、ed。、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 3920、2004年10月。
[XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[XMPP-URI] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）の国際化されたリソース識別子（IRIS）および均一なリソース識別子（URI）」、RFC 5122、2008年2月。
Authors' Addresses
著者の住所
Alexey Melnikov (editor) 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
Barry Leiba (editor) IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Barry Leiba（編集者）IBM T.J.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532米国
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Wolfgang Segmuller IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Wolfgang Segmuller IBM T.J.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532米国
Phone: +1 914 784 7408
EMail: werewolf@us.ibm.com
Tim Martin Endless Crossword 672 Haight st. San Francisco, CA 94117 US
ティムマーティンエンドレスクロスワード672ヘイトセントカリフォルニア州サンフランシスコ94117 US
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu