< draft-newman-lemonade-burl-00.txt		draft-newman-lemonade-burl-01.txt >
	Network Working Group C. Newman		Network Working Group C. Newman
	Internet-Draft Sun Microsystems		Internet-Draft Sun Microsystems
	Expires: September 20, 2004 March 22, 2004		Updates: 3463 (if approved) July 12, 2004
			Expires: January 10, 2005
	Message Submission BURL Extension		Message Submission BURL Extension
	draft-newman-lemonade-burl-00.txt		draft-newman-lemonade-burl-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 http://		The list of current Internet-Drafts can be accessed at
	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 September 20, 2004.		This Internet-Draft will expire on January 10, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	The submission profile of Simple Mail Transfer Protocol (SMTP)		The submission profile of Simple Mail Transfer Protocol (SMTP)
	provides a standard way for an email client to submit a complete		provides a standard way for an email client to submit a complete
	message for delivery. This specification extends the submission		message for delivery. This specification extends the submission
	profile by adding a new BURL command which can be used to fetch		profile by adding a new BURL command which can be used to fetch
	submission data from an Internet Message Access Protocol (IMAP)		submission data from an Internet Message Access Protocol (IMAP)
	server. This permits a mail client to inject content from an IMAP		server. This permits a mail client to inject content from an IMAP
	server into the SMTP infrastructure without downloading it to the		server into the SMTP infrastructure without downloading it to the
	client and uploading it back to the server.		client and uploading it back to the server.
	Table of Contents		Table of Contents
	1. Conventions Used in this Document . . . . . . . . . . . . . . 3		1. Conventions Used in this Document . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. BURL Submission Extension . . . . . . . . . . . . . . . . . . 3		3. BURL Submission Extension . . . . . . . . . . . . . . . . . . 3
	3.1 SMTP Submission Extension Registration . . . . . . . . . . . . 3		3.1 SMTP Submission Extension Registration . . . . . . . . . . 3
	3.2 BURL Transaction . . . . . . . . . . . . . . . . . . . . . . . 4		3.2 BURL Transaction . . . . . . . . . . . . . . . . . . . . . 4
	3.3 The BURL IMAP Option . . . . . . . . . . . . . . . . . . . . . 4		3.3 The BURL IMAP Option . . . . . . . . . . . . . . . . . . . 4
	3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6		3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 6
	4. 8-bit and Binary . . . . . . . . . . . . . . . . . . . . . . . 6		4. 8-bit and Binary . . . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. Updates to RFC 3463 . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Response Codes . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Document History . . . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7.1 Changes from -01 . . . . . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7.2 Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Normative References . . . . . . . . . . . . . . . . . . . . . 8		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
	Informative References . . . . . . . . . . . . . . . . . . . . 8		9.2 Informative References . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . 10		A. Document History . . . . . . . . . . . . . . . . . . . . . . . 12
			A.1 Changes from burl-00 . . . . . . . . . . . . . . . . . . . 12
			A.2 Changes from compose-01 . . . . . . . . . . . . . . . . . 12
			A.3 Changes from compose-00 . . . . . . . . . . . . . . . . . 12
			Intellectual Property and Copyright Statements . . . . . . . . 13
	1. Conventions Used in this Document		1. Conventions Used in this Document
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"		The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
	in this document are to be interpreted as defined in "Key words for		in this document are to be interpreted as defined in "Key words for
	use in RFCs to Indicate Requirement Levels" [2].		use in RFCs to Indicate Requirement Levels" [2].
	The formal syntax use the Augmented Backus-Naur Form (ABNF) [4]		The formal syntax use the Augmented Backus-Naur Form (ABNF) [4]
	notation including the core rules defined in Appendix A of RFC 2234.		notation including the core rules defined in Appendix A of RFC 2234.
	2. Introduction		2. Introduction
	This specification defines an extension to the standard Message		This specification defines an extension to the standard Message
	Submission [6] protocol to permit data to be fetched from an IMAP		Submission [6] protocol to permit data to be fetched from an IMAP
	server at message submission time. This MAY be used in conjuction		server at message submission time. This MAY be used in conjunction
	with the CHUNKING [10] mechanism so that chunks of the message can		with the CHUNKING [10] mechanism so that chunks of the message can
	come from an external IMAP server. This provides the ability to		come from an external IMAP server. This provides the ability to
	forward an email message without first downloading it to the client.		forward an email message without first downloading it to the client.
	3. BURL Submission Extension		3. BURL Submission Extension
	This section defines the BURL submission extension.		This section defines the BURL submission extension.
	3.1 SMTP Submission Extension Registration		3.1 SMTP Submission Extension Registration
	1. The name of this submission extension is "BURL". This extends		1. The name of this submission extension is "BURL". This extends
	the Message Submission protocol on port 587 and MUST NOT be		the Message Submission protocol on port 587 and MUST NOT be
	advertised by a regular SMTP [8] server on port 25. Compliant		advertised by a regular SMTP [8] server on port 25 that acts as a
			relay for incoming mail from other SMTP relays. Compliant
	submission clients MUST attempt to use port 587 prior to falling		submission clients MUST attempt to use port 587 prior to falling
	back to port 25, unless explicitly configured to do otherwise by		back to port 25, unless explicitly configured to do otherwise by
	the user.		the user.
	2. The EHLO keyword value associated with the extension is "BURL".		2. The EHLO keyword value associated with the extension is "BURL".
	3. The BURL EHLO keyword will have zero or more arguments. The only		3. The BURL EHLO keyword will have zero or more arguments. The only
	argument defined at this time is the "imap" argument, which MUST		argument defined at this time is the "imap" argument, which MUST
	be present in order to use IMAP URLs with BURL. Clients MUST		be present in order to use IMAP URLs with BURL. Clients MUST
	ignore other arguments after the BURL EHLO keyword unless they		ignore other arguments after the BURL EHLO keyword unless they
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	The arguments which appear after the BURL EHLO keyword may change		The arguments which appear after the BURL EHLO keyword may change
	subsequent to the use of SMTP AUTH [7], so a server which		subsequent to the use of SMTP AUTH [7], so a server which
	advertises BURL with no arguments prior to authentication		advertises BURL with no arguments prior to authentication
	indicates that BURL is supported but authentication is required		indicates that BURL is supported but authentication is required
	to use it.		to use it.
	4. This extension adds the BURL SMTP verb. This verb is used as a		4. This extension adds the BURL SMTP verb. This verb is used as a
	replacement for the DATA command and is only permitted during a		replacement for the DATA command and is only permitted during a
	mail transaction after at least one successful recipient.		mail transaction after at least one successful recipient.
	3.2 BURL Transaction		3.2 BURL Transaction
	When a BURL-aware client connects to a submit server with the BURL		When a BURL-aware client connects to a submit server with the BURL
	extension, it will first authenticate (using SMTP AUTH and perhaps		extension, it will first authenticate (using SMTP AUTH and perhaps
	STARTTLS), and then can submit any number of messages with full		STARTTLS), and then can submit any number of messages with full
	interoperability with important SMTP extensions such as delivery		interoperability with important SMTP extensions such as delivery
	status notifications [17].		status notifications [18].
	A simple BURL transaction will consist of MAIL FROM, one or more RCPT		A simple BURL transaction will consist of MAIL FROM, one or more RCPT
	TO headers and a BURL command with the "LAST" tag. The BURL command		TO headers and a BURL command with the "LAST" tag. The BURL command
	will include an IMAP URL pointing to a fully formed message ready for		will include an IMAP URL pointing to a fully formed message ready for
	injection into the SMTP infrastructure. If PIPELINING [9] is		injection into the SMTP infrastructure. If PIPELINING [9] is
	advertised, the client MAY send the entire transaction in one round		advertised, the client MAY send the entire transaction in one round
	trip. If no valid RCPT TO address is supplied, the BURL command will		trip. If no valid RCPT TO address is supplied, the BURL command will
	simply fail and no resolution of BURL arguments will be performed.		simply fail and no resolution of the BURL URL argument will be
	If at least one valid RCPT TO address is supplied, then the BURL		performed. If at least one valid RCPT TO address is supplied, then
	argument will be resolved before the server responds to the command.		the BURL URL argument will be resolved before the server responds to
			the command.
	A more sophisticated BURL transaction occurs when the server also		A more sophisticated BURL transaction occurs when the server also
	advertises CHUNKING [10]. In this case, the BURL and BDAT commands		advertises CHUNKING [10]. In this case, the BURL and BDAT commands
	may be interleaved until one of them terminates the transaction with		may be interleaved until one of them terminates the transaction with
	the "LAST" argument. If PIPELINING [9] is also advertise, then the		the "LAST" argument. If PIPELINING [9] is also advertised, then the
	client may pipeline the entire transaction in one round-trip.		client may pipeline the entire transaction in one round-trip.
	However, it MUST wait for the results of the "LAST" BDAT or BURL		However, it MUST wait for the results of the "LAST" BDAT or BURL
	command prior to initiating a new transaction.		command prior to initiating a new transaction.
	The BURL command directs the server to fetch the data object to which		The BURL command directs the server to fetch the data object to which
	the URL refers and include it in the message. If the URL fetch		the URL refers and include it in the message. If the URL fetch
	fails, the server will fail the entire transaction.		fails, the server will fail the entire transaction.
	3.3 The BURL IMAP Option		3.3 The BURL IMAP Option
	When "imap" is present in the space-separated list of arguments		When "imap" is present in the space-separated list of arguments
	following the BURL EHLO keyword, that indicates the BURL command		following the BURL EHLO keyword, that indicates the BURL command
	supports IMAP URLs [3] with the URLAUTH [13] extended form.		supports the URLAUTH [13] extended form of IMAP URLs [3].
	Subsequent to a successful SMTP AUTH command, the submission server		Subsequent to a successful SMTP AUTH command, the submission server
	MAY indicate a pre-arranged trust relationship with a specific IMAP		MAY indicate a pre-arranged trust relationship with a specific IMAP
	server by including a BURL EHLO keyword argument of the form "imap://		server by including a BURL EHLO keyword argument of the form "imap://
	imap.example.com". In this case, the submission server will permit a		imap.example.com". In this case, the submission server will permit a
	regular IMAP URL to mailboxes on imap.example.com which the user who		regular IMAP URL to mailboxes on imap.example.com which the user who
	authenticated to the submit server can access.		authenticated to the submit server can access.
	3.4 Examples		3.4 Examples
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively. If a single "C:" or "S:" label applies to		server respectively. If a single "C:" or "S:" label applies to
	multiple lines, then the line breaks between those lines are for		multiple lines, then the line breaks between those lines are for
	editorial clarity only and are not part of the actual protocol		editorial clarity only and are not part of the actual protocol
	exchange.		exchange.
	Two successful submissions (without and with pipelining) follow:		Two successful submissions (without and with pipelining) follow:
	<SSL/TLS encryption layer negotiated>		<SSL/TLS encryption layer negotiated>
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	C: MAIL FROM:<harry@gryffindor.example.com>		C: MAIL FROM:<harry@gryffindor.example.com>
	C: RCPT TO:<ron@gryffindor.example.com>		C: RCPT TO:<ron@gryffindor.example.com>
	C: BURL imap://harry@gryffindor.example.com/outbox		C: BURL imap://harry@gryffindor.example.com/outbox
	;uidvalidity=1078863300/;uid=25;urlauth=submit+harry		;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
	:internal:71354a473744909de610943775f92038 LAST		:internal:71354a473744909de610943775f92038 LAST
	S: 250 2.5.0 Address Ok.		S: 250 2.5.0 Address Ok.
	S: 250 2.1.5 ron@gryffindor.example.com OK.		S: 250 2.1.5 ron@gryffindor.example.com OK.
	S: 554 5.7.0 IMAP URL authorization failed		S: 554 5.7.0 IMAP URL authorization failed
	3.5 Formal Syntax		3.5 Formal Syntax
	The following syntax specification inherits ABNF [4] and Uniform		The following syntax specification inherits ABNF [4] and Uniform
	Resource Identifiers [5].		Resource Identifiers [5].
	burl-param = "imap" / ("imap://" authority)		burl-param = "imap" / ("imap://" authority)
	; parameter to BURL EHLO keyword		; parameter to BURL EHLO keyword
	burl-cmd = "BURL" SP absoluteURI [SP end-marker] CRLF		burl-cmd = "BURL" SP absoluteURI [SP end-marker] CRLF
	end-marker = "LAST"		end-marker = "LAST"
	4. 8-bit and Binary		4. 8-bit and Binary
	The BURL server MUST advertise 8BITMIME [1] and perform the		A submit server which advertises BURL MUST also advertise 8BITMIME
	downconversion described in that specification on the resulting		[1] and perform the down conversion described in that specification
	complete message if 8-bit data is received with the BURL command and		on the resulting complete message if 8-bit data is received with the
	passed to a 7-bit server. If the URL argument to BURL refers to		BURL command and passed to a 7-bit server. If the URL argument to
	binary data, then the submit server MAY refuse the command or		BURL refers to binary data, then the submit server MAY refuse the
	downconvert as described in Binary SMTP [10].		command or down convert as described in Binary SMTP [10].
	The Submit server MAY refuse to accept a BURL command or combination		The Submit server MAY refuse to accept a BURL command or combination
	of BURL and BDAT commands which result in unencoded 8-bit data in		of BURL and BDAT commands which result in unencoded 8-bit data in
	mail or MIME [16] headers.		mail or MIME [16] headers. Alternatively, the server MAY accept such
			data and down convert to MIME header encoding [17].
	5. IANA Considerations		5. Updates to RFC 3463
	When this is published as an RFC, the "BURL" SMTP extension as		SMTP or Submit servers which advertise ENHANCEDSTATUSCODES [15] may
	described in Section 3 will be registered. This registration will be		includes enhanced status codes defined in RFC 3463 [19]. The BURL
	marked as for use by message submission [6] only in the registry.		extension introduces new error cases which that RFC did not consider.
			The following additional enhanced status codes are defined by this
			specification:
	6. Security Considerations		X.6.6 Message content not available
	A separate specification discussing security details of this proposal		The message content could not be fetched from a remote system.
	and counter-proposals is forthcoming.		This may be useful as a permanent or persistent temporary
			notification.
	Implementations which support the URLAUTH [13] form of IMAP URLs		X.7.8 Trust relationship required
	SHOULD implement both the SMTP STARTTLS [11] and the IMAP STARTTLS
	[12] extensions and MUST have a configuration setting which requires
	their use with such IMAP URLs.
	When a client uses SMTP STARTTLS to send a BURL command which		The submission server requires a configured trust relationship
	references non-public information, the message submission server MUST		with a third-party server in order to access the message content.
	use STARTTLS or a mechanism providing equivalent data privacy when
	resolving that URL.
	7. Document History		6. Response Codes
	7.1 Changes from -01		This section includes example response codes to the BURL command.
			Other text may be used with the same response codes. This list is
			not exhaustive and BURL clients MUST tolerate any valid SMTP response
			code. Most of these examples include the appropriate enhanced status
			code [19].
	o Removed the conversion argument to BURL to simplify.		554 5.5.0 No recipients have been specified
	o Replace the conversion section with the simpler 8-bit and Binary		This response code occurs when BURL is used with PIPELINING and
	section.		all RCPT TOs failed.
	o Removed the failhow argument to simplify and eliminate		503 5.5.0 Valid RCPT TO required before BURL
	race-condition which bothered people.
	o Simplify specification to eliminate "composition" model and just		This response code is an alternative to the previous one when BURL
	focus on BURL command.		is used with PIPELINING and all RCPT TOs failed.
	o Make it clear that BURL can be used without the chunking		554 5.6.3 Conversion required but not supported
	extension.
	7.2 Changes from -00		This response code occurs when the URL points to binary data and
			the implementation does not support down conversion to base64.
			This can also be used if the URL points to message data with 8-bit
			content in headers and the server does not down convert such
			content.
	o Added the end-marker "LAST", so this could be used without BDAT		554 5.3.4 Message too big for system
	and works with a pre-composed message.
	o Changed "Message Composition" to "Message Submission with		The message (subsequent to URL resolution) is larger than the
	Composition" in several places.		per-message size limit for this server.
	o Correct Spelling Errors		554 5.7.8 URL resolution requires trust relationship
	Normative References		The submit server does not have a trust relationship with the IMAP
			server specified in the URL argument to BURL.
			552 5.2.2 Mailbox full
			The recipient is local, the submit server supports direct delivery
			and the recipient has exceeded his quota and any grace period for
			delivery attempts.
			554 5.6.6 IMAP URL resolution failed
			The IMAP FETCHURL command returned an error or no data.
			354 Waiting for additional BURL or BDAT commands
			A BURL command without the "LAST" modifier was sent. The URL for
			this BURL command was successfully resolved, but the content will
			not be committed to persistent storage until the rest of the
			message content is collected. For example, a Unix server may have
			written the content to a queue file buffer, but not yet performed
			an fsync() operation. If the server loses power, the content can
			still be lost.
			451 4.4.1 IMAP server unavailable
			The connection to the IMAP server to resolve the URL failed.
			250 2.5.0 Ok.
			The URL was successfully resolved and the complete message data
			has been committed to persistent storage.
			250 2.6.4 MIME header conversion with loss performed
			The URL pointed to message data which included mail or MIME
			headers with 8-bit data. This data was converted to MIME header
			encoding [17] but the submit server may not have correctly guessed
			the unlabelled character set.
			7. IANA Considerations
			When this is published as an RFC, the "BURL" SMTP extension as
			described in Section 3 will be registered. This registration will be
			marked for use by message submission [6] only in the registry.
			8. Security Considerations
			Modern SMTP submission servers often include content-based security
			and denial-of-service defense mechanisms such as virus filtering,
			size limits, server-generated signatures, spam filtering, etc.
			Implementations of BURL should fetch the URL content prior to
			application of such content-based mechanisms in order to preserve
			their function.
			Clients which generate unsolicited bulk email or email with viruses
			could use this mechanism to compensate for a slow link between the
			client and submit server. In particular, this mechanism would make
			it feasible for a programmable cell phone or other device on a slow
			link to become a significant source of unsolicited bulk email and/or
			viruses. This makes it more important for submit server vendors
			implementing BURL to have auditing and/or defenses against such
			denial-of-service attacks including mandatory authentication, logging
			which associates unique client identifiers with mail transactions,
			limits on re-use of the same IMAP URL, rate limits, recipient count
			limits and content filters.
			Transfer of the URLAUTH [13] form of IMAP URLs in the clear can
			expose the authorization token to network eavesdroppers.
			Implementations which support such URLs can address this issue by
			using a strong confidentiality protection mechanism. For example,
			the SMTP STARTTLS [11] and the IMAP STARTTLS [12] extensions in
			combination with a configuration setting which requires their use
			with such IMAP URLs would address this concern.
			Use of a pre-arranged trust relationship between a submit server and
			a specific IMAP server introduces security considerations: a
			compromise of the submit server should not automatically compromise
			all accounts on the IMAP server so trust relationships involving
			super-user proxy credentials are strongly discouraged. A system
			which requires the submit server to authenticate to the IMAP server
			with submit credentials and subsequently requires a URLAUTH URL to
			fetch any content addresses this concern. A trusted third party
			model for proxy credentials such as that provided by Kerberos5 [14]
			would also suffice.
			When a client uses SMTP STARTTLS to send a BURL command which
			references non-public information there is a user expectation that
			the entire message content will be treated confidentially. To
			address this expectation, the message submission server should use
			STARTTLS or a mechanism providing equivalent data confidentiality
			when fetching the content referenced by that URL.
			A legitimate user of a submit server may try to compromise other
			accounts on the server by providing an IMAP URLAUTH URL which points
			to a server under that user's control which is designed to undermine
			the security of the submit server. For this reason, the IMAP client
			code which the submit server uses must be robust with respect to
			arbitrary input sizes (including large IMAP literals) and arbitrary
			delays from the IMAP server. Requiring a pre-arranged trust
			relationship between a submit server and the IMAP server also
			addresses this concern.
			9. References
			9.1 Normative References
	[1] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,		[1] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
	"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July		"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
	1994.		1994.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.		[3] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
	skipping to change at page 8, line 47 ¶		skipping to change at page 11, line 13 ¶
	[10] Vaudreuil, G., "SMTP Service Extensions for Transmission of		[10] Vaudreuil, G., "SMTP Service Extensions for Transmission of
	Large and Binary MIME Messages", RFC 3030, December 2000.		Large and Binary MIME Messages", RFC 3030, December 2000.
	[11] Hoffman, P., "SMTP Service Extension for Secure SMTP over		[11] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, February 2002.		Transport Layer Security", RFC 3207, February 2002.
	[12] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[12] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	[13] Crispin, M. and C. Newman, "Internet Message Access Protocol		[13] Crispin, M. and C. Newman, "Internet Message Access Protocol
	(IMAP) - URLAUTH Extension", draft-crispin-imap-urlauth-06		(IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth-00
	(work in progress), January 2004.		(work in progress), July 2004.
	Informative References		9.2 Informative References
	[14] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,		[14] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
	August 1982.		Service (V5)", RFC 1510, September 1993.
	[15] Freed, N., "SMTP Service Extension for Returning Enhanced Error		[15] Freed, N., "SMTP Service Extension for Returning Enhanced Error
	Codes", RFC 2034, October 1996.		Codes", RFC 2034, October 1996.
	[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message Bodies",		Extensions (MIME) Part One: Format of Internet Message Bodies",
	RFC 2045, November 1996.		RFC 2045, November 1996.
	[17] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service		[17] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
			Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
			November 1996.
			[18] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
	Extension for Delivery Status Notifications (DSNs)", RFC 3461,		Extension for Delivery Status Notifications (DSNs)", RFC 3461,
	January 2003.		January 2003.
			[19] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
			January 2003.
	Author's Address		Author's Address
	Chris Newman		Chris Newman
	Sun Microsystems		Sun Microsystems
	1050 Lakes Drive		1050 Lakes Drive
	West Covina, CA 91790		West Covina, CA 91790
	US		US
	EMail: chris.newman@sun.com		EMail: chris.newman@sun.com
			Appendix A. Document History
			Note to RFC Editor: delete this section before publication as an RFC.
			A.1 Changes from burl-00
			o Enhanced security considerations section
			o Updated URLAUTH reference
			o Added updates to RFC 3463
			o Added Response Codes section
			A.2 Changes from compose-01
			o Removed the conversion argument to BURL to simplify.
			o Replace the conversion section with the simpler 8-bit and Binary
			section.
			o Removed the failhow argument to simplify and eliminate
			race-condition which bothered people.
			o Simplify specification to eliminate "composition" model and just
			focus on BURL command.
			o Make it clear that BURL can be used without the chunking
			extension.
			A.3 Changes from compose-00
			o Added the end-marker "LAST", so this could be used without BDAT
			and works with a pre-composed message.
			o Changed "Message Composition" to "Message Submission with
			Composition" in several places.
			o Correct Spelling Errors
	Intellectual Property Statement		Intellectual Property Statement
	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 or other rights that might be claimed to		intellectual property 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; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of		claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can		proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	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 which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
End of changes. 58 change blocks.
	95 lines changed or deleted		258 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/