< draft-ietf-lemonade-profile-06.txt		draft-ietf-lemonade-profile-07.txt >
	Internet Draft: Lemonade Profile S. H. Maes		Internet Draft: Lemonade Profile S. H. Maes
	Document: draft-ietf-lemonade-profile-06.txt A. Melnikov		Document: draft-ietf-lemonade-profile-07.txt A. Melnikov
	Expires: May 2006 November 2005		Expires: July 2006 January 2006
	Lemonade Profile		Lemonade Profile
	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.
	skipping to change at line 45 ¶		skipping to change at line 45 ¶
	constrained in memory, bandwidth, processing power, or other areas)		constrained in memory, bandwidth, processing power, or other areas)
	to efficiently use IMAP and Submission to access and submit mail.		to efficiently use IMAP and Submission to access and submit mail.
	This includes the ability to forward received mail without needing to		This includes the ability to forward received mail without needing to
	download and upload the mail, to optimize submission and to		download and upload the mail, to optimize submission and to
	efficiently resynchronize in case of loss of connectivity with the		efficiently resynchronize in case of loss of connectivity with the
	server.		server.
	The Lemonade profile relies upon extensions to IMAP and Mail		The Lemonade profile relies upon extensions to IMAP and Mail
	Submission protocols; specifically URLAUTH and CATENATE IMAP protocol		Submission protocols; specifically URLAUTH and CATENATE IMAP protocol
	[RFC3501] extensions and BURL extension to the SUBMIT protocol		[RFC3501] extensions and BURL extension to the SUBMIT protocol
	[RFC2476].		[SUBMIT].
	Conventions used in this document		Conventions used in this document
	In examples, "M:", "I:" and "S:" indicate lines sent by the client		In examples, "M:", "I:" and "S:" indicate lines sent by the client
	messaging user agent, IMAP e-mail server and SMTP submit server		messaging user agent, IMAP e-mail server and SMTP submit server
	respectively.		respectively.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
			All examples in this document are optimized for Lemonade use and
			might not represent examples of proper protocol usage for a general
			use Submit/IMAP client. In particular examples assume that Lemonade
			Submit and IMAP servers support all Lemonade extensions described in
			this document, so they don't show how to deal with absence of an
			extension.
	Table of Contents		Table of Contents
	Status of this Memo 1		Status of this Memo 1
	Abstract 1		Abstract 1
	Conventions used in this document 2		Conventions used in this document 2
	Table of Contents 2		Table of Contents 2
	1. Introduction 3		1. Introduction 3
	2. Forward without download 4		2. Forward without download 4
	2.1. Motivations 4		2.1. Motivations 4
	2.2. Message Sending Overview 4		2.2. Message Sending Overview 4
	skipping to change at line 106 ¶		skipping to change at line 113 ¶
	Authors Addresses 23		Authors Addresses 23
	Intellectual Property Statement 23		Intellectual Property Statement 23
	1. Introduction		1. Introduction
	Lemonade provides enhancements to Internet email to support diverse		Lemonade provides enhancements to Internet email to support diverse
	service environments.		service environments.
	This document describes the lemonade profile that includes:		This document describes the lemonade profile that includes:
	- "Forward without download" that describes exchanges between		- "Forward without download" that describes exchanges between
	Lemonade clients and servers to allow to submit new email messages		Lemonade clients and servers to allow to submit new email
	incorporating content which resides on locations external to the client.		messages incorporating content which resides on locations
	- Quick mailbox resynchronization using [CONDSTORE].		external to the client.
	- Several IMAP and SMTP extensions that allow to save bandwidth		- Quick mailbox resynchronization using [CONDSTORE].
	and/or number of round trips required to send/receive data.		- Several IMAP and SMTP extensions that allow saving bandwidth
			and/or number of round trips required to send/receive data.
	The organization of this document is as follows. Section 2 describes		The organization of this document is as follows. Section 2 describes
	the Forward without download. Section 3 describes additional SMTP		the Forward without download. Section 3 describes additional SMTP
	extensions that must be supported by all Lemonade Submission servers.		extensions that must be supported by all Lemonade Submission servers.
	Section 4 describes IMAP quick resynchronization.		Section 4 describes IMAP quick resynchronization.
	2. Forward without download		2. Forward without download
	2.1. Motivations		2.1. Motivations
	The advent of client/server email using the [RFC3501], [RFC2821] and		The advent of client/server email using the [RFC3501], [RFC2821] and
	[RFC2476] protocols has changed what formerly were local disk		[SUBMIT] protocols has changed what formerly were local disk
	operations to become repetitive network data transmissions.		operations to become repetitive network data transmissions.
	Lemonade "forward without download" makes use of the [BURL] SUBMIT		Lemonade "forward without download" makes use of the [BURL] SUBMIT
	extension to enable access to external sources during the submission		extension to enable access to external sources during the submission
	of a message. In combination with the IMAP [URLAUTH] extension,		of a message. In combination with the IMAP [URLAUTH] extension,
	inclusion of message parts or even entire messages from the IMAP mail		inclusion of message parts or even entire messages from the IMAP mail
	store is possible with a minimal trust relationship between the IMAP		store is possible with a minimal trust relationship between the IMAP
	and SMTP SUBMIT servers.		and SMTP SUBMIT servers.
	Lemonade "forward without download" has the advantage of maintaining		Lemonade "forward without download" has the advantage of maintaining
	one submission protocol, and thus avoids the risk of having multiple		one submission protocol, and thus avoids the risk of having multiple
	parallel and possibly divergent mechanisms for submission. The client		parallel and possibly divergent mechanisms for submission. The client
	can use Submit/SMTP [RFC2476] extensions without these being added to		can use Submit/SMTP [SUBMIT] extensions without these being added to
	IMAP. Furthermore, by keeping the details of message submission in		IMAP. Furthermore, by keeping the details of message submission in
	the SMTP SUBMIT server, Lemonade "forward without download" can work		the SMTP SUBMIT server, Lemonade "forward without download" can work
	with other message retrieval protocols such as POP, NNTP, or whatever		with other message retrieval protocols such as POP, NNTP, or whatever
	else may be designed in the future.		else may be designed in the future.
	2.2. Message Sending Overview		2.2. Message Sending Overview
	The act of sending an email message can be thought of as involving		The act of sending an email message can be thought of as involving
	multiple steps: initiation of a new draft, draft editing, message		multiple steps: initiation of a new draft, draft editing, message
	assembly, and message submission.		assembly, and message submission.
	skipping to change at line 157 ¶		skipping to change at line 165 ¶
	Initiation of a new draft and draft editing takes place in the MUA.		Initiation of a new draft and draft editing takes place in the MUA.
	Frequently, users choose to save more complex messages on an		Frequently, users choose to save more complex messages on an
	[RFC3501] server (via the APPEND command with the \Draft flag) for		[RFC3501] server (via the APPEND command with the \Draft flag) for
	later recall by the MUA and resumption of the editing process.		later recall by the MUA and resumption of the editing process.
	Message assembly is the process of producing a complete message from		Message assembly is the process of producing a complete message from
	the final revision of the draft and external sources. At assembly		the final revision of the draft and external sources. At assembly
	time, external data is retrieved and inserted in the message.		time, external data is retrieved and inserted in the message.
	Message submission is the process of inserting the assembled message		Message submission is the process of inserting the assembled message
	into the [RFC2821] infrastructure, typically using the [RFC2476]		into the [RFC2821] infrastructure, typically using the [SUBMIT]
	protocol.		protocol.
	2.3. Traditional Strategy		2.3. Traditional Strategy
	Traditionally, messages are initiated, edited, and assembled entirely		Traditionally, messages are initiated, edited, and assembled entirely
	within an MUA, although drafts may be saved to an [RFC3501] server		within an MUA, although drafts may be saved to an [RFC3501] server
	and later retrieved from the server. The completed text is then		and later retrieved from the server. The completed text is then
	transmitted to an MSA for delivery.		transmitted to an MSA for delivery.
	There is often no clear boundary between the editing and assembly		There is often no clear boundary between the editing and assembly
	skipping to change at line 185 ¶		skipping to change at line 193 ¶
	submission.		submission.
	In the past, this was not much of a problem, because drafts, external		In the past, this was not much of a problem, because drafts, external
	data, and the message submission mechanism were typically located on		data, and the message submission mechanism were typically located on
	the same system as the MUA. The most common problem was running out		the same system as the MUA. The most common problem was running out
	of disk quota.		of disk quota.
	2.4. Step by step description		2.4. Step by step description
	The model distinguishes between a Messaging User Agent (MUA), an		The model distinguishes between a Messaging User Agent (MUA), an
	IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([RFC2476]),		IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([SUBMIT]), as
	as illustrated in Figure 1.		illustrated in Figure 1.
	+--------------------+ +--------------+		+--------------------+ +--------------+
	| | <------------ | |		| | <------------ | |
	| MUA (M) | | IMAPv4Rev1 |		| MUA (M) | | IMAPv4Rev1 |
	| | | Server |		| | | Server |
	| | ------------> | (Server I) |		| | ------------> | (Server I) |
	+--------------------+ +--------------+		+--------------------+ +--------------+
	^ | ^ |		^ | ^ |
	| | | |		| | | |
	| | | |		| | | |
	skipping to change at line 232 ¶		skipping to change at line 240 ¶
	achieved.		achieved.
	2.4.1. Message assembly using IMAP CATENATE extension		2.4.1. Message assembly using IMAP CATENATE extension
	In the [BURL]/[CATENATE] variant of the Lemonade "forward without		In the [BURL]/[CATENATE] variant of the Lemonade "forward without
	download" strategy, messages are initially composed and edited within		download" strategy, messages are initially composed and edited within
	an MUA. The [CATENATE] extension to [RFC3501] is then used to create		an MUA. The [CATENATE] extension to [RFC3501] is then used to create
	the messages on the IMAP server by transmitting new text and		the messages on the IMAP server by transmitting new text and
	assembling them. The [UIDPLUS] IMAP extension is used by the client		assembling them. The [UIDPLUS] IMAP extension is used by the client
	in order to learn the UID of the created messages. Finally a		in order to learn the UID of the created messages. Finally a
	[URLAUTH] format URL is given to a [RFC2476] server for submission		[URLAUTH] format URL is given to a [SUBMIT] server for submission
	using the [BURL] extension.		using the [BURL] extension.
	The flow involved to support such a use case consists of:		The flow involved to support such a use case consists of:
	M: {to I -- Optional} The client connects to the IMAP server,		M: {to I -- Optional} The client connects to the IMAP server,
	optionally starts TLS (if data confidentiality is required),		optionally starts TLS (if data confidentiality is required),
	authenticates, opens a mailbox ("INBOX" in the example below) and		authenticates, opens a mailbox ("INBOX" in the example below) and
	fetches body structures (See [RFC3501]).		fetches body structures (See [RFC3501]).
	Example:		Example:
	M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)		M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
	skipping to change at line 392 ¶		skipping to change at line 400 ¶
	Note that if the IMAP server doesn't send CAPABILITY response code		Note that if the IMAP server doesn't send CAPABILITY response code
	in the greeting, the mail submission server must issue the		in the greeting, the mail submission server must issue the
	CAPABILITY command to learn about supported IMAP extensions as		CAPABILITY command to learn about supported IMAP extensions as
	described in RFC 3501.		described in RFC 3501.
	Also, if data confidentiality is not required the mail submission		Also, if data confidentiality is not required the mail submission
	server may omit the STARTTLS command before issuing the LOGIN		server may omit the STARTTLS command before issuing the LOGIN
	command.		command.
	S2: {to M} OK (2XX)		S: {to M} Submission server assembles the complete message and if
			the assembly succeeds it returns OK to the MUA:
	Submission server returns OK to the MUA:
	S: 250 2.5.0 Ok.		S: 250 2.5.0 Ok.
	M: {to I} The client marks the forwarded message on the IMAP		M: {to I} The client marks the forwarded message on the IMAP
	server.		server.
	M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)		M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
	I: A0053 OK STORE completed		I: A0053 OK STORE completed
	Note: the UID STORE command shown above will only work if the		Note: the UID STORE command shown above will only work if the
	marked message is in the currently selected mailbox. This command		marked message is in the currently selected mailbox. This command
	can be omitted. The $Forwarded IMAP keyword is described in section		can be omitted. The $Forwarded IMAP keyword is described in section
	2.8.		2.8.
	2.4.2. Message assembly using SMTP CHUNKING and BURL extensions		2.4.2. Message assembly using SMTP CHUNKING and BURL extensions
	In the [BURL]/[CHUNKING] variant of the Lemonade "forward without		In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
	download" strategy, messages are initially composed and edited within		download" strategy, messages are initially composed and edited within
	an MUA. The BURL [BURL] and BDAT [CHINKING] commands are then used		an MUA. During submission [RFC2476], BURL [BURL] and BDAT [CHINKING]
	to create the messages from multiple parts during submission		commands are used to create the messages from multiple parts. New
	[RFC2476], existing body parts are referenced using [URLAUTH] format		body parts are supplied using BDAT commands, while existing body
	URLs.		parts are referenced using [URLAUTH] format URLs in BURL commands.
	The flow involved to support such a use case consists of:		The flow involved to support such a use case consists of:
	M: {to I -- Optional} The client connects to the IMAP server,		M: {to I -- Optional} The client connects to the IMAP server,
	optionally starts TLS (if data confidentiality is required),		optionally starts TLS (if data confidentiality is required),
	authenticates, opens a mailbox ("INBOX" in the example below) and		authenticates, opens a mailbox ("INBOX" in the example below) and
	fetches body structures (See [RFC3501]).		fetches body structures (See [RFC3501]).
	Example:		Example:
	M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)		M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
	I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"		I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
	skipping to change at line 457 ¶		skipping to change at line 464 ¶
	UIDVALIDITY=385759045/;UID=25627;Section=2.MIME;		UIDVALIDITY=385759045/;UID=25627;Section=2.MIME;
	expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:		expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
	internal:A0DEAD473744909de610943775f9BEEF"		internal:A0DEAD473744909de610943775f9BEEF"
	"imap://bob.ar@example.org/INBOX;		"imap://bob.ar@example.org/INBOX;
	UIDVALIDITY=385759045/;UID=25627;Section=2;		UIDVALIDITY=385759045/;UID=25627;Section=2;
	expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:		expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
	internal:BEEFA0DEAD473744909de610943775f9"		internal:BEEFA0DEAD473744909de610943775f9"
	I: A0054 OK GENURLAUTH completed		I: A0054 OK GENURLAUTH completed
	M: {to S} The client connects to the mail submission server and		M: {to S} The client connects to the mail submission server and
	starts a new mail transaction. It uses BURL to let the SMTP submit		starts a new mail transaction. It uses BURL to instruct the SMTP
	server fetch pieces of the message to be sent from the IMAP server		submit server to fetch from the IMAP server pieces of the message
	(See [BURL] for details of the semantics and steps). Note that the		to be sent (See [BURL] for details of the semantics and steps).
	second EHLO command is required after a successful STARTTLS		Note that the second EHLO command is required after a successful
	command. The third EHLO command is required if and only if the		STARTTLS command. The third EHLO command is required if and only if
	second EHLO response doesn't list any BURL options. See section		the second EHLO response doesn't list any BURL options. See section
	2.4.1 for an example of submission where the third EHLO		2.4.1 for an example of submission where the third EHLO
	command/response is not present.		command/response is not present.
	S: 220 owlry.example.org ESMTP		S: 220 owlry.example.org ESMTP
	M: EHLO potter.example.org		M: EHLO potter.example.org
	S: 250-owlry.example.com		S: 250-owlry.example.com
	S: 250-8BITMIME		S: 250-8BITMIME
	S: 250-BINARYMIME		S: 250-BINARYMIME
	S: 250-PIPELINING		S: 250-PIPELINING
	S: 250-BURL		S: 250-BURL
	skipping to change at line 588 ¶		skipping to change at line 595 ¶
	S: a003 OK Logout successful		S: a003 OK Logout successful
	Note that if the IMAP server doesn't send CAPABILITY response code		Note that if the IMAP server doesn't send CAPABILITY response code
	in the greeting, the mail submission server must issue the		in the greeting, the mail submission server must issue the
	CAPABILITY command to learn about supported IMAP extensions as		CAPABILITY command to learn about supported IMAP extensions as
	described in RFC 3501.		described in RFC 3501.
	Also, if data confidentiality is required the mail submission		Also, if data confidentiality is required the mail submission
	server should start TLS before issuing the LOGIN command.		server should start TLS before issuing the LOGIN command.
	S2: {to M} OK (2XX)		S: {to M} Submission server assembles the complete message and if
			the assembly succeeds it acknowledges acceptance of the message by
	Submission server acknowledges acceptance of the message by sending		sending 250 response to the last BDAT command:
	250 response to the last BDAT command:
	S: 250 2.5.0 Ok, message accepted.		S: 250 2.5.0 Ok, message accepted.
	M: {to I} The client marks the forwarded message on the IMAP		M: {to I} The client marks the forwarded message on the IMAP
	server.		server.
	M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)		M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
	I: A0053 OK STORE completed		I: A0053 OK STORE completed
	Note: the UID STORE command shown above will only work if the		Note: the UID STORE command shown above will only work if the
	marked message is in the currently selected mailbox. This command		marked message is in the currently selected mailbox. This command
	skipping to change at line 615 ¶		skipping to change at line 621 ¶
	2.5. Normative statements related to forward without download		2.5. Normative statements related to forward without download
	Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501],		Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501],
	CATENATE [CATENATE], UIDPLUS [UIDPLUS] and URLAUTH [URLAUTH]. This		CATENATE [CATENATE], UIDPLUS [UIDPLUS] and URLAUTH [URLAUTH]. This
	support MUST be declared via CAPABILITY [RFC3501].		support MUST be declared via CAPABILITY [RFC3501].
	Lemonade compliant submit servers MUST support the BURL [BURL],		Lemonade compliant submit servers MUST support the BURL [BURL],
	8BITMIME [8BITMIME], BINARYMIME [CHUNKING] and CHUNKING [CHUNKING].		8BITMIME [8BITMIME], BINARYMIME [CHUNKING] and CHUNKING [CHUNKING].
	This support MUST be declared via EHLO [RFC2821]. BURL MUST support		This support MUST be declared via EHLO [RFC2821]. BURL MUST support
	URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"		URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
	option following the BURL EHLO keyword.		option following the BURL EHLO keyword (See [BURL] for more details).
	Additional normative statements are provided in other sections.		Additional normative statements are provided in other sections.
	2.6. Security Considerations for pawn-tickets.		2.6. Security Considerations for pawn-tickets.
	The so-called "pawn-ticket" authorization mechanism uses a URI, which		The so-called "pawn-ticket" authorization mechanism uses a URI, which
	contains its own authorization credentials using [URLAUTH]. The		contains its own authorization credentials using [URLAUTH]. The
	advantage of this mechanism is that the SMTP submit [RFC2476] server		advantage of this mechanism is that the SMTP submit [SUBMIT] server
	cannot access any data on the [RFC3501] server without a "pawn-		cannot access any data on the [RFC3501] server without a "pawn-
	ticket" created by the client.		ticket" created by the client.
	The "pawn-ticket" grants access only to the specific data that the		The "pawn-ticket" grants access only to the specific data that the
	SMTP submit [RFC2476] server is authorized to access, can be revoked		SMTP submit [SUBMIT] server is authorized to access, can be revoked
	by the client, and can have a time-limited validity.		by the client, and can have a time-limited validity.
	2.7. The fcc problem		2.7. The fcc problem
	The "fcc problem" refers to delivering a copy of a message to a "file		The "fcc problem" refers to delivering a copy of a message to a "file
	carbon copy" recipient. By far, the most common case of fcc is a		carbon copy" recipient. By far, the most common case of fcc is a
	client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"		client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox"
	mailbox.		mailbox.
	In the traditional strategy, the MUA duplicates the effort spent in		In the traditional strategy, the MUA duplicates the effort spent in
	skipping to change at line 650 ¶		skipping to change at line 656 ¶
	in a separate step. This may be a write to a local disk file or an		in a separate step. This may be a write to a local disk file or an
	APPEND to a mailbox on an IMAP server. The latter is one of the "		APPEND to a mailbox on an IMAP server. The latter is one of the "
	repetitive network data transmissions" which represents the "problem"		repetitive network data transmissions" which represents the "problem"
	aspect of the "fcc problem".		aspect of the "fcc problem".
	The [CATENATE] extension to [RFC3501] can be used to address the fcc		The [CATENATE] extension to [RFC3501] can be used to address the fcc
	problem. The final message is constructed in the mailbox designed for		problem. The final message is constructed in the mailbox designed for
	outgoing mail. Note that the [CATENATE] extension can only create a		outgoing mail. Note that the [CATENATE] extension can only create a
	single message and only on the server which stages the outgoing		single message and only on the server which stages the outgoing
	message for submission. Additional copies of the message can be		message for submission. Additional copies of the message can be
	created on the same server using one or more COPY command.		created on the same server using one or more COPY commands.
	2.8. Registration of $Forwarded IMAP keyword		2.8. Registration of $Forwarded IMAP keyword
	$Forwarded IMAP keyword is used by several IMAP clients to specify		The $Forwarded IMAP keyword is used by several IMAP clients to
	that the message was resent to another email address, embedded within		specify that the message was resent to another email address,
	or attached to a new message. A mail client sets this keyword when it		embedded within or attached to a new message. A mail client sets this
	successfully forwards the message to another email address. Typical		keyword when it successfully forwards the message to another email
	usage of this keyword is to show a different (or additional) icon for		address. Typical usage of this keyword is to show a different (or
	a message that has been forwarded. Once set the flag SHOULD NOT be		additional) icon for a message that has been forwarded. Once set the
	cleared.		flag SHOULD NOT be cleared.
	Lemonade compliant servers MUST be able to store the $Forwarded		Lemonade compliant servers MUST be able to store the $Forwarded
	keyword. They MUST preserve it on the COPY operation. The servers		keyword. They MUST preserve it on the COPY operation. The servers
	MUST support the SEARCH KEYWORD $Forwarded.		MUST support the SEARCH KEYWORD $Forwarded.
	3. Message Submission		3. Message Submission
	LEMONADE compliant mail submission servers are expected to implement		LEMONADE compliant mail submission servers are expected to implement
	the following set of SMTP extensions to make message submission		the following set of SMTP extensions to make message submission
	efficient.		efficient.
	skipping to change at line 692 ¶		skipping to change at line 698 ¶
	Clients SHOULD pipeline SMTP commands when possible.		Clients SHOULD pipeline SMTP commands when possible.
	3.2. DSN Support		3.2. DSN Support
	LEMONADE compliant mail submission servers MUST support SMTP service		LEMONADE compliant mail submission servers MUST support SMTP service
	extensions for delivery status notifications [RFC3461].		extensions for delivery status notifications [RFC3461].
	3.3. Message size declaration		3.3. Message size declaration
	LEMONADE compliant mail submission servers MUST support the SMTP		LEMONADE compliant mail submission servers MUST support the SMTP
	Service Extension for Message Size Declaration [RFC2927].		Service Extension for Message Size Declaration [RFC1870].
	Note a LEMONADE compliant mail submission server must perform message		LEMONADE compliant mail submission servers MUST ("expand") all BURL
	size limit enforcement after performing "expansion" of all BURL		parts before enforcing a message size limit.
	parts.
	A LEMONADE compliant client SHOULD use message size declaration. In		A LEMONADE compliant client SHOULD use message size declaration. In
	particular it SHOULD NOT send a message to a mail submission server,		particular it SHOULD NOT send a message to a mail submission server,
	if the client knows that the message exceeds the maximal message size		if the client knows that the message exceeds the maximal message size
	advertised by the submission server.		advertised by the submission server.
	3.4. Enhanced status code Support		3.4. Enhanced status code Support
	LEMONADE compliant mail submission servers MUST support SMTP Service		LEMONADE compliant mail submission servers MUST support SMTP Service
	Extension for Returning Enhanced Error Codes [RFC2034].		Extension for Returning Enhanced Error Codes [RFC2034].
	skipping to change at line 734 ¶		skipping to change at line 739 ¶
	Lemonade compliant IMAP servers MUST support the NAMESPACE		Lemonade compliant IMAP servers MUST support the NAMESPACE
	[NAMESPACE] extension. The extension allows clients to discover		[NAMESPACE] extension. The extension allows clients to discover
	shared mailboxes and mailboxes belonging to other users.		shared mailboxes and mailboxes belonging to other users.
	Lemonade compliant IMAP servers MUST support the LITERAL+ [LITERAL+]		Lemonade compliant IMAP servers MUST support the LITERAL+ [LITERAL+]
	extension. The extension allows clients to save a round trip each		extension. The extension allows clients to save a round trip each
	time a non-synchronizing literal is sent.		time a non-synchronizing literal is sent.
	Lemonade compliant IMAP servers MUST support the IDLE [IDLE]		Lemonade compliant IMAP servers MUST support the IDLE [IDLE]
	extension. The extension allows clients to receive instant		extension. The extension allows clients to receive instant
	notifications about changes in the selected mailbox, without the need		notifications about changes in the selected mailbox, without needing
	for constant polling for changes.		to poll for changes.
	LEMONADE Compliant IMAP servers MUST support IMAP over TLS [RFC3501]		LEMONADE Compliant IMAP servers MUST support IMAP over TLS [RFC3501]
	as required by RFC 3501.		as required by RFC 3501.
	6. Summary of the required IMAP and SMTP extensions		6. Summary of the required IMAP and SMTP extensions
	------------------------------------------------------		-----------------------------------------------------|
	|Name of an SMTP extension| Comment |		| Name of SMTP extension | Comment |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| PIPELINING | Section 3.1 |		| PIPELINING | Section 3.1 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| DNS | Section 3.2 |		| DNS | Section 3.2 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| SIZE | Section 3.3 |		| SIZE | Section 3.3 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| ENHANCEDSTATUSCODES | Section 3.4 |		| ENHANCEDSTATUSCODES | Section 3.4 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| STARTTLS | Section 3.5 |		| STARTTLS | Section 3.5 |
	skipping to change at line 769 ¶		skipping to change at line 774 ¶
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| CHUNKING, | Section 2.5 |		| CHUNKING, | Section 2.5 |
	| BINARYMIME | Section 2.5 |		| BINARYMIME | Section 2.5 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| 8BITMIME, | Required by BURL |		| 8BITMIME, | Required by BURL |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| AUTH | Required by Submission, |		| AUTH | Required by Submission, |
	| | See [SMTPAUTH]. |		| | See [SMTPAUTH]. |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	------------------------------------------------------		-----------------------------------------------------|
	|Name of an IMAP extension| Comment |		| Name of IMAP extension | Comment |
	| or feature | |		| or feature | |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| NAMESPACE | Section 5 |		| NAMESPACE | Section 5 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| CONDSTORE | Section 4 |		| CONDSTORE | Section 4 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| STARTTLS |Required by IMAP (RFC3501)|		| STARTTLS |Required by IMAP (RFC3501)|
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| URLAUTH, | Forward without download,|		| URLAUTH, | Forward without download,|
	| CATENATE, | Section 2 |		| CATENATE, | Section 2 |
	| UIDPLUS | |		| UIDPLUS | |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| LITERAL+ | Section 5 |		| LITERAL+ | Section 5 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| IDLE | Section 5 |		| IDLE | Section 5 |
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	| $Forwarded IMAP keyword | Section 2.8 |		| $Forwarded IMAP keyword | Section 2.8
			|
	|-------------------------|--------------------------|		|-------------------------|--------------------------|
	7. Future work		7. Future work
	The Lemonade Working Group is looking into additional issues related		The Lemonade Working Group is looking into additional issues related
	to access of email from mobile devices, possibly including:		to usage of email by mobile devices, possibly including:
	- Media conversion (static and possibly streamed)		- Media conversion (static and possibly streamed)
	- Transport optimization for low or costly bandwidth and less		- Transport optimization for low or costly bandwidth and less
	reliable mobile networks (e.g. quick reconnect)		reliable mobile networks (e.g. quick reconnect)
	- Server to client notifications, possibly outside of the		- Server to client notifications, possibly outside of the
	traditional IMAP band		traditional IMAP band
	- Dealing with firewall and intermediaries		- Dealing with firewall and intermediaries
	- Compression and other bandwidth optimization		- Compression and other bandwidth optimization
	- Filtering		- Filtering
	- Other considerations for mobile clients		- Other considerations for mobile clients
	8. Security Considerations		8. Security Considerations
	Security considerations on Lemonade "forward without download" are		Security considerations on Lemonade "forward without download" are
	discussed throughout section 2. Additional security considerations		discussed throughout section 2. Additional security considerations
	can be found in [RFC3501] and other documents describing other SMTP		can be found in [RFC3501] and other documents describing other SMTP
	and IMAP extensions comprising the Lemonade Profile.		and IMAP extensions comprising the Lemonade Profile.
	Note that the mandatory to implement authentication mechanism for		Note that the mandatory to implement authentication mechanism for
	SMTP submission is described in [RFC2476]. The mandatory to implement		SMTP submission is described in [SUBMIT]. The mandatory to implement
	authentication mechanism for IMAP is described in [RFC3501].		authentication mechanism for IMAP is described in [RFC3501].
	8.1. Confidentiality Protection of Submitted Messages		8.1. Confidentiality Protection of Submitted Messages
	When clients submit new messages, link protection such as TLS guards		When clients submit new messages, link protection such as TLS guards
	against an eavesdropper seeing the contents of the submitted message.		against an eavesdropper seeing the contents of the submitted message.
	It's worth noting, however, that even if TLS is not used, the		It's worth noting, however, that even if TLS is not used, the
	security risks are no worse if BURL is used to reference the text		security risks are no worse if BURL is used to reference the text
	than if the text is submitted directly. If BURL is not used, an		than if the text is submitted directly. If BURL is not used, an
	eavesdropper gains access to the full text of the message. If BURL		eavesdropper gains access to the full text of the message. If BURL
	is used, the eavesdropper may or may not be able to gain such access,		is used, the eavesdropper may or may not be able to gain such access,
	depending on the form of BURL used. For example, some forms restrict		depending on the form of BURL used. For example, some forms restrict
	use of the URL to an entity authorized as a submission server or a		use of the URL to an entity authorized as a submission server or a
	specific user.		specific user.
	8.2. TLS		8.2. TLS
	When LEMONADE clients use the BURL extension to mail submission, an		When LEMONADE clients use the BURL extension to mail submission, an
	extension that requires sending a URLAUTH token to the mail		extension that requires sending a URLAUTH token to the mail
	submission server, such a token should be protected from interception		submission server, such a token should be protected from interception
	to avoid a replay attack that will disclose the contents of the		to avoid a replay attack that may disclose the contents of the
	message to an attacker. TLS based encryption of the mail submission		message to an attacker. TLS based encryption of the mail submission
	path will provide protection against this attack.		path will provide protection against this attack.
	LEMONADE clients SHOULD use TLS protected IMAP and mail submission		LEMONADE clients SHOULD use TLS protected IMAP and mail submission
	channels when using BURL-based message submission to protect the		channels when using BURL-based message submission to protect the
	URLAUTH token from interception.		URLAUTH token from interception.
	LEMONADE compliant mail submission servers SHOULD use TLS protected		LEMONADE compliant mail submission servers SHOULD use TLS protected
	IMAP connection when fetching message content using the URLAUTH token		IMAP connections when fetching message content using the URLAUTH
	provided by the LEMONADE client.		token provided by the LEMONADE client.
	When a client uses SMTP STARTTLS to send a BURL command which		When a client uses SMTP STARTTLS to send a BURL command which
	references non-public information, there is a user expectation that		references non-public information, there is a user expectation that
	the entire message content will be treated confidentially. To meet		the entire message content will be treated confidentially. To meet
	this expectation, the message submission server should use STARTTLS		this expectation, the message submission server should use STARTTLS
	or a mechanism providing equivalent data confidentiality when		or a mechanism providing equivalent data confidentiality when
	fetching the content referenced by that URL.		fetching the content referenced by that URL.
	9. IANA Considerations		9. IANA Considerations
	skipping to change at line 885 ¶		skipping to change at line 891 ¶
	UIDPLUS extension", work in progress, draft-crispin-imap-		UIDPLUS extension", work in progress, draft-crispin-imap-
	rfc2359bis-XX.txt.		rfc2359bis-XX.txt.
	[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate		[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	http://www.ietf.org/rfc/rfc2119		http://www.ietf.org/rfc/rfc2119
	[RFC2197] Freed, N. "SMTP Service Extension for Command Pipelining",		[RFC2197] Freed, N. "SMTP Service Extension for Command Pipelining",
	RFC 2197, September 1997. http://www.ietf.org/rfc/rfc2197		RFC 2197, September 1997. http://www.ietf.org/rfc/rfc2197
	[RFC2476] Gellens, R. and Klensin, J., "Message Submission for Mail",		[RFC1870] Freed, N. and K. Moore, "SMTP Service Extension for Message
			Size Declaration", RFC 1870, November 1995.
			[SUBMIT] Gellens, R. and Klensin, J., "Message Submission for Mail",
	draft-gellens-submit-bis-02.txt.		draft-gellens-submit-bis-02.txt.
	[SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over		[SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over
	TLS ", RFC 3207, February 2002. http://www.ietf.org/rfc/rfc3207		TLS ", RFC 3207, February 2002. http://www.ietf.org/rfc/rfc3207
	[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,		[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.		April 2001.
	[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol		[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
	Version 4 rev1", RFC 3501, March 2003.		Version 4 rev1", RFC 3501, March 2003.
	skipping to change at line 933 ¶		skipping to change at line 942 ¶
	10.2. Informative References		10.2. Informative References
	[IMAP-DISC] Melnikov, A. "Synchronization Operations For		[IMAP-DISC] Melnikov, A. "Synchronization Operations For
	Disconnected Imap4 Clients", IMAP-DISC, work in progress, draft-		Disconnected Imap4 Clients", IMAP-DISC, work in progress, draft-
	melnikov-imap-disc-XX.txt		melnikov-imap-disc-XX.txt
	Version History		Version History
	This section will be deleted before publication.		This section will be deleted before publication.
			Version 07:
			[1] Addressed editorial comments from Randy Gellens and Dave
			Cridland.
	Version 06:		Version 06:
	[1] Updated the reference to SMTP STARTTLS.		[1] Updated the reference to SMTP STARTTLS.
	[2] Updated the CATENATE example as per comments from Dave Cridland		[2] Updated the CATENATE example as per comments from Dave Cridland
	(message context, missing additional EHLO, etc.).		(message context, missing additional EHLO, etc.).
	[3] Added a new section showing use of BURL/BDAT for message		[3] Added a new section showing use of BURL/BDAT for message
	assembly.		assembly.
	[4] Added a requirement to support IMAP IDLE extension.		[4] Added a requirement to support IMAP IDLE extension.
	[5] Added description of the $Forwarded IMAP keyword.		[5] Added description of the $Forwarded IMAP keyword.
	[6] Added a requirement to support URLAUTH in BURL.		[6] Added a requirement to support URLAUTH in BURL.
	[7] Mentioned mandatory to implement authentication in the Security		[7] Mentioned mandatory to implement authentication in the Security
	skipping to change at line 1075 ¶		skipping to change at line 1088 ¶
	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 AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 32 change blocks.
	61 lines changed or deleted		74 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/