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
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 (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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
ユーザーは、可能な限り迅速に、彼らは新しいメールを受け取ったことが通知されるように偉大な長さに行きます。これらの方法の大部分は、定期的に新しいメッセージをチェックするためにポーリングを必要とします。最終的な配送エージェントによって処理さpushメソッドは、ユーザーの迅速な通知を与え、サーバリソースを節約できます。この文書では、通知方法を指定しませんが、モバイル通信のために、このような拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）などの既存のインスタントメッセージングインフラストラクチャを使用して、またはグローバルシステム（GSM）ショートメッセージサービス（SMS）メッセージが人気であることが期待されます。この文書では、ユーザーがいつ、どのように通知が送られるべきであるため、特定のルールを与えることができますふるいメールフィルタリング言語の拡張機能について説明します。
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".
これは、インスタント通知を提供するために、[ふるい]によって定義されたSieve言語への拡張です。これは、新しいアクション「通知」を定義します。
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].
表記の規則は、[ふるい]と[ABNF]の使用を含むセクション1.1です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【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>
用法：[ "から" 文字列]通知[ "重要" < "1" / "2" / "3">] [ "オプション" の文字列リスト] [ "メッセージ" 文字列] <方法：文字列>
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.
「通知」アクションは、通知がユーザーに送信されることを指定します。通知の形式は実装定義であり、また使用する通知方法（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メッセージを送信するための電話番号、またはXMPP XMPP識別子を含む[XMPP] URI [XMPP-URI]とTEL URI [TEL-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スキーマを実装がサポートしていないことを指定した場合、通知は、実行時にエラー状態が発生しなければなりません。ふるいのスクリプトは、このようなエラー状態を回避するために、彼らは唯一のサポートのものを使用することを確認するために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の拡張子は、エラーが発生しなければなりません。例えば、TELでの電話番号を制限する - 実装は、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「から」タグは、通知の作成者を指定するために使用されてもよいです。このパラメータの値の構文はメソッド固有です。実装は、通知方法の指定に応じて構文をチェックして、構文的に無効な場合、エラーを生成する必要があります「から」タグが指定されています。
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.
タグ：「から」著者値の偽造を防ぐ/最小限にするためには、実装がで指定することができますどのような値に制限を課すべきです。例えば、実装は、既知の著者アドレスのリストのメンバであるために、この値を制限するか、または特定のドメインに属しています。そのような制限を満たしていない値は、単に、むしろ「通知」アクションが失敗する原因よりも、無視されることが示唆されます。
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スクリプトの所有者によって知覚される「重要度」タグは、通知の短納期の重要性を指定します。 「重要」：「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.
通知方法は、ユーザーがメッセージ内の特定のパラメータに基づいてメッセージをフィルタリングすることを可能にする場合、ユーザは、重要度に基づいてフィルタリングすることができるべきです。通知方法は、重要性をサポートしていない場合、このパラメータは無視しなければなりません。 1が提供されていない場合、実装は、デフォルトのメッセージで重要度の値は、セクション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.
「：オプション」タグが通知方法に追加のパラメータを送信するために使用されます。パラメータの解釈はメソッド固有です。この文書では、そのような追加のパラメータを指定していません。
Each string in the options string list has the following syntax: "<optionname>=<value>" where optionname has the following ABNF [ABNF]:
オプション名は以下のABNF [ABNF]を持っている「<オプション名> = <値>」：オプションの文字列リストの各文字列の構文は次のとおりです。
l-d = ALPHA / DIGIT l-d-p = l-d / "." / "-" / "_" optionname = l-d *l-d-p value = *(%x01-09 / %x0B-0C / %x0E-FF)
L-D = ALPHA / DIGITのL-D-P = L-D / "" / " - " / "_" オプション名= L-Dの* L-D-P値= *（％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.
「：メッセージ」タグは、通知に含まれるメッセージデータを指定します。文字列全体が送られる必要がありますが、実装は、技術的または審美的な理由のためにメッセージが短くなる場合があります。 「：メッセージ」場合はパラメータが存在しない、デフォルトの実装固有のメッセージが使用されています。そうでなければ特定の通知メカニズムによって指定されない限り、ヘッダフィールドと「件名」ヘッダフィールドの値が「から」の少なくとも値を含む実装デフォルトが推奨されます。
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.
以下の実施例に示すように、より複雑なメッセージを構築するために、通知拡張は、ふるい変数延長[変数]と一緒に使用することができます。
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}"; }
ヘッダ場合：「：マッチヘッダ場合件名ヘッダの値を取得するために使用されている：{＃がマッチ」「sievemailinglist@example.org「から」含ま件名」「*」{セット「対象」、「$ {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"、 "変数"、 "封筒"]が必要です。
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"; }
ヘッダ場合：「被験体」、「あなたの犬」{セット「notif_method」「TEL：+14085551212」を含みます。 }
if header :contains "to" "sievemailinglist@example.org" { set "notif_method" ""; }
ヘッダ場合：「」「sievemailinglist@example.org」{セット「notif_method」「に」が含ま。 }
if not string :is "${notif_method}" "" { notify "${notif_method}"; }
ない文字列であれば、 "$ {notif_method}" "" { "$ {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}"; }
ヘッダがあれば：boss@example.org「「から」含有」{＃：マッチは、ヘッダ場合件名ヘッダの値を取得するために使用される：マッチ「テーマ」「*」{「$ {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"; } }
ヘッダーでない場合は＃が＃「あなたの情報のために」の重要度の高い通知を必要としません：FYI「「件名」が含まれている：」{通知：重要「1」：メッセージ「BOSS：$ {対象}」「電話番号：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パラメータを指定する必要があります。
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>
使用法：valid_notify_methodの<notification-のURI：文字列のリスト>
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.
通知-URIを引数にリストされている通知方法がサポートされており、彼らが（実装固有の意味上の制限を含む）の両方の構文的に（URIパラメータを含む）と意味的に有効とされている場合valid_notify_methodテストが真です。このテストは、「通知」アクションの「方法」のパラメータで実行されるようにまったく同じ検証を実行しなければなりません。
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; }
実施例4（部分）：valid_notify_methodない場合[ "のmailto："、 "http://gw.example.net/notify?test"] {ストップ。 }
Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE] <notification-uri: string> <notification-capability: string> <key-list: string-list>
使用法：notify_method_capability [コンパレータ] [MATCH-TYPE]の<notification-URI：文字列> <通知機能：文字列>の<key-リスト：文字列のリスト>
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に特異的であり、キーリストで指定された値にそれを一致通知能力文字列で指定された通知機能を検索します。マッチが発生した場合、テストは成功します。マッチのデフォルトのタイプは「：あり」、およびデフォルトのコンパレータは「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.
（valid_notify_method試験、セクション4によって決定されるように）、またはサポートされていない通知方法を指定する指定された通知-URIが構文的に無効である場合notify_method_capabilityテストは無条件失敗しなければなりません。しかし、これはエラーを引き起こしてはなりません。
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.
「：数」「関係」の拡張子[リレーショナル]と呼ばれるマッチタイプを追加します。返された情報は、空の文字列、または1の場合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は」Sieveスクリプトに利用可能になります。この修飾子は、「予約されていない」セット（[URI]参照）に属していない文字列内の任意のオクテットのパーセント符号化を行います。パーセント符号化手順は、[URI]に記載されています。
The ":encodeurl" modifier has precedence 15.
「：にencodeURL」修飾子が優先さ15を有しています。
Example 6: require ["enotify", "variables"];
実施例6：[ "enotify"、 "変数"]要します。
set :encodeurl "body_param" "Safe body&evil=evilbody";
セット：にencodeURL "body_param" "安全ボディ＆悪= evilbody";
notify "mailto:tim@example.com?body=${body_param}";
通知 "？のmailto：tim@example.com体= $ {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.
「通知」アクションは、他のすべてのアクションと互換性があり、かつ他のアクションの動作には影響を与えません。具体的には、「通知」アクションは暗黙のキープをキャンセルしてはなりません。
Multiple executed "notify" actions are allowed. Specific notification methods MAY allow multiple notifications from the same script to be collapsed into one.
複数の実行「通知」のアクションが許可されています。具体的な通知方法は、同じスクリプトから複数の通知を一つにまとめることを可能にすることができます。
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:
通知はループとバウンスが発生することができます。また、許可複数の宛先に通知する単一のスクリプト攻撃内のメッセージの数を増幅する手段として使用することができます。ループ検出が正しく実装されていない場合はさらに、指数関数的に増殖通知ループを設定することも可能です。したがって、ふるいの通知方法：
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.
で、すべてのアクションを「通知」許可するSieveスクリプトを自由に利用可能な、および/またはメッセージ爆弾やその他の虐待を作成するための責任を負うことができる人間に追跡可能でない電子メールアカウントに関連付けられている状況では適切でないかもしれません。
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.
種々の内部URIを構築する実装がパラメータは、URIのすべてのコンポーネントが正しくパーセントエンコードされていることを確認する必要があります通知する（参照[URI]）。特に、これはの値に適用される「から」と「メッセージ」引数をタグ付けに適用することができる「：オプション」値。
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メッセージの場合）および/または通知の受信者によってSieveスクリプトを制御するユーザによって経済的損失につながる可能性があります。
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.
こうしたユーザーのLDAP（Lightweight Directory Access Protocol）のエントリとして（ユーザー所有のデータストアからそれを抽出することにより、通知の対象を制御するよう、最後は「通知」アクションでの変数の使用の一般的な禁止ではないべきではないことに注意してください）有用であると考えられています。
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スクリプトは、好まれる（または好ましくない）特派のメールボックス名やメールアドレスなど、個人情報を公開する可能性があることが可能です。そのため、スクリプトはまた、不正な検索から保護されなければなりません。
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>
To：iana@iana.org件名：enotify説明：新しいふるい拡張機能名の登録、受信したメッセージをユーザに通知するための「通知」アクションを追加します。また、2つの新しいテスト提供：妥当性についてvalid_notify_methodチェック通知URIを、 notify_method_capabilityは、受信者の能力を確認することができます。 RFC番号：このRFCの連絡先アドレス：ふるいディスカッションリスト<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-ガイドライン]に登録することができるようなフォーマットを有します。始まらない通知メカニズムの登録「VND。」 「仕様が必要である」というポリシー[IANA-ガイドライン]を使用して登録されています。
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].
ベンダ制御された通知メカニズム名はフォーム「ドンを<ベンダー名>。<機構名>」なければならず、ここで、<ベンダ名>アプリケーション設定アクセスプロトコル（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]
To：iana@iana.org件名：新しいふるい通知メカニズムメカニズム名の登録：メカニズムURI [メカニズムの名前]：[このメカニズムによって使用されるURIを定義する文書のRFC番号。異なる機構は、異なるURIスキーマを使用しなければならない]メカニズムに固有のオプション：[任意ふるい通知オプション（で使用される：パラメータ「オプション」）の名前このメカニズムに特異的である、または「なし」永久かつ容易に入手可能な参照を：[RFC番号または、この通知メカニズムを定義した文書のURL]詳細のために連絡する人とEメールアドレス：[このメカニズムについては、技術担当者の名前と電子メールアドレス]
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-ガイドライン]に登録することができるようなフォーマットを有します。始まらない通知-能力値の登録「VND。」 「仕様が必要である」というポリシー[IANA-ガイドライン]を使用して登録されています。
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].
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]
To：iana@iana.org件名：新しい通知機能パラメータの機能名の登録：説明[通知機能の名前]：構文[通知機能の目的の説明]：[許可の正式な定義値とその構文]常設し、容易に利用可能な基準（S）：[RFC番号（複数可）またはこの通知メカニズムを定義するドキュメントのURL]連絡先：[この詳細については、技術担当者の名前と電子メールアドレス機構]
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>
To：iana@iana.org件名：オンライン説明：notify_method_capability試験に通知-uriパラメータによって識別されるエンティティは、すぐに通知し、通知を受け取ることができるかどうかを返し、新しい通知機能パラメータ機能名の登録。構文：「多分」、「はい」、「いいえ」、および：3つの値のいずれかを含むことができます。値は小文字でなければなりません。恒久的かつ容易に利用可能な基準（S）：このRFCの連絡先情報：ふるいディスカッションリスト<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.
ラリー・グリーンフィールド、サラ・ロブソン、ティム・ショーウォルター監督、サイラスDaboo、ナイジェルSwinson、はKjetil Torgrimオム、マイケルHaardt、マーク・E.マレット、ネッドフリード、リサDusseault、Dilyan Palauzov、ARNT Gulbrandsenの、ピーター・サン・アンドレ、ショーン・ターナー、カレンのおかげでこのドキュメントのヘルプのためのジェニングス、およびパシEronen。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]クロッカー、D.、エド。そして、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, January 2009.
[のMailTo] Leiba、B.とM. Haardt、 "ふるい通知メカニズム：MAILTO"、RFC 5436、2009年1月。
[Relational] Segmuller, W. and B. Leiba, "Sieve Extension: Relational Tests", RFC 5231, January 2008.
[リレーショナル] Segmuller、W.及びB. Leiba、 "ふるい拡張子：リレーショナルテスト"、RFC 5231、2008年1月。
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[ふるい]ギュンター、P.、エド。 。とT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[変数]オム、K.、 "ふるい拡張：変数"、RFC 5229、2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "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-ガイドライン] 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]サン・アンドレ、エド、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"。、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]サンアンドレ、P.、 "国際化資源識別子（IRIを）および拡張メッセージングおよびプレゼンスプロトコル（XMPP）のためのユニフォームリソース識別子（URI）"、RFC 5122、2008年2月。
Authors' Addresses
著者のアドレス
Alexey Melnikov (editor) 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
Barry Leiba (editor) IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
バリー・レイバ（編集者）IBM T.J。ワトソン研究所19スカイラインドライブホーソーン、NY 10532米国
Phone: +1 914 784 7941 EMail: leiba@watson.ibm.com
電話：+1 914 784 7941 Eメール：leiba@watson.ibm.com
Wolfgang Segmuller IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
ヴォルフガングSegmuller IBM T.J。ワトソン研究所19スカイラインドライブホーソーン、NY 10532米国
Phone: +1 914 784 7408 EMail: werewolf@us.ibm.com
電話：+1 914 784 7408 Eメール：werewolf@us.ibm.com
Tim Martin Endless Crossword 672 Haight st. San Francisco, CA 94117 US
ティム・マーティンエンドレスクロスワード672ヘイトセント。サンフランシスコ、CA 94117米国
Phone: +1 510 260-4175 EMail: timmartin@alumni.cmu.edu
電話：+1 510 260-4175 Eメール：timmartin@alumni.cmu.edu