draft-ietf-sieve-notify-mailto-03.txt   draft-ietf-sieve-notify-mailto-04.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 7, 2008 freenet AG Expires: January 9, 2008 freenet AG
July 6, 2007 July 8, 2007
Sieve Notification Mechanism: mailto Sieve Notification Mechanism: mailto
draft-ietf-sieve-notify-mailto-03 draft-ietf-sieve-notify-mailto-04
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 7, 2008. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
1.2. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Conventions used in this document . . . . . . . . . . . . . 3
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 4 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . . 4
2.2. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 4 2.2. Test notify_method_capability . . . . . . . . . . . . . . . 4
2.3. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4 2.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 4
2.4. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 4 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4
2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4 2.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 4
2.6. Other Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4
2.7. Other Definitions . . . . . . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Internationalization Considerations . . . . . . . . . . . . 8 4. Internationalization Considerations . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 12
7.2. Non-Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Non-Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The [Notify] extension to the [Sieve] mail filtering language is a The [Notify] extension to the [Sieve] mail filtering language is a
framework for providing notifications by employing URIs to specify framework for providing notifications by employing URIs to specify
the notification mechanism. This document defines how [mailto] URIs the notification mechanism. This document defines how [mailto] URIs
are used to generate notifications by e-mail. are used to generate notifications by e-mail.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
The mailto mechanism results in the sending of a new email message (a The mailto mechanism results in the sending of a new email message (a
"notification message") to notify a recipient about a "triggering "notification message") to notify a recipient about a "triggering
message". message".
2.1. Notify parameter "method" 2.1. Notify parameter "method"
The mailto notification mechanism uses standard mailto URIs as The mailto notification mechanism uses standard mailto URIs as
specified in [mailto]. specified in [mailto].
2.2. Notify tag ":from" 2.2. Test notify_method_capability
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.
2.3. Notify tag ":from"
The :from tag overrides the default sender of the notification The :from tag overrides the default sender of the notification
message. message. "Sender", here, refers to the value used in the [RFC2822]
"From" header. Implementations MAY also use this value in the
[RFC2821] "MAIL FROM" command (the "envelope sender"), or they may
prefer to establish a mailbox that receives bounces from notification
messages.
2.3. Notify tag ":importance" 2.4. Notify tag ":importance"
The :importance tag has no special meaning for this notification The :importance tag has no special meaning for this notification
mechanism, and this specification puts no restriction on its use. mechanism, and this specification puts no restriction on its use.
Implementations MAY use the value of :importance to set a priority or Implementations MAY use the value of :importance to set a priority or
importance indication on the notification message. 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).
2.4. Notify tag ":options" 2.5. Notify tag ":options"
This tag is not used by the mailto method. This tag is not used by the mailto method.
2.5. Notify tag ":message" 2.6. Notify tag ":message"
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.
2.7. Other Definitions
Because the receipt of an email message is generating another email
message, implementations MUST take steps to avoid mail loops. The
notification message contains the "Received:" fields from the
triggering message to allow loop detection as described in [RFC2821],
section 6.2. The implementation 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.
The overall notification message is composed using the following
guidelines (see [RFC2822] for references to message header fields):
o Unless overridden by ":from", the "From:" header field and the o Unless overridden by ":from", the "From:" header field and the
envelope sender of the notification message are set either to the envelope sender of the notification message are set either to the
envelope "to" field from the triggering message, as used by Sieve, envelope "to" field from the triggering message, as used by Sieve,
or to a fixed address (so it "comes from the notification or to a fixed address (so it "comes from the notification
system"), at the discretion of the implementation. system"), at the discretion of the implementation. This may not
be overridden by a "from" URI header, and any such URI header will
be ignored.
o The "To:" header field and the envelope recipient(s) of the o The "To:" header field and the envelope recipient(s) of the
notification message are set to the address(es) specified in URI notification message are set to the address(es) specified in the
(including any URI headers where the hname is "to"). URI (including any URI headers where the hname is "to").
o The "Received:" field from the triggering message are retained in
the notification message, as these may help detect and prevent
mail loops.
o The "Subject:" field of the notification message contains the o The "Subject:" field of the notification message contains the
value defined by the :message notify tag, as described in value defined by the :message notify tag, as described in
[Notify]. If there is no :message tag, the subject is retained [Notify]. If there is no :message tag and there is a "subject"
from the triggering message. Note that Sieve [Variables] can be header on the URI, then that value is used. If that is also
used to advantage here, as shown in the example in Section 3. absent, the subject is retained from the triggering message. Note
that Sieve [Variables] can be used to advantage here, as shown in
the example in Section 3.
o If the mailto URI contains a "body" header, the value of that o If the mailto URI contains a "body" header, the value of that
header is used as the body of the notification message. If there header is used as the body of the notification message. If there
is no "body" header, it is up to the implementation to leave the is no "body" header, it is up to the implementation whether to
body empty or use an excerpt of the original message. leave the body empty or to use an excerpt of the original message.
o URI headers with hname "received" are considered unsafe and are o The "Received:" fields from the triggering message are retained in
ignored if specified. URI headers with hname "from" and "subject" the notification message, as these may help detect and prevent
conflict with the implictly set values from and are ignored if mail loops. URI headers with hname "received" are considered
specified. unsafe, and will be ignored.
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. Any URI headers with those names are ignored. Further,
the "Date" header serves as the notification timestamp defined in
[Notify].
o All other header fields of the notification message either are as o All other header fields of the notification message either are as
specified by URI headers, or have implementation-specific values; specified by URI headers, or have implementation-specific values;
their values are not defined here. It is suggested that the their values are not defined here. It is suggested that the
implementation capitalizes the first letter of URI headers and implementation capitalizes the first letter of URI headers and
adds a space character after the colon between the mail header adds a space character after the colon between the mail header
name and value when adding URI headers to the message. name and value when adding URI headers to the message.
2.6. Other Definitions
Because the receipt of an email message is generating another email
message, implementations MUST take steps to avoid mail loops. The
notification message contains the "Received:" fields from the
triggering message to allow loop detection as described in [RFC2821],
section 6.2. The implementation MUST allow messages with empty
envelope senders to trigger notifications.
3. Examples 3. Examples
Triggering message (received by recipient@example.org): Triggering message (received by recipient@example.org):
Return-Path: <knitting-bounces@example.com> Return-Path: <knitting-bounces@example.com>
Received: from mail.example.com by mail.example.org Received: from mail.example.com by mail.example.org
for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500 for <recipient@example.org>; Wed, 7 Dec 2005 05:08:02 -0500
Received: from hobbies.example.com by mail.example.com Received: from hobbies.example.com by mail.example.com
for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800 for <knitting@example.com>; Wed, 7 Dec 2005 02:00:26 -0800
Message-ID: <1234567.89ABCDEF@example.com> Message-ID: <1234567.89ABCDEF@example.com>
skipping to change at page 9, line 14 skipping to change at page 10, 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. specification MUST protect themselves against mail loops (see
Section 2.7).
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
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:
To: iana@iana.org To: iana@iana.org
skipping to change at page 11, line 16 skipping to change at page 12, line 16
7.1. Normative References 7.1. Normative References
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
Martin, "Sieve Extension: Notifications", work in Martin, "Sieve Extension: Notifications", work in
progress, draft-ietf-sieve-notify, December 2005. progress, draft-ietf-sieve-notify, December 2005.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", work in Filtering Language", work in
progress, draft-ietf-sieve-3028bis, November 2005. progress, draft-ietf-sieve-3028bis, November 2005.
[mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto [mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
URL scheme", RFC 2368, July 1998. URL scheme", RFC 2368, July 1998.
7.2. Non-Normative References 7.2. Non-Normative References
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
 End of changes. 24 change blocks. 
50 lines changed or deleted 94 lines changed or added

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