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
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.
版权所有（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail.
本文档描述了用于通知的Sieve扩展的概要文件，以允许通过电子邮件发送通知。
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
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]邮件过滤语言的[Notify]扩展是一个通过使用URI指定通知机制来提供通知的框架。本文档定义了如何使用[mailto]URI通过电子邮件生成通知。
Conventions for notations are as in Section 1.1 of [Sieve], including the use of [Kwds].
符号惯例如[SIVE]第1.1节所述，包括使用[KWD]。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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_能力测试可能会返回“是”或“否”，前提是筛选处理器能够确定通知消息的收件人是否在线并登录。否则，测试将为此通知方法返回“maybe”。
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]“邮件发件人”命令（“信封发件人”）中使用此值，或者它们可能更喜欢建立一个接收通知消息反弹的邮箱。
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".
对于包含“Auto Submitted:”标头字段且其值不是“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.
在短时间内到达同一地址也可能有用。不同的实现、不同的管理域和不同的用户可能有不同的需求；配置选项在这里是个好主意。
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 如果触发消息的信封发送者为空，则通知消息的信封发送者也必须为空，以避免消息循环。否则，通知消息的信封发送者应设置为“：from”标记到通知操作的值，如果指定了，则具有电子邮件地址语法，并且根据特定于实现的安全检查是有效的（参见[通知]第3.3节）。如果“：from”未指定或无效，则通知消息的信封发件人应设置为触发消息中的信封“to”字段（由SIVE使用），或设置为与通知系统相关的电子邮件地址（由实施部门自行决定）。这不能被“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中指定的地址（包括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 通知消息中必须包含标题字段“自动提交：自动通知”（见第2.7.1节）。这是为了减少消息循环的可能性，将其标记为自动生成的消息。除其他结果外，它将通知其他通知系统不要生成进一步的通知。hname为“自动提交”的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”标记的值（如果指定了），该字段具有电子邮件地址语法，并且根据特定于实现的安全检查有效（请参阅[notify]的第3.3节）。如果未指定“：from”或“：from”无效，则通知消息的“from:”标题字段应设置为触发消息的信封“to”字段（由SIVE使用），或与通知系统相关的电子邮件地址（由实施部门自行决定）。这不能被“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中指定的地址（包括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 通知消息的“主题：”字段应包含“：message”标记定义的值，如[Notify]中所述。如果没有“：message”标记，并且URI上有一个“subject”头，那么应该使用该值。如果“主题”标题也不存在，则应在触发消息中保留主题。请注意，如第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包含“body”头，则该头的值应用作通知消息的主体。如果没有“body”头，则由实现决定是将body留空还是使用原始消息的摘录。
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 触发消息中的“Received:”字段可以保留在通知消息中，因为这些字段可以提供有用的跟踪/历史记录/诊断信息。“自动提交”标题字段必须位于这些字段上方（见第2.7.1节）。带有hname“received”的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"
通知消息中必须包含标题字段“自动提交：自动通知”（请参见[RFC3834]）。“自动提交”标题字段被视为“跟踪字段”，类似于“已接收”
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.
标题字段（请参见[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 所有者电子邮件-指定生成此通知的筛选脚本的所有者的电子邮件地址，该地址由实现确定。如果指定，它可能用于标识或联系脚本的所有者。参数属性是“所有者电子邮件”，参数值是一个包含电子邮件地址的带引号的字符串，如[RFC5322]中的“addr spec”所定义。示例：自动提交：自动通知；所有者电子邮件=”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]中的“令牌”定义。示例：自动提交：自动通知；所有者令牌=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
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):
筛选脚本（代表运行）recipient@example.org):
require ["enotify", "variables"];
要求[“enotify”，“variables”]；
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";
}
}
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
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 为通知消息重新生成了“消息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节。邮件循环的其他可能缓解措施涉及服务限制的类型。例如，在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.
如果将通知消息发送到网关进入其他服务（如SMS），也会出现问题。在网关翻译过程中，来自电子邮件的信息经常丢失；在这种情况下，避免循环、联系脚本所有者以及解决其他问题所需的关键信息可能会丢失。电子邮件网关的开发人员应该考虑这些问题，并尽量保存尽可能多的信息，包括出现在电子邮件跟踪头和自动提交的标题字段中。
Additional security considerations are discussed in [Sieve] and in [Notify].
其他安全注意事项在[SIVE]和[Notify]中讨论。
The following template specifies the IANA registration of the Sieve notification mechanism specified in this document:
以下模板规定了本文件中规定的SIVE通知机制的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
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]
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-异端网站>
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-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-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>
关键字值：自动通知说明：表示消息是由筛选通知系统生成的。参数：所有者电子邮件、所有者令牌。至少需要一个；两者都指生成此消息的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.
[通知]Melnikov，A.，Ed.，Leiba，B.，Ed.，Segmuller，W.，和T.Martin，“筛选电子邮件过滤：通知扩展”，RFC 54352009年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 38342004年8月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.，Ed.和T.Showalter，Ed.，“筛：电子邮件过滤语言”，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，“mailto URL方案”，RFC 2368，1998年7月。
[RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，Ed.，“简单邮件传输协议”，RFC5212008年10月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[变量]霍姆，K.，“筛网扩展：变量”，RFC 52292008年1月。
Authors' Addresses
作者地址
Barry Leiba IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Barry Leiba IBM T.J.Watson研究中心美国纽约州霍桑市天际大道19号，邮编10532
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
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街13号，邮编40549
Phone: +49 241 53087 520
EMail: michael.haardt@freenet.ag
Phone: +49 241 53087 520
EMail: michael.haardt@freenet.ag