[要約] RFC 5436は、Sieve通知メカニズムの一部であるmailtoについての要約と目的をまとめたものです。mailtoは、Sieveスクリプトによって生成された通知メッセージをメールアドレスに送信するための方法です。このRFCの目的は、mailtoの仕様と使用方法を明確にすることです。
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
ふるい通知メカニズム：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.
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
概要
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.
[Sieve]メールフィルタリング言語の[通知]拡張機能は、URIを使用して通知メカニズムを指定することにより、通知を提供するためのフレームワークです。このドキュメントでは、urisが電子メールで通知を生成するために使用される方法を定義しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 Urisには、ヘッダー名と値で構成されるヘッダーフィールドが含まれている場合があります。これらのヘッダーフィールドは、「メッセージヘッダー」と区別するために「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テストは、「はい」または「いいえ」を返すことができます。Sieveプロセッサが通知メッセージの受信者がオンラインでログインしているかどうかを確実に判断できる場合にのみです。通知方法。
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] "mail from" command（ "envelope sender"）からこの値を使用したり、通知メッセージからバウンスを受信するメールボックスを確立することを好む場合があります。
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).
「：重要」タグは、この通知メカニズムに対する特別な意味を持たず、この仕様はその使用に制限を与えません。実装は、「：重要性」の値を使用して、通知メッセージに優先または重要性の表示を設定する場合があります（おそらく視覚的表示、または非標準的ではあるが一般的に使用されるメッセージヘッダーの1つを使用する場合）。
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.
電子メールメッセージの受信は別の電子メールメッセージを生成しているため、実装はメールループを避けるための手順を実行する必要があります。「Auto-Submitted：」の必要なインクルージョンは、メッセージ構成ガイドラインで説明されているように、ループの検出と回避にも役立ちます。
Implementations SHOULD NOT trigger notifications for messages containing "Auto-Submitted:" header fields with any value other than "No".
実装は、「no」以外の値を持つ「auto-submitted： "ヘッダーフィールド」を含むメッセージの通知をトリガーしないでください。
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.
この通知方法は、通知メッセージの配信にストアアンドフォワードシステムを使用するため、Sieveプロセッサは通知を再試行する必要はありません。したがって、この方法の実装は、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.
実装は、通知メッセージの制限を検討する必要があります。特に、同じスクリプトの呼び出しから同じアドレスに複製通知を送信してはなりません。同じアドレスまでの短い時間内に通知のバッチングも役立つ場合があります。異なる実装、異なる管理ドメイン、および異なるユーザーが異なるニーズを持っている場合があります。ここでは、構成オプションが良い考えです。
The overall notification message is composed using the following guidelines (see [RFC5322] for references to message header fields):
全体的な通知メッセージは、メッセージヘッダーフィールドへの参照については、次のガイドラインを使用して構成されています。
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 トリガーメッセージのエンベロープ送信者が空の場合、メッセージループを避けるために、通知メッセージのエンベロープ送信者も空でなければなりません。それ以外の場合は、通知メッセージのエンベロープ送信者は、「から」の値に設定する必要があります。「Tag」へのnotifyアクションまで、指定されている場合は、電子メールアドレスの構文があり、実装固有のセキュリティチェックに従って有効です（参照[通知]のセクション3.3）。"：from"が指定されていない、または有効でない場合、通知メッセージのエンベロープ送信者は、シーブで使用されているように、トリガーメッセージからのエンベロープ「フィールド」に設定するか、通知に関連付けられた電子メールアドレスに設定する必要がありますシステム、実装の裁量で。これは、「From」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 通知メッセージのエンベロープ受信者は、URIで指定されたアドレス（ES）に設定する必要があります（HNAMEが「TO」または「CC」であるURIヘッダーを含む）。
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 ヘッダーフィールド「Auto-Submitted：auto-notified」は、通知メッセージに含める必要があります（セクション2.7.1を参照）。これは、これを自動的に生成されたメッセージとしてタグ付けすることにより、メッセージループの可能性を減らすためです。他の結果の中でも、他の通知システムに、さらなる通知を生成しないように通知します。hname「auto-submitted」を備えたmailto uriヘッダーは安全ではないと見なされ、無視する必要があります。
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 「from：」通知メッセージのヘッダーフィールドは、「タグから通知アクションへの値」に設定する必要があります。（[通知]のセクション3.3を参照）。"：from"が指定されていない、または有効でない場合、「from：」通知メッセージのヘッダーフィールドは、封筒に「envelope」に設定する必要があります。実装の裁量で、通知システムに関連付けられています。これは、「From」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").
o 「to：」通知メッセージのヘッダーフィールドは、URIで指定されたアドレス（es）に設定する必要があります（hnameが「to」であるURIヘッダーを含む）。
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 「件名：」のフィールドは、[notify]に記載されているように、「：メッセージ」タグによって定義された値を含める必要があります。「：メッセージ」タグがなく、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.
o Mailto URIに「ボディ」ヘッダーが含まれている場合、そのヘッダーの値は通知メッセージの本文として使用する必要があります。「ボディ」ヘッダーがない場合、ボディを空にしたままにするか、元のメッセージの抜粋を使用するかは実装次第です。
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ヘッダーは無視する必要があります。さらに、「日付」ヘッダーは、[Notify]で定義された通知タイムスタンプとして機能します。
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.
ヘッダーフィールド「Auto-Submitted：auto-notified」は、通知メッセージに含める必要があります（[RFC3834]を参照）。「自動サビッド」ヘッダーフィールドは、「受信」ヘッダーフィールドと同様の「トレースフィールド」と見なされます（[RFC5321]を参照）。実装がトリガーメッセージから「受信」フィールドを保持している場合（上記を参照）、「自動サブミットされた」フィールドは、「受信」フィールドの上に配置する必要があり、トリガーメッセージからの境界として機能する必要があります。通知メッセージの一部になります。
The header field "Auto-Submitted: auto-notified" MUST include one or both of the following parameters:
ヘッダーフィールド「Auto-Submitted：auto-notified」には、次のパラメーターの1つまたは両方を含める必要があります。
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 所有者email-この通知を生成したシーブスクリプトの所有者の実装によって決定された電子メールアドレスを指定します。指定されている場合は、スクリプトの所有者を識別または連絡するために使用される場合があります。パラメーター属性は「所有者エメイル」であり、パラメーター値は[RFC5322]の「ADDR-Spec」で定義されているように、電子メールアドレスを含む引用文字です。例：Auto-Submitted：Auto-Notified;所有者email = "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 オーナートークン - この通知を生成したシーブスクリプトの所有者の管理ドメインが、所有者を識別するために使用できる、実装によって決定された不透明なトークンを指定します。これは、所有者のプライバシーを保護しながら所有者の識別を可能にするために使用される場合があります。パラメーター属性は「所有者トークン」であり、パラメーター値は[RFC3834]の「トークン」で定義されています。例：Auto-Submitted：Auto-Notified;所有者-Token = AF3NN2PK5DDXI0W
See Section 5 for discussion of possible uses of these parameters.
これらのパラメーターの使用の可能性についての議論については、セクション5を参照してください。
Triggering message (received by recipient@example.org):
メッセージをトリガーする（recionient@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
I just finished a great new sweater!
素晴らしい新しいセーターを終えたところです！
Sieve script (run on behalf of recipient@example.org):
Sieve Script（Recosion@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";
}
}
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
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 「Message-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.
o このメッセージがmail.example.orgサーバーに再度表示される場合、サーバーは「mail.example.org」の存在を使用して、それを認識するために行を使用できます。また、自動補助ヘッダーフィールドが存在しているため、サーバーに別の通知を送信しないように指示します。これには、識別用のオプションの所有者メールパラメーターが含まれています。
This specification introduces no specific internationalization issues that are not already addressed in [Sieve] and in [Notify].
この仕様では、[Sieve]および[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を参照してください。メールループの他の可能な緩和には、サービスの制限の種類が含まれます。たとえば、1人のユーザーに対して生成された通知の数は、たとえば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.
通知の受信者として指定された電子メールアドレスは、シーブスクリプトを所有するエンティティが所有していない場合があります。その結果、通知受信者は、意図（メール爆弾攻撃を取り付けるためのスクリプトを使用）を通じて、または偶然（住所が誤っているか、再割り当てされている）を通じて、不要な通知のターゲットとして巻き上げられる可能性があります。状況は間違いなく、受信者が不要な電子メールを受け取る他のどのものよりも悪いことではなく、この場合に同じメカニズムの一部を使用できます。しかし、この拡張機能を展開する人は、ここでの潜在的な追加の問題を認識する必要があります。ここでは、スクリプトが電子メールアドレスを適切に検証しない手段を通じて作成される可能性があり、そのようなスクリプトは忘れられ、無期限に実行される可能性があります。
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.
通知メッセージがGatewayに送信された場合、SMSなどの別のサービスに問題が表示される場合も、問題が表示されます。電子メールメッセージからの情報は、ゲートウェイの翻訳でしばしば失われます。この場合、ループを避け、スクリプトの所有者に連絡し、他の問題を解決するために必要な重要な情報が失われる可能性があります。電子メールゲートウェイの開発者は、これらの問題を考慮し、電子メールトレースヘッダーや自動補助ヘッダーフィールドに表示されるものなど、できるだけ多くの情報を保存しようとする必要があります。
Additional security considerations are discussed in [Sieve] and in [Notify].
追加のセキュリティ上の考慮事項は、[Sieve]および[Notify]で説明されています。
The following template specifies the IANA registration of the Sieve notification mechanism specified in this document:
次のテンプレートは、このドキュメントで指定されたSIEVE通知メカニズムの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>
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から入手可能です。キーワードは、「必要な仕様」ポリシー[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]
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連絡先：Keith Moore <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>
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>
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>
キーワード値：Auto-Notified説明：メッセージがふるい通知システムによって生成されたことを示します。パラメーター：所有者 - メール、オーナートークン。少なくとも1つが必要です。どちらもこのメッセージを生成したSieveスクリプトの所有者を参照しています。詳細については、関連するRFCを参照してください。恒久的で容易に利用できるリファレンス：RFC 5436連絡先：Michael 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[Notify] Melnikov、A.、Ed。、Leiba、B.、Ed。、Segmuller、W。、およびT. Martin、「Sieve Emailフィルタリング：通知の拡張」、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] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[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月。
[mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[Mailto] Hoffman、P.、Masinter、L。、およびJ. Zawinski、「The Mailto URL Scheme」、RFC 2368、1998年7月。
[RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[変数] Homme、K。、「Sieve Extension：変数」、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スカイラインドライブホーソーン、ニューヨーク10532米国
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Michael Haardt freenet.de GmbH Willstaetter Str. 13 Duesseldorf, NRW 40549 Germany
Michael Haardt freenet.de gmbh Willstaetter str。13 Duesseldorf、NRW 40549ドイツ
Phone: +49 241 53087 520
EMail: michael.haardt@freenet.ag