draft-ietf-sieve-notify-mailto-01.txt   draft-ietf-sieve-notify-mailto-02.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
Expires: April 19, 2007 M. Haardt Intended status: Standards Track M. Haardt
freenet.de AG Expires: September 8, 2007 freenet.de AG
October 16, 2006 March 7, 2007
Sieve Notification Mechanism: mailto Sieve Notification Mechanism: mailto
draft-ietf-sieve-notify-mailto-01 draft-ietf-sieve-notify-mailto-02
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 April 19, 2007. This Internet-Draft will expire on September 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 tag ":method" . . . . . . . . . . . . . . . . . . . . 4 2.1. Notify tag ":method" . . . . . . . . . . . . . . . . . . . . 4
2.2. Notify tag ":priority" . . . . . . . . . . . . . . . . . . . 4 2.2. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 4
2.3. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4 2.3. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 4
2.4. Other Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.4. Other Definitions . . . . . . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Internationalization Considerations . . . . . . . . . . . . 9 4. Internationalization Considerations . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 11
7.2. Non-Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Non-Normative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 13
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.
1.2. Conventions used in this document 1.2. Conventions used in this document
Conventions for notations are as in [Sieve] section 1.1, including Conventions for notations are as in [Sieve] section 1.1, including
the use of [Kwds] and the use of [ABNF]. the use of [Kwds].
[[no abnf ref: We don't actually need the ABNF reference...]]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [Kwds]. document are to be interpreted as described in [Kwds].
2. Definition 2. Definition
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".
skipping to change at page 4, line 26 skipping to change at page 4, line 26
accepted. accepted.
[[Barry ignored: Should we ignore them, or should their presence be [[Barry ignored: Should we ignore them, or should their presence be
an error?]] an error?]]
[[Michael ignored: The mailto URI spec allows for either. I like [[Michael ignored: The mailto URI spec allows for either. I like
ignoring them more, because it fits into the picture of ignoring a ignoring them more, because it fits into the picture of ignoring a
different sender for other message-generating actions, if it is different sender for other message-generating actions, if it is
forbidden.]] forbidden.]]
2.2. Notify tag ":priority" [[Barry ignored 2: My thinking, when I suggested error, was that a
script that explicitly tried to use them, even when this spec says
"don't", would be broken. I see no reasonable scenario through which
the mailto URI could be derived in a computed way that would include
those fields, and thus justify ignoring them rather than considering
them an error.]]
The :priority tag has no special meaning for this notification 2.2. Notify tag ":importance"
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 :priority 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.
2.3. Notify tag ":message" 2.3. Notify tag ":message"
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 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
[[Barry from: It might be better in some cases for the system"), at the discretion of the implementation.
notification to "come from" the sender of the triggering message.
In other cases it might be better for all notifications to come
from the "mail system". I think we should define a way to specify
the behaviour here, perhaps with a new notify tag.]]
[[Michael from: Variables could perform both. Does that
suffice?]]
[[Barry sender: Should we also provide a mapping or setting for
the "Sender:" header field?]]
[[Michael sender: If that is required, the base spec should allow [[Barry sender: Alternative: the "from" is set to the envelope to,
it for all methods, like it offers ":from".]] and the "sender" is set to the adderss of the notification
system?]]
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 URI
(including any URI headers where the hname is "to"). (including any URI headers where the hname is "to").
[[Barry to: I'd like some way to specify that the To: header
should be retained from the triggering message. In fact, I'd like
a way to say that ALL headers be retained.]]
[[Michael to: Retaining the original "To:" field could easily
result in a loop. I think we need to define the focus of this
method: Generic SMTP message generation, or "just notifications"
over SMTP?]]
o The "Received:" field from the triggering message are retained in o The "Received:" field from the triggering message are retained in
the notification message, as these may help detect and prevent the notification message, as these may help detect and prevent
mail loops. 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, the subject is retained
from the triggering message. Note that Sieve [Variables] can be from the triggering message. Note that Sieve [Variables] can be
used to advantage here, as shown in the example in Section 3. used to advantage here, as shown in the example in Section 3.
skipping to change at page 5, line 40 skipping to change at page 5, line 31
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.
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, the body of the notification message is is no "body" header, the body of the notification message is
empty. empty.
[[Barry body: I'd like some way to specify that the body contain [[Barry body: I'd like some way to specify that the body contain
the body of the triggering message.]] some excerpt from the body of the triggering message. Does anyone
else want this, or should we just say "Barry's being silly," and
[[Michael body: Can variables do that? I don't know.]] forget it?]]
2.4. Other Definitions 2.4. 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
notification message contains the "Received:" fields from the notification message contains the "Received:" fields from the
triggering message to allow loop detection as described in [RFC2821], triggering message to allow loop detection as described in [RFC2821],
section 6.2. The implementation MUST allow messages with empty section 6.2. The implementation MUST allow messages with empty
envelope senders to trigger notifications. envelope senders to trigger notifications.
[[Barry loops: We should say more about this...]]
[[Michael loops: Ok now? Informal reference or normative? Could you
add it?]]
[[comment 1: Mailto URIs focus on the message, not its submission. [[comment 1: Mailto URIs focus on the message, not its submission.
There is no way to specify envelope parameters, require encryption or There is no way to specify envelope parameters, require encryption or
authentication. Sure enough there is more than SMTP, so mailto is authentication. Sure enough there is more than SMTP, so mailto is
fine not to address this specific transport, but should we ever need fine not to address this specific transport, but should we ever need
more, it can not be specified as URI header, because there is no room more, it can not be specified as URI header, because there is no room
in its namespace.]] in its namespace.]]
[[comment 2: Michael tried to get documentation on SMTP-SMS gateways,
but everybody operating one keeps the specification like a precious
secret. From experiments made some years ago, we know some gateways
ignore all messages with empty envelope senders, some do not
implement MIME and some ignore the body.]]
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 7, line 34 skipping to change at page 6, line 34
I just finished a great new sweater! I just finished a great new sweater!
Sieve script (run on behalf of recipient@example.org): Sieve script (run on behalf of recipient@example.org):
require ["notify", "variables"]; require ["notify", "variables"];
if header :contains "list-id" "knitting.example.com" { if header :contains "list-id" "knitting.example.com" {
if header :matches "Subject" "[*] *" { if header :matches "Subject" "[*] *" {
notify :method "mailto:0123456789@sms.example.net" notify :method "mailto:0123456789@sms.example.net"
:message "From ${1} list: ${2}" :message "From ${1} list: ${2}"
:priority "3"; :importance "3";
} }
} }
Notification message: Notification message:
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
Date: Wed, 7 Dec 2005 05:08:55 -0500 Date: Wed, 7 Dec 2005 05:08:55 -0500
skipping to change at page 12, line 26 skipping to change at page 11, line 26
[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] Duerst, M., Masinter, L., and J. Zawinski, "The mailto URI [mailto] Duerst, M., Masinter, L., and J. Zawinski, "The mailto URI
scheme", work in progress, draft-duerst-mailto-bis, scheme", work in progress, draft-duerst-mailto-bis,
February 2005. February 2005.
7.2. Non-Normative References 7.2. Non-Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001. RFC 2821, April 2001.
[Variables] [Variables]
Homme, K., "Sieve Extension: Variables", work in Homme, K., "Sieve Extension: Variables", work in
progress, draft-ietf-sieve-variables, October 2005. progress, draft-ietf-sieve-variables, October 2005.
Authors' Addresses Authors' Addresses
Barry Leiba Barry Leiba
skipping to change at page 14, line 7 skipping to change at page 13, line 7
freenet.de AG freenet.de AG
Willstaetter Str. 13 Willstaetter Str. 13
Duesseldorf, NRW 40549 Duesseldorf, NRW 40549
Germany Germany
Phone: +49 241 53087 520 Phone: +49 241 53087 520
Email: michael.haardt@freenet-ag.de Email: michael.haardt@freenet-ag.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 14, line 47 skipping to change at page 13, line 47
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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 26 change blocks. 
69 lines changed or deleted 43 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/