< draft-ietf-sieve-notify-mailto-09.txt		draft-ietf-sieve-notify-mailto-10.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		Updates: 3834 (if approved) M. Haardt
	Expires: April 4, 2009 freenet AG		Intended status: Standards Track freenet.de GmbH
	October 1, 2008		Expires: June 7, 2009 December 4, 2008
	Sieve Notification Mechanism: mailto		Sieve Notification Mechanism: mailto
	draft-ietf-sieve-notify-mailto-09		draft-ietf-sieve-notify-mailto-10
	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 4, 2009.		This Internet-Draft will expire on June 7, 2009.
	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 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	2.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4		2.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4
	2.7. Other Definitions . . . . . . . . . . . . . . . . . . . . 5		2.7. Other Definitions . . . . . . . . . . . . . . . . . . . . 5
	2.7.1. The Auto-Submitted header field . . . . . . . . . . . . . 7		2.7.1. The Auto-Submitted header field . . . . . . . . . . . . . 7
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Internationalization Considerations . . . . . . . . . . . 10		4. Internationalization Considerations . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
	6.1. Registration of notification mechanism . . . . . . . . . . 12		6.1. Registration of notification mechanism . . . . . . . . . . 13
	6.2. New registry for Auto-Submitted header field keywords . . 12		6.2. New registry for Auto-Submitted header field keywords . . 13
	6.3. Initial registration of Auto-Submitted header field		6.3. Initial registration of Auto-Submitted header field
	keywords . . . . . . . . . . . . . . . . . . . . . . . . . 12		keywords . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . 14		7. References . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 14		7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	7.2. Non-Normative References . . . . . . . . . . . . . . . . . 14		7.2. Non-Normative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . 17
	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 14 ¶		skipping to change at page 4, line 14 ¶
	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".
	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]. 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".
	2.2. Test notify_method_capability		2.2. Test notify_method_capability
	The notify_method_capability test for "online" may return "yes" or		The notify_method_capability test for "online" may return "yes" or
	"no" only if the Sieve processor can determine with certainty whether		"no" only if the Sieve processor can determine with certainty whether
	or not the recipients of the notification message are online and		or not the recipients of the notification message are online and
	logged in. Otherwise, the test returns "maybe" for this notification		logged in. Otherwise, the test returns "maybe" for this notification
	method.		method.
	2.3. Notify tag ":from"		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. "Sender", here, refers to the value used in the [RFC2822]		message. "Sender", here, refers to the value used in the [RFC5322]
	"From" header. Implementations MAY also use this value in the		"From" header. Implementations MAY also use this value in the
	[RFC2821] "MAIL FROM" command (the "envelope sender"), or they may		[RFC5321] "MAIL FROM" command (the "envelope sender"), or they may
	prefer to establish a mailbox that receives bounces from notification		prefer to establish a mailbox that receives bounces from notification
	messages.		messages.
	2.4. 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 (perhaps a visual		importance indication on the notification message (perhaps a visual
	indication, or perhaps making use of one of the non-standard but		indication, or perhaps making use of one of the non-standard but
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 32 ¶
	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
	and for retrying the initial submission. Once the notification		and for retrying the initial submission. Once the notification
	message is submitted, implementations MUST NOT resubmit it, as this		message is submitted, implementations MUST NOT resubmit it, as this
	is likely to result in multiple notifications, and increases the		is likely to result in multiple notifications, and increases the
	danger of message loops.		danger of message loops.
	The overall notification message is composed using the following		The overall notification message is composed using the following
	guidelines (see [RFC2822] for references to message header fields):		guidelines (see [RFC5322] for references to message header fields):
	o If the envelope sender of the triggering message is empty, the		o If the envelope sender of the triggering message is empty, the
	envelope sender of the notification message MUST be empty as well,		envelope sender of the notification message MUST be empty as well,
	to avoid message loops. Otherwise, the envelope sender of the		to avoid message loops. Otherwise, the envelope sender of the
	notification message SHOULD be set to the value of the ":from"		notification message SHOULD be set to the value of the ":from"
	parameter to the notify action, if one is specified, has email		parameter to the notify action, if one is specified, has email
	address syntax and is valid according to the implementation		address syntax and is valid according to the implementation
	specific security checks (see Section 3.3 of [Notify]). If		specific security checks (see Section 3.3 of [Notify]). If
	":from" is not specified or is not valid, the envelope sender of		":from" is not specified or is not valid, the envelope sender of
	the notification message SHOULD be set either to the envelope "to"		the notification message SHOULD be set either to the envelope "to"
	field from the triggering message, as used by Sieve, or to an		field from the triggering message, as used by Sieve, or to an
	email address associated with the notification system, at the		email address associated with the notification system, at the
	discretion of the implementation. This MAY NOT be overridden by a		discretion of the implementation. This MUST NOT be overridden by
	"from" URI header, and any such URI header MUST be ignored.		a "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
	inform other notification systems not to generate further		inform other notification systems not to generate further
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 22 ¶
	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
	used by Sieve, or to an email address associated with the		used by Sieve, or to an email address associated with the
	notification system, at the discretion of the implementation.		notification system, at the discretion of the implementation.
	This MAY NOT be overridden by a "from" URI header, and any such		This MUST NOT be overridden by a "from" URI header, and any such
	URI header MUST be ignored.		URI header MUST be ignored.
	o The "To:" header field of the notification message SHOULD be set		o The "To:" header field of the notification message SHOULD be set
	to the address(es) specified in the URI (including any URI headers		to the address(es) specified in the URI (including any URI headers
	where the hname is "to").		where the hname is "to").
	o The "Subject:" field of the notification message SHOULD contain		o The "Subject:" field of the notification message SHOULD contain
	the value defined by the :message notify tag, as described in		the value defined by the :message notify tag, as described in
	[Notify]. If there is no :message tag and there is a "subject"		[Notify]. If there is no :message tag and there is a "subject"
	header on the URI, then that value SHOULD be used. If that is		header on the URI, then that value SHOULD be used. If that is
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 25 ¶
	implementation capitalize the first letter of URI headers and add		implementation capitalize the first letter of URI headers and add
	a space character after the colon between the mail header name and		a space character after the colon between the mail header name and
	value when adding URI headers to the message, to be consistent		value when adding URI headers to the message, to be consistent
	with common practice in email headers.		with common practice in email headers.
	2.7.1. The Auto-Submitted header field		2.7.1. The Auto-Submitted header field
	The header field "Auto-Submitted: auto-notified" MUST be included in		The header field "Auto-Submitted: auto-notified" MUST be included in
	the notification message (see [RFC3834]). The "Auto-Submitted"		the notification message (see [RFC3834]). The "Auto-Submitted"
	header field is considered a "trace field", similar to "Received"		header field is considered a "trace field", similar to "Received"
	header fields (see [RFC2821]). If the implementation retains the		header fields (see [RFC5321]). If the implementation retains the
	"Received" fields from the triggering message (see above), the "Auto-		"Received" fields from the triggering message (see above), the "Auto-
	Submitted" field MUST be placed above those "Received" fields,		Submitted" field MUST be placed above those "Received" fields,
	serving as a boundary between the ones from the triggering message		serving as a boundary between the ones from the triggering message
	and those that will be part of the notification message.		and those that will be part of the notification message.
	The auto-notified Auto-Submitted field MAY include one or both of the		The auto-notified Auto-Submitted field MUST include one or both of
	following OPTIONAL parameters:		the following parameters:
	o owner-email - specifies an email address of the owner of the Sieve		o owner-email - specifies an email address of the owner of the Sieve
	script that generated this notification. If specified, it might		script that generated this notification. If specified, it might
	be used to identify or contact the script's owner. The parameter		be used to identify or contact the script's owner. The parameter
	attribute is "owner-email", and the parameter value is a quoted		attribute is "owner-email", and the parameter value is a quoted
	string containing an email address, as defined by "addr-spec" in		string containing an email address, as defined by "addr-spec" in
	[RFC2822]. Example:		[RFC5322]. Example:
	Auto-Submitted: auto-notified; owner-email="me@example.com"		Auto-Submitted: auto-notified; owner-email="me@example.com"
	o owner-token - specifies an opaque token that the administrative		o owner-token - specifies an opaque token that the administrative
	domain of the owner of the Sieve script that generated this		domain of the owner of the Sieve script that generated this
	notification can identify the owner with. This might be used to		notification can identify the owner with. This might be used to
	allow identification of the owner while protecting the owner's		allow identification of the owner while protecting the owner's
	privacy. The parameter attribute is "owner-token", and the		privacy. The parameter attribute is "owner-token", and the
	parameter value is as defined by "token" in [RFC3834]. Example:		parameter value is as defined by "token" in [RFC3834]. Example:
	Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W		Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W
			See Section 5 for discussion of possible uses of these parameters.
	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 11, line 31 ¶		skipping to change at page 11, line 31 ¶
	most legitimate situations in the given environment, and even with		most legitimate situations in the given environment, and even with
	careful selection it's inevitable that there will be false positives		careful selection it's inevitable that there will be false positives
	-- and false negatives.		-- and false negatives.
	Ultimately, human intervention may be necessary to re-enable		Ultimately, human intervention may be necessary to re-enable
	notifications that have been disabled because a loop was detected, or		notifications that have been disabled because a loop was detected, or
	to terminate a very slow loop that's under the automatic-detection		to terminate a very slow loop that's under the automatic-detection
	radar. Administrative mechanisms MUST be available to handle these		radar. Administrative mechanisms MUST be available to handle these
	sorts of situations.		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.
			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
			preseve as much information as possible, including what appears in
			email trace headers and Auto-Submitted.
	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 14, line 9 ¶		skipping to change at page 15, line 9 ¶
	Parameters: owner-email, owner-token. Both optional, both refer to		Parameters: owner-email, owner-token. Both optional, both refer to
	the owner of the Sieve script that generated this message. See the		the owner of the Sieve script that generated this message. See the
	relevant RFC for details.		relevant RFC for details.
	Standards Track/IESG-approved experimental RFC number: this RFC		Standards Track/IESG-approved experimental RFC number: this RFC
	Contact: Michael Haardt <michael.haardt@freenet.ag>		Contact: Michael Haardt <michael.haardt@freenet.ag>
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[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 2007.		progress, draft-ietf-sieve-notify, December 2007.
	[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
	April 2001.
	[RFC3834] Moore, K., "Recommendations for Automatic Responses to		[RFC3834] Moore, K., "Recommendations for Automatic Responses to
	Electronic Mail", RFC 3834, August 2004.		Electronic Mail", RFC 3834, August 2004.
			[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
			October 2008.
	[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email		[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
	Filtering Language", RFC 5228, January 2008.		Filtering Language", RFC 5228, January 2008.
	[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
	[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol",
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		RFC 5321, October 2008.
	October 1998.
	[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
	RFC 2821, April 2001.
	[Variables]		[Variables]
	Homme, K., "Sieve Extension: Variables", RFC 5229,		Homme, K., "Sieve Extension: Variables", RFC 5229,
	January 2008.		January 2008.
	Authors' Addresses		Authors' Addresses
	Barry Leiba		Barry Leiba
	IBM T.J. Watson Research Center		IBM T.J. Watson Research Center
	19 Skyline Drive		19 Skyline Drive
	Hawthorne, NY 10532		Hawthorne, NY 10532
	US		US
	Phone: +1 914 784 7941		Phone: +1 914 784 7941
	Email: leiba@watson.ibm.com		Email: leiba@watson.ibm.com
	Michael Haardt		Michael Haardt
	freenet AG		freenet.de GmbH
	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		Email: michael.haardt@freenet.ag
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
End of changes. 23 change blocks.
	35 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/