Network Working Group B. Leiba
Request for Comments: 5436 IBM T.J. Watson Research Center
Updates: 3834 M. Haardt
Category: Standards Track freenet.de GmbH
January 2009
Sieve Notification Mechanism: mailto
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
抽象
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail.
この文書では、通知が電子メールで送信されるように、通知のためのふるい延長のプロファイルを記述する。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Conventions Used in This Document ..........................3
2. Definition ......................................................3
2.1. Notify Parameter "method" ..................................3
2.2. Test notify_method_capability ..............................3
2.3. Notify Tag ":from" .........................................3
2.4. Notify Tag ":importance" ...................................4
2.5. Notify Tag ":options" ......................................4
2.6. Notify Tag ":message" ......................................4
2.7. Other Definitions ..........................................4
2.7.1. The Auto-Submitted Header Field .....................6
3. Examples ........................................................7
4. Internationalization Considerations .............................8
5. Security Considerations .........................................9
6. IANA Considerations ............................................10
6.1. Registration of Notification Mechanism ....................10
6.2. New Registry for Auto-Submitted Header Field Keywords .....10
6.3. Initial Registration of Auto-Submitted Header
Field Keywords ............................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
The [Notify] extension to the [Sieve] mail filtering language is a framework for providing notifications by employing URIs to specify the notification mechanism. This document defines how [mailto] URIs are used to generate notifications by email.
[ふるい]メールフィルタリング言語に[通知]拡張は、通知メカニズムを指定するURIを使用することにより、通知を提供するためのフレームワークです。この文書では、[MAILTO] URIは、電子メールによる通知を生成するために使用する方法を定義します。
Conventions for notations are as in Section 1.1 of [Sieve], including the use of [Kwds].
表記の規則は、[Kwds]の使用を含む、[ふるい]のセクション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 mailto mechanism results in the sending of a new email message (a "notification message") to notify a recipient about a "triggering message".
「トリガーメッセージ」についての受信者に通知するために、新しい電子メールメッセージ（「通知メッセージ」）の送信でのmailtoのメカニズムの結果。
The mailto notification mechanism uses standard mailto URIs as specified in [mailto]. mailto URIs may contain header fields consisting of a header name and value. These header fields are called "URI headers" to distinguish them from "message headers".
[MAILTO]で指定されるようにmailtoの通知メカニズムは、標準のmailto URIを使用します。 MAILTO URIは、ヘッダ名と値とからなるヘッダフィールドを含んでいてもよいです。これらのヘッダーフィールドは、「メッセージヘッダ」と区別するために「URIヘッダ」と呼ばれます。
The notify_method_capability test for "online" may return "yes" or "no" only if the Sieve processor can determine with certainty whether or not the recipients of the notification message are online and logged in. Otherwise, the test returns "maybe" for this notification method.
「オンライン」のnotify_method_capabilityテストは「yes」または「no」ふるいプロセッサは、通知メッセージの受信者がこのためにそうでなければ、テストリターンが「多分」。オンラインで、ログインしたか否かを確実に判断できる場合にのみ返すことがあります。通知方法。
The ":from" tag overrides the default sender of the notification message. "Sender", here, refers to the value used in the [RFC5322] "From" header. Implementations MAY also use this value in the [RFC5321] "MAIL FROM" command (the "envelope sender"), or they may prefer to establish a mailbox that receives bounces from notification messages.
「：から」タグは、通知メッセージのデフォルトの送信者を優先します。 「送信者」は、ここでは、「From」ヘッダ[RFC5322]で使用される値を意味します。また、実装はコマンド（「エンベロープ送信者」）[RFC5321]「FROM MAIL」で、この値を使用したり、それらを通知メッセージからバウンスを受け取るメールボックスを確立することを好むかもしれません。
The ":importance" tag has no special meaning for this notification mechanism, and this specification puts no restriction on its use. Implementations MAY use the value of ":importance" to set a priority or importance indication on the notification message (perhaps a visual indication, or perhaps making use of one of the non-standard but commonly used message headers).
「：重要」タグは、この通知メカニズムのためには特別な意味を持ちませんし、この仕様は、その使用に制限をかけていません。通知メッセージ（おそらく視覚的な表示、またはおそらく非標準が、一般的に使用されるメッセージ・ヘッダーのいずれを利用して）上の優先順位または重要性指標を設定する：「重要性」の実装は、値を使用することができます。
This tag is not used by the mailto method.
このタグは、mailtoの方法で使用されていません。
The value of this tag, if it is present, is used as the subject of the notification message, and overrides all other mechanisms for determining the subject (as described below). Its value SHOULD NOT normally be truncated, though it may be sensible to truncate an excessively long value.
このタグの値は、それが存在する場合、通知メッセージの件名として使用され、（後述のように）対象を決定するために、すべての他のメカニズムを上書き。過度に長い値を切り捨てるが賢明かもしれないが、その値は、通常、切り捨てされるべきではありません。
Because the receipt of an email message is generating another email message, implementations MUST take steps to avoid mail loops. The REQUIRED inclusion of an "Auto-Submitted:" field, as described in the message composition guidelines, will also help in loop detection and avoidance.
電子メールメッセージの受信が別の電子メールメッセージを生成しているので、実装はメールのループを避けるために、手順を実行する必要があります。 「自動提出：」必要な包含フィールドは、メッセージ作成のガイドラインに記載されているように、また、ループ検出及び回避に役立つだろう。
Implementations SHOULD NOT trigger notifications for messages containing "Auto-Submitted:" header fields with any value other than "No".
「いいえ」以外の値を持つヘッダフィールド：実装は、「自動提出」を含むメッセージの通知をトリガすべきではありません。
Implementations MUST allow messages with empty envelope senders to trigger notifications.
実装は空のエンベロープ送信者とのメッセージが通知をトリガするために許容しなければなりません。
Because this notification method uses a store-and-forward system for delivery of the notification message, the Sieve processor should not have a need to retry notifications. Therefore, implementations of this method SHOULD use normal mechanisms for submitting SMTP messages and for retrying the initial submission. Once the notification message is submitted, implementations MUST NOT resubmit it, as this is likely to result in multiple notifications, and increases the danger of message loops.
この通知方法は、通知メッセージの送達のためのストアアンドフォワード方式を採用しているため、ふるいプロセッサは、通知を再試行する必要性を持つべきではありません。したがって、この方法の実装は、最初の送信SMTPメッセージを送信するための再試行のための通常のメカニズムを使用すべきです。通知メッセージが送信されると、これは複数の通知が発生する可能性がある、とのメッセージループの危険性を高めるよう、実装は、それを再送信してはなりません。
Implementations SHOULD consider limiting notification messages. In particular, they SHOULD NOT sent duplicate notifications to the same address from the same script invocation. Batching of notifications within a short time to the same address might also be useful. Different implementations, different administrative domains, and different users may have different needs; configuration options are a good idea here.
実装は、通知メッセージを制限することを検討してください。特に、それらは、同じスクリプトの呼び出しから同じアドレスに重複する通知を送信しない（SHOULD NOT）。同じアドレスに短い時間内に通知のバッチ処理も有用であるかもしれません。異なる実装、異なる管理ドメイン、および異なるユーザーが異なるニーズを有していてもよいです。設定オプションは、ここでは良いアイデアです。
The overall notification message is composed using the following guidelines (see [RFC5322] for references to message header fields):
全体的な通知メッセージは、（メッセージヘッダーフィールドへの参照のために[RFC5322]を参照）は、以下のガイドラインを使用して構成されています。
o If the envelope sender of the triggering message is empty, the envelope sender of the notification message MUST be empty as well, to avoid message loops. Otherwise, the envelope sender of the notification message SHOULD be set to the value of the ":from" tag to the notify action, if one is specified, has email address syntax, and is valid according to the implementation-specific security checks (see Section 3.3 of [Notify]). If ":from" is not specified or is not valid, the envelope sender of the notification message SHOULD be set either to the envelope "to" field from the triggering message, as used by Sieve, or to an email address associated with the notification system, at the discretion of the implementation. This MUST NOT be overridden by a "from" URI header, and any such URI header MUST be ignored.
トリガメッセージのエンベロープ送信者が空の場合は、O、通知メッセージのエンベロープ送信者はメッセージループを避けるために、同様に空でなければなりません。それ以外の場合は、通知メッセージのエンベロープ送信者がの値に設定する必要があります：タグ「から」通知アクションに1が指定されている場合は、メールアドレスの構文を持ち、（参照実装固有のセキュリティチェックに応じて有効とされます[通知]のセクション3.3）。場合は「：からは、」指定されていないか、有効ではありませんが、通知メッセージのエンベロープ送信者は、トリガメッセージから、ふるいによって使用されるように、または通知に関連付けられているメールアドレスにフィールド「に」封筒のいずれかに設定されるべきである（SHOULD）システム、実装の裁量で。これは、「から」URIヘッダによって上書きしてはいけません、そして、そのようなURIヘッダは無視しなければなりません。
o The envelope recipient(s) of the notification message SHOULD be set to the address(es) specified in the URI (including any URI headers where the hname is "to" or "cc").
oを通知メッセージのエンベロープ受信者（複数可）（hnameが「する」または「CC」である任意のURIヘッダを含む）URIで指定されたアドレス（ES）に設定されるべきです。
o The header field "Auto-Submitted: auto-notified" MUST be included in the notification message (see Section 2.7.1). This is to reduce the likelihood of message loops, by tagging this as an automatically generated message. Among other results, it will inform other notification systems not to generate further notifications. mailto URI headers with hname "auto-submitted" are considered unsafe and MUST be ignored.
oをヘッダ・フィールド「自動提出：自動通知は、」（セクション2.7.1を参照）、通知メッセージに含まれなければなりません。これは自動的に生成されたメッセージとしてこれをタグ付けすることにより、メッセージループの可能性を低減することです。他の結果の中でも、さらに通知を生成していない他の通知システムに通知します。 mailto URIヘッダhnameで「自動提出は、」安全でないとみなされ、無視しなければなりません。
o The "From:" header field of the notification message SHOULD be set to the value of the ":from" tag to the notify action, if one is specified, has email address syntax, and is valid according to the implementation-specific security checks (see Section 3.3 of [Notify]). If ":from" is not specified or is not valid, the "From:" header field of the notification message SHOULD be set either to the envelope "to" field from the triggering message, as used by Sieve, or to an email address associated with the notification system, at the discretion of the implementation. This MUST NOT be overridden by a "from" URI header, and any such URI header MUST be ignored.
O「から」：インプリメンテーション固有のセキュリティに係るタグ通知アクションに、一方が指定されている場合、有している電子メールアドレスの構文、及び有効である「から」通知メッセージのヘッダフィールドの値に設定する必要がありますチェック（[通知]のセクション3.3を参照）。 「：からは、」指定されていないか、有効ではありませんが、「から：」場合は、通知メッセージのヘッダフィールドは、トリガメッセージから、ふるいによって使用されるように、または電子メールアドレスへのフィールド「に」封筒のいずれかに設定されるべきである（SHOULD）実装の裁量で、通知システムに関連付けられています。これは、「から」URIヘッダによって上書きしてはいけません、そして、そのようなURIヘッダは無視しなければなりません。
o The "To:" header field of the notification message SHOULD be set to the address(es) specified in the URI (including any URI headers where the hname is "to").
○「：を」通知メッセージのヘッダフィールドは、（hname「が」任意URIヘッダを含む）URIで指定されたアドレス（ES）に設定されるべきです。
o The "Subject:" field of the notification message SHOULD contain the value defined by the ":message" tag, as described in [Notify]. If there is no ":message" tag and there is a "subject" header on the URI, then that value SHOULD be used. If the "subject" header is also absent, the subject SHOULD be retained from the triggering message. Note that Sieve [Variables] can be used to advantage here, as shown in the example in Section 3.
記載されているように[通知]、タグ：「メッセージ」の通知メッセージのフィールドにより定義された値を含むべきである：「件名」O。 「メッセージ」全く存在しない場合、タグは、およびURIの「件名」ヘッダが存在し、その値を使用すべきです。 「被験体」ヘッダも存在しない場合、被験者は、トリガメッセージから保持されるべきです。第3の例に示すようにふるい[変数]、ここで有利に用いることができることに留意されたいです。
o The "References:" field of the notification message MAY be set to refer to the triggering message, and MAY include references from the triggering message.
「参考文献：」O通知メッセージのフィールドは、トリガメッセージを参照するように設定されてもよく、トリガメッセージからの参照を含むかもしれません。
o If the mailto URI contains a "body" header, the value of that header SHOULD be used as the body of the notification message. If there is no "body" header, it is up to the implementation whether to leave the body empty or to use an excerpt of the original message.
MAILTO URIが「本体」ヘッダが含まれている場合は、O、そのヘッダの値は、通知メッセージのボディとして使用されるべきです。いかなる「本体」ヘッダが存在しない場合は、空のボディを残すか、元のメッセージの抜粋を使用するかどうかの実装次第です。
o The "Received:" fields from the triggering message MAY be retained in the notification message, as these could provide useful trace/ history/diagnostic information. The "Auto-Submitted" header field MUST be placed above these (see Section 2.7.1). URI headers with hname "received" are considered unsafe, and MUST be ignored.
O「受信：」これらは有用なトレース/歴史/診断情報を提供できるよう、トリガメッセージのフィールドは、通知メッセージに保持することができます。 「自動提出」ヘッダフィールド（セクション2.7.1を参照）、これらの上方に配置されなければなりません。 hnameとURIヘッダは、安全でないとみなされ、無視されなければならない「受信しました」。
o Other header fields of the notification message that are normally related to an individual new message (such as "Message-ID" and "Date") are generated for the notification message in the normal manner, and MUST NOT be copied from the triggering message. Any URI headers with those names MUST be ignored. Further, the "Date" header serves as the notification timestamp defined in [Notify].
O正常（例えば、「メッセージID」と「日付」など）は、個々の新しいメッセージに関連する通知メッセージの他のヘッダフィールドは、通常の方法で通知メッセージのために生成され、トリガメッセージからコピーしてはいけません。それらの名前を持つ任意のURIヘッダは無視しなければなりません。さらに、「日付」ヘッダは、で定義された通知のタイムスタンプとして機能する[通知]。
o All other header fields of the notification message either are as specified by URI headers, or have implementation-specific values; their values are not defined here. It is suggested that the implementation capitalize the first letter of URI headers and add a space character after the colon between the mail header name and value when adding URI headers to the message, to be consistent with common practice in email headers.
通知メッセージのすべての他のヘッダフィールドOのいずれかURIヘッダで指定された、または実装固有の値を有するようです。それらの値は、ここで定義されていません。実装がURIヘッダの最初の文字を大文字にし、電子メールのヘッダの一般的な慣行と一致するように、メッセージにURIヘッダを追加するときメールヘッダ名と値の間にコロンの後に空白文字を追加することが示唆されます。
The header field "Auto-Submitted: auto-notified" MUST be included in the notification message (see [RFC3834]). The "Auto-Submitted" header field is considered a "trace field", similar to "Received" header fields (see [RFC5321]). If the implementation retains the "Received" fields from the triggering message (see above), the "Auto-Submitted" field MUST be placed above those "Received" fields, serving as a boundary between the ones from the triggering message and those that will be part of the notification message.
ヘッダフィールド「自動提出：自動通知は、」通知メッセージ（[RFC3834]を参照）に含まれなければなりません。 「自動提出」ヘッダフィールドは、「トレース・フィールド」、同様の「受信」するためのヘッダーフィールド（[RFC5321]を参照）であると考えられます。実装がトリガメッセージから「受信」フィールド（上記参照）を保持している場合、「自動提出」フィールドは、トリガメッセージからのものとなりますそれらの間の境界として、これらの「受信」フィールドの上に置かなければなりません通知メッセージの一部です。
The header field "Auto-Submitted: auto-notified" MUST include one or both of the following parameters:
ヘッダフィールド「自動提出：自動通知された」次のパラメータのいずれかまたは両方を含める必要があります。
o owner-email - specifies an email address, determined by the implementation, of the owner of the Sieve script that generated this notification. If specified, it might be used to identify or contact the script's owner. The parameter attribute is "owner-email", and the parameter value is a quoted string containing an email address, as defined by "addr-spec" in [RFC5322]. Example: Auto-Submitted: auto-notified; owner-email="me@example.com"
Oオーナ - メール - この通知を生成したSieveスクリプトの所有者の実装によって決定されたメールアドレスを、指定します。指定された場合、特定またはスクリプトの所有者に連絡するために使用される可能性があります。パラメータ属性は、「所有者の電子メール」であり、[RFC5322]に「ADDR仕様」によって定義されるパラメータ値は、電子メールアドレスを含む引用符で囲まれた文字列です。例：自動提出：自動通知。所有者のメール=「me@example.com」
o owner-token - specifies an opaque token, determined by the implementation, that the administrative domain of the owner of the Sieve script that generated this notification can use to identify the owner. This might be used to allow identification of the owner while protecting the owner's privacy. The parameter attribute is "owner-token", and the parameter value is as defined by "token" in [RFC3834]. Example: Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W
O所有者トークン - この通知を生成しSieveスクリプトの所有者の管理ドメイン所有者を識別するために使用することができ、実装によって決定される不透明トークンを、指定します。これは、所有者のプライバシーを保護しながら、所有者の識別を可能にするために使用される可能性があります。パラメータ属性は、「所有者トークン」であり、[RFC3834]に「トークン」によって定義されたパラメータ値です。例：自動提出：自動通知。所有者トークン= af3NN2pK5dDXI0W
See Section 5 for discussion of possible uses of these parameters.
これらのパラメータの使用可能性についての議論については、セクション5を参照してください。
Triggering message (received by recipient@example.org):
メッセージをトリガする（recipient@example.orgによって受信されました）：
Return-Path: <knitting-bounces@example.com> Received: from mail.example.com by mail.example.org for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500 Received: from hobbies.example.com by mail.example.com for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800 Message-ID: <1234567.89ABCDEF@example.com> Date: Wed, 07 Dec 2005 10:59:19 +0100 Precedence: list List-Id: Knitting Mailing List <knitting.example.com> Sender: knitting-bounces@example.com Errors-To: knitting-bounces@example.com From: "Jeff Smith" <jeff@hobbies.example.com> To: "Knitting Mailing List" <knitting@example.com> Subject: [Knitting] A new sweater
リターンパスを<knitting-bounces@example.com>受信：mail.example.comからmail.example.orgで<recipient@example.org>のために。受信水曜日、2005年12月7日午前5時08分02秒-0500：hobbies.example.comから<knitting@example.com>のためにmail.example.comにより、水曜日、2005年12月7日午前2時00分26秒-0800メッセージ-ID：<1234567.89ABCDEF@example.com>日：水曜日、2005年12月7日10時59分19秒0100の優先順位：リストリスト-ID：編みメーリングリスト<編み.example.comと>送信者：knitting-bounces@example.comエラー-TO：knitting-bounces@example.comから： "ジェフ・スミス" <jeff@hobbies.example.com>へ： "編み物はメーリングリスト" <編み@ example.com>件名：[ニット]新しいセーター
I just finished a great new sweater!
私は偉大な新しいセーターを完成しました！
Sieve script (run on behalf of recipient@example.org):
（recipient@example.orgの代わりに実行）ふるいスクリプト：
require ["enotify", "variables"];
[ "enotify"、 "変数"]が必要です。
if header :contains "list-id" "knitting.example.com" { if header :matches "Subject" "[*] *" { notify :message "From ${1} list: ${2}" :importance "3" "mailto:0123456789@sms.example.net?to=backup@example.com"; } }
"[*] *" {通知件名 "：メッセージを "$ {1}リストから：{2} $"：重要度を「： "リストID" が "knitting.example.com" マッチ{もし、ヘッダ" を含む：ヘッダは、IF 3" "？のmailto：0123456789@sms.example.net to=backup@example.com"。 }}
Notification message:
通知メッセージ：
Auto-Submitted: auto-notified; owner-email="recipient@example.org" Received: from mail.example.com by mail.example.org for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500 Received: from hobbies.example.com by mail.example.com for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800 Date: Wed, 7 Dec 2005 05:08:55 -0500 Message-ID: <A2299BB.FF7788@example.org> From: recipient@example.org To: 0123456789@sms.example.net, backup@example.com Subject: From Knitting list: A new sweater
自動提出：自動通知。受信した所有者のメール=「recipient@example.org」：mail.example.comからmail.example.orgで<recipient@example.org>のために。受信水曜日、2005年12月7日午前5時08分02秒-0500：hobbies.example.comから<knitting@example.com>のためにmail.example.comにより、水曜日、2005年12月7日午前2時00分26秒-0800日：水曜日、2005年12月7日午前5時08分55秒-0500メッセージ-ID：<A2299BB.FF7788@example.org>から：recipient@example.orgへ：0123456789 @ sms.example.net、backup@example.com件名：編み物リストから：新しいセーター
Note that:
ご了承ください：
o Fields such as "Message-ID:" and "Date:" were generated afresh for the notification message, and do not relate to the triggering message.
Oフィールドは、「メッセージID：」のように「日付：」通知メッセージのために新たに生成された、及びトリガメッセージに関連していません。
o Additional "Received:" fields will be added to the notification message in transit; the ones shown were copied from the triggering message. New ones will be added above the Auto-Submitted: header field.
Oの追加「受信：」フィールドは、輸送中の通知メッセージに追加されます。図示のものは、トリガメッセージからコピーされました。ヘッダフィールド：新しいものは、自動提出の上に追加されます。
o If this message should appear at the mail.example.org server again, the server can use the presence of a "mail.example.org" received line to recognize that. The Auto-Submitted header field is also present to tell the server to avoid sending another notification, and it includes an optional owner-email parameter for identification.
このメッセージが再びmail.example.orgサーバーで表示されます場合は、O、サーバーはそれを認識するために、「mail.example.org」受信ラインの存在を使用することができます。自動提出ヘッダフィールドは、別の通知を送信することを避けるためにサーバに指示することも存在し、それは識別のためのオプションの所有者の電子メールパラメータを含みます。
This specification introduces no specific internationalization issues that are not already addressed in [Sieve] and in [Notify].
この仕様は、すでに[ふるい]にし、[通知]で扱われていない具体的な国際化の問題を紹介しません。
Sending a notification is comparable with forwarding mail to the notification recipient. Care must be taken when forwarding mail automatically, to ensure that confidential information is not sent into an insecure environment.
通知を送信すると、通知の受信者にメールを転送するに匹敵するものです。メールを転送する際に注意が機密情報を安全でない環境に送信されないことを保証するために、自動的に取られなければなりません。
The automated sending of email messages exposes the system to mail loops, which can cause operational problems. Implementations of this specification MUST protect themselves against mail loops; see Section 2.7 for discussion of this and some suggestions. Other possible mitigations for mail loops involve types of service limitations. For example, the number of notifications generated for a single user might be limited to no more than, say, 30 in a 60-minute period. Of course, this technique presents its own problems, in that the actual rate-limit must be selected carefully, to allow most legitimate situations in the given environment. Even with careful selection, it's inevitable that there will be false positives -- and false negatives.
自動化された電子メールメッセージの送信は、操作上の問題を引き起こす可能性がループを郵送するためのシステムを公開しています。この仕様の実装は、メールループから身を守る必要があります。これといくつかの提案の議論については、セクション2.7を参照してください。メールのループのための他の可能な緩和策は、サービスの制限の種類を伴います。例えば、単一のユーザのために生成される通知の数は、これ以上の60分間に30、たとえば、以下に限定される可能性があります。もちろん、この技術は、独自の問題を提示し、その中で実際のレート制限は、与えられた環境の中で最も合法的な状況を可能にするために、慎重に選択しなければなりません。および偽陰性 - でも、慎重に選択すると、それは偽陽性があることは避けられないのです。
Ultimately, human intervention may be necessary to re-enable notifications that have been disabled because a loop was detected, or to terminate a very slow loop that's under the automatic-detection radar. Administrative mechanisms MUST be available to handle these sorts of situations.
最終的には、人間の介入は、ループが検出されたため、無効になっている通知を再度有効にする、または自動検出レーダーの下だが非常に遅いループを終了する必要があるかもしれません。管理メカニズムは、状況のこれらの種類を処理するために利用可能でなければなりません。
Email addresses specified as recipients of notifications might not be owned by the entity that owns the Sieve script. As a result, a notification recipient could wind up as the target of unwanted notifications, either through intent (using scripts to mount a mail-bomb attack) or by accident (an address was mistyped or has been reassigned). The situation is arguably no worse than any other in which a recipient gets unwanted email, and some of the same mechanisms can be used in this case. But those deploying this extension have to be aware of the potential extra problems here, where scripts might be created through means that do not adequately validate email addresses, and such scripts might then be forgotten and left to run indefinitely.
通知の受信者として指定されたメールアドレスは、Sieveスクリプトを所有しているエンティティによって所有されない場合があります。その結果、通知受信者のいずれかの意図を介して、または事故により（アドレスが入力ミスされたか、再割り当てされています）（メール爆弾攻撃をマウントするためのスクリプトを使用して）、不要な通知の対象として羽目になる可能性があります。状況は、受信者が迷惑メールを取得し、同じメカニズムのいくつかはこの場合に使用することができる他のどのよりも間違いなく何も悪いことではありません。スクリプトが適切にメールアドレスを検証しませんし、そのようなスクリプトは、その後忘れや無期限に実行するために残されるかもしれない手段を介して作成される可能性がありますどこでも、この拡張機能を導入するものは、ここに潜在的な余分な問題を認識する必要があります。
In particular, note that the Auto-Submitted header field is required to include a value that a recipient can use when contacting the source domain of the notification message (see Section 2.7.1). That value will allow the domain to track down the script's owner and have the script corrected or disabled. Domains that enable this extension MUST be prepared to respond to such complaints, in order to limit the damage caused by a faulty script.
具体的には、自動提出ヘッダフィールドは、通知メッセージの送信元ドメインと接触するとき、受信者が使用できる値を含むことが必要であることに注意してください（セクション2.7.1を参照）。この値は、ドメインは、スクリプトの所有者を追跡し、スクリプトを修正または無効になっていることができます。この拡張機能を有効にするドメインは、障害のあるスクリプトによる被害を制限するために、そのような苦情に対応するために準備しなければなりません。
Problems can also show up if notification messages are sent to a gateway into another service, such as SMS. Information from the email message is often lost in the gateway translation; and in this case, critical information needed to avoid loops, to contact the script owner, and to resolve other problems might be lost. Developers of email gateways should consider these issues, and try to preserve as much information as possible, including what appears in email trace headers and the Auto-Submitted header field.
通知メッセージはSMSなど、他のサービスへのゲートウェイに送信された場合にも、問題が現れることができます。電子メールメッセージからの情報は、多くの場合、ゲートウェイ翻訳で失われます。この場合には、ループを回避するために、スクリプトの所有者に連絡して、他の問題を解決するために必要な重要な情報が失われる可能性があります。電子メールゲートウェイの開発者は、これらの問題を考慮し、電子メールのトレースヘッダと自動提出ヘッダフィールドに表示されるものを含め、できるだけ多くの情報を、保存しようとする必要があります。
Additional security considerations are discussed in [Sieve] and in [Notify].
追加のセキュリティ上の考慮事項は、[ふるい]にし、[通知]で議論されています。
The following template specifies the IANA registration of the Sieve notification mechanism specified in this document:
次のテンプレートは、この文書で指定されたふるい通知メカニズムのIANA登録を指定します。
To: iana@iana.org Subject: Registration of new Sieve notification mechanism Mechanism name: mailto Mechanism URI: RFC2368 Mechanism-specific options: none Permanent and readily available reference: RFC 5436 Person and email address to contact for further information: Michael Haardt <michael.haardt@freenet.ag>
To：iana@iana.org件名：新しいふるい通知メカニズムメカニズム名の登録：mailtoのメカニズムURI：RFC2368メカニズム固有のオプション：なし永久かつ容易に入手可能な参照：RFC 5436人と詳細のために連絡する電子メールアドレス：マイケルHaardt < michael.haardt@freenet.ag>
This information should be added to the list of Sieve notification mechanisms available from http://www.iana.org.
この情報は、http://www.iana.orgから入手ふるい通知メカニズムのリストに追加する必要があります。
Because [RFC3834] does not define a registry for new keywords used in the Auto-Submitted header field, we define one here, which has been created and is available from http://www.iana.org. Keywords are registered using the "Specification Required" policy [IANA].
[RFC3834]は自動提出ヘッダーフィールドで使用される新しいキーワードの登録を定義していないので、我々が作成され、http://www.iana.orgから入手可能ですされている、ここでは1を定義します。キーワードは「仕様が必要である」というポリシー[IANA]を使用して登録されています。
This defines the template to be used to register new keywords. Initial entries to this registry follow in Section 6.3.
これは、新しいキーワードを登録する際に使用するテンプレートを定義します。このレジストリへの初期エントリは、セクション6.3で従ってください。
To: iana@iana.org Subject: Registration of new auto-submitted header field keyword Keyword value: [the text value of the field] Description: [a brief explanation of the purpose of this value] Parameters: [list any keyword-specific parameters, specify their meanings, specify whether they are required or optional; use "none" if there are none]
To：iana@iana.org件名：新しい自動提出ヘッダフィールドキーワードキーワード値の登録：説明[フィールドのテキスト値]：パラメータ[この値の目的の簡単な説明]：[リストの任意のキーワード固有パラメータは、彼らが必須またはオプションされているかどうかを指定し、その意味を指定します。何も存在しない場合は「none」を使用しません]
Permanent and readily available reference: [identifies the specification that defines the value being registered] Contact: [name and email address to contact for further information]
永久的かつ容易に入手可能な参照：[詳細のために連絡する名前とメールアドレス]：問い合わせ[登録されている値を定義する仕様を識別する]
The following are the initial keywords that have been registered in the "Auto-Submitted Header Field Keywords" registry, available from http://www.iana.org.
次http://www.iana.orgから入手可能な「自動提出ヘッダーフィールドキーワード」レジストリに登録されている最初のキーワードが、あります。
Keyword value: no Description: Indicates that a message was NOT automatically generated, but was created by a human. It is the equivalent to the absence of an Auto-Submitted header altogether. Parameters: none Permanent and readily available reference: RFC3834 Contact: Keith Moore <moore@network-heretics.com>
キーワード値：なし説明：メッセージが自動的に生成されませんでしたが、人間によって作成されたことを示します。これは完全に自動提出ヘッダが存在しないことと等価です。パラメータ：なし永久かつ容易に入手可能な参照：RFC3834連絡先：キース・ムーア<moore@network-heretics.com>
Keyword value: auto-generated Description: Indicates that a message was generated by an automatic process, and is not a direct response to another message. Parameters: none Permanent and readily available reference: RFC3834 Contact: Keith Moore <moore@network-heretics.com>
キーワード値：自動生成説明：メッセージが自動プロセスによって生成されたことを示し、別のメッセージに直接応答しません。パラメータ：なし永久かつ容易に入手可能な参照：RFC3834連絡先：キース・ムーア<moore@network-heretics.com>
Keyword value: auto-replied Description: Indicates that a message was automatically generated as a direct response to another message. Parameters: none Permanent and readily available reference: RFC3834 Contact: Keith Moore <moore@network-heretics.com>
キーワード値：自動答えた説明：メッセージは自動的に別のメッセージへの直接の応答として生成されたことを示します。パラメータ：なし永久かつ容易に入手可能な参照：RFC3834連絡先：キース・ムーア<moore@network-heretics.com>
Keyword value: auto-notified Description: Indicates that a message was generated by a Sieve notification system. Parameters: owner-email, owner-token. At least one is required; both refer to the owner of the Sieve script that generated this message. See the relevant RFC for details. Permanent and readily available reference: RFC 5436 Contact: Michael Haardt <michael.haardt@freenet.ag>
キーワード値：自動通知説明：メッセージがふるい通知システムによって生成されたことを示します。パラメータ：所有者、電子メール、所有者トークン。少なくとも一方が必要です。両方このメッセージを生成Sieveスクリプトの所有者を参照してください。詳細については、関連するRFCを参照してください。恒久的かつ容易に利用可能な参照：RFC 5436お問い合わせ：マイケルHaardt <michael.haardt@freenet.ag>
[IANA] 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月。
[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月。
[Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
。。[通知]メルニコフ、A.、エド、Leiba、B.、エド、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]ムーア、K.、 "電子メールへの自動応答のための提言"、RFC 3834、2004年8月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[ふるい]ギュンター、P.、エド。 。とT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[MAILTO]ホフマン、P.、Masinter、L.、およびJ. Zawinski、 "mailtoのURLスキーム"、RFC 2368、1998年7月。
[RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[変数]オム、K.、 "ふるい拡張：変数"、RFC 5229、2008年1月。
Authors' Addresses
著者のアドレス
Barry Leiba 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
Michael Haardt freenet.de GmbH Willstaetter Str. 13 Duesseldorf, NRW 40549 Germany
マイケルHaardt freenet.de社WillstaetterのStr。13デュッセルドルフNRW 40549ドイツ
Phone: +49 241 53087 520 EMail: michael.haardt@freenet.ag
電話：+49 241 53087 520 Eメール：michael.haardt@freenet.ag