draft-ietf-sieve-notify-mailto-08.txt   draft-ietf-sieve-notify-mailto-09.txt 
Sieve Working Group B. Leiba Sieve Working Group B. Leiba
Internet-Draft IBM T.J. Watson Research Center Internet-Draft IBM T.J. Watson Research Center
Intended status: Standards Track M. Haardt Intended status: Standards Track M. Haardt
Expires: January 10, 2009 freenet AG Expires: April 4, 2009 freenet AG
July 9, 2008 October 1, 2008
Sieve Notification Mechanism: mailto Sieve Notification Mechanism: mailto
draft-ietf-sieve-notify-mailto-08 draft-ietf-sieve-notify-mailto-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2009. This Internet-Draft will expire on April 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes a profile of the Sieve extension for This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail. notifications, to allow notifications to be sent by electronic mail.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 5, line 13 skipping to change at page 5, line 13
excessively long value. excessively long value.
2.7. Other Definitions 2.7. Other Definitions
Because the receipt of an email message is generating another email Because the receipt of an email message is generating another email
message, implementations MUST take steps to avoid mail loops. The message, implementations MUST take steps to avoid mail loops. The
REQUIRED inclusion of an "Auto-Submitted:" field, as described in the REQUIRED inclusion of an "Auto-Submitted:" field, as described in the
message composition guidelines, will also help in loop detection and message composition guidelines, will also help in loop detection and
avoidance. avoidance.
Implementations MUST NOT trigger notifications for messages Implementations SHOULD NOT trigger notifications for messages
containing "Auto-Submitted:" header fields with any value other than containing "Auto-Submitted:" header fields with any value other than
"No". "No".
Implementations MUST allow messages with empty envelope senders to Implementations MUST allow messages with empty envelope senders to
trigger notifications. trigger notifications.
Because this notification method uses a store-and-forward system for Because this notification method uses a store-and-forward system for
delivery of the notification message, the Sieve processor should not delivery of the notification message, the Sieve processor should not
have a need to retry notifications. Therefore, implementations of have a need to retry notifications. Therefore, implementations of
this method SHOULD use normal mechanisms for submitting SMTP messages this method SHOULD use normal mechanisms for submitting SMTP messages
skipping to change at page 6, line 5 skipping to change at page 6, line 5
"from" URI header, and any such URI header MUST be ignored. "from" URI header, and any such URI header MUST be ignored.
o The envelope recipient(s) of the notification message SHOULD be o The envelope recipient(s) of the notification message SHOULD be
set to the address(es) specified in the URI (including any URI set to the address(es) specified in the URI (including any URI
headers where the hname is "to" or "cc"). headers where the hname is "to" or "cc").
o The header field "Auto-Submitted: auto-notified" MUST be included o The header field "Auto-Submitted: auto-notified" MUST be included
in the notification message (see Section 2.7.1). This is to in the notification message (see Section 2.7.1). This is to
reduce the likelihood of message loops, by tagging this as an reduce the likelihood of message loops, by tagging this as an
automatically generated message. Among other results, it will automatically generated message. Among other results, it will
cause the notification message not to generate further inform other notification systems not to generate further
notifications. mailto URI headers with hname "auto-submitted" are notifications. mailto URI headers with hname "auto-submitted" are
considered unsafe and MUST be ignored. considered unsafe and MUST be ignored.
o The "From:" header field of the notification message SHOULD be set o The "From:" header field of the notification message SHOULD be set
to the value of the ":from" parameter to the notify action, if one to the value of the ":from" parameter to the notify action, if one
is specified, has email address syntax and is valid according to is specified, has email address syntax and is valid according to
the implementation specific security checks (see Section 3.3 of the implementation specific security checks (see Section 3.3 of
[Notify]). If ":from" is not specified or is not valid, the [Notify]). If ":from" is not specified or is not valid, the
"From:" header field of the notification message SHOULD be set "From:" header field of the notification message SHOULD be set
either to the envelope "to" field from the triggering message, as either to the envelope "to" field from the triggering message, as
skipping to change at page 11, line 14 skipping to change at page 11, line 14
5. Security Considerations 5. Security Considerations
Sending a notification is comparable with forwarding mail to the Sending a notification is comparable with forwarding mail to the
notification recipient. Care must be taken when forwarding mail notification recipient. Care must be taken when forwarding mail
automatically, to ensure that confidential information is not sent automatically, to ensure that confidential information is not sent
into an insecure environment. into an insecure environment.
The automated sending of email messages exposes the system to mail The automated sending of email messages exposes the system to mail
loops, which can cause operational problems. Implementations of this loops, which can cause operational problems. Implementations of this
specification MUST protect themselves against mail loops (see specification MUST protect themselves against mail loops; see
Section 2.7). 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, and even with
careful selection it's inevitable that there will be false positives
-- and false negatives.
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.
Additional security considerations are discussed in [Sieve] and in Additional security considerations are discussed in [Sieve] and in
[Notify]. [Notify].
6. IANA Considerations 6. IANA Considerations
6.1. Registration of notification mechanism 6.1. Registration of notification mechanism
The following template specifies the IANA registration of the Sieve The following template specifies the IANA registration of the Sieve
notification mechanism specified in this document: notification mechanism specified in this document:
skipping to change at page 16, line 44 skipping to change at line 551
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 7 change blocks. 
12 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/