< draft-siemborski-rfc2554bis-08.txt		draft-siemborski-rfc2554bis-09.txt >
	Network Working Group Robert Siemborski		Network Working Group Robert Siemborski
	INTERNET-DRAFT Google, Inc.		INTERNET-DRAFT Google, Inc.
	Intended status: Standards Track Alexey Melnikov		Intended status: Standards Track Alexey Melnikov
	Obsoletes: RFC 2554 (if approved) Isode Limited		Obsoletes: RFC 2554 (if approved) Isode Limited
	Updates: RFC 3463 February 2007		Updates: RFC 3463 April 2007
	Expires: August 2007		Expires: October 2007
	SMTP Service Extension for Authentication		SMTP Service Extension for Authentication
	<draft-siemborski-rfc2554bis-08.txt>		<draft-siemborski-rfc2554bis-09.txt>
	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		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its		Engineering Task Force (IETF), its areas, and its
	working groups. Note that other groups may also distribute		working groups. Note that other groups may also distribute
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	SMTP Service Extension for Authentication February 2007
	Abstract		Abstract
	This document defines a Simple Mail Transport Protocol (SMTP)		This document defines a Simple Mail Transport Protocol (SMTP)
	extension whereby an SMTP client may indicate an authentication		extension whereby an SMTP client may indicate an authentication
	mechanism to the server, perform an authentication protocol		mechanism to the server, perform an authentication protocol
	exchange, and optionally negotiate a security layer for subsequent		exchange, and optionally negotiate a security layer for subsequent
	protocol interactions during this session. This extension includes		protocol interactions during this session. This extension includes
	a profile of the Simple Authentication and Security Layer (SASL) for		a profile of the Simple Authentication and Security Layer (SASL) for
	SMTP.		SMTP.
	This document obsoletes RFC 2554 and replaces it as a Proposed		This document obsoletes RFC 2554.
	Standard.
	SMTP Service Extension for Authentication February 2007
	1. Introduction		1. Introduction
	This document defines a Simple Mail Transport Protocol (SMTP)		This document defines a Simple Mail Transport Protocol (SMTP)
	extension whereby an SMTP client may indicate an authentication		extension whereby an SMTP client may indicate an authentication
	mechanism to the server, perform an authentication protocol		mechanism to the server, perform an authentication protocol
	exchange, optionally negotiate a security layer for subsequent		exchange, optionally negotiate a security layer for subsequent
	protocol interactions during this session and, during a mail		protocol interactions during this session and, during a mail
	transaction, optionally specify a mailbox associated with the		transaction, optionally specify a mailbox associated with the
	identity which submitted the message to the mail delivery system.		identity which submitted the message to the mail delivery system.
	skipping to change at page 1, line 106 ¶		skipping to change at page 1, line 101 ¶
	separated list of the names of available [SASL] mechanisms.		separated list of the names of available [SASL] mechanisms.
	The list of available mechanisms MAY change after a successful		The list of available mechanisms MAY change after a successful
	STARTTLS command [SMTP-TLS].		STARTTLS command [SMTP-TLS].
	4. A new [SMTP] verb "AUTH" is defined.		4. A new [SMTP] verb "AUTH" is defined.
	5. An optional parameter using the keyword "AUTH" is added to the		5. An optional parameter using the keyword "AUTH" is added to the
	MAIL FROM command, and extends the maximum line length of the		MAIL FROM command, and extends the maximum line length of the
	MAIL FROM command by 500 characters.		MAIL FROM command by 500 characters.
	SMTP Service Extension for Authentication February 2007
	6. This extension is appropriate for the submission protocol		6. This extension is appropriate for the submission protocol
	[SUBMIT].		[SUBMIT].
	4. The AUTH Command		4. The AUTH Command
	AUTH mechanism [initial-response]		AUTH mechanism [initial-response]
	Arguments:		Arguments:
	mechanism: A string identifying a [SASL] authentication		mechanism: A string identifying a [SASL] authentication
	mechanism.		mechanism.
	skipping to change at page 1, line 156 ¶		skipping to change at page 1, line 149 ¶
	The SASL authentication exchange consists of a series of		The SASL authentication exchange consists of a series of
	server challenges and client responses that are specific to		server challenges and client responses that are specific to
	the chosen [SASL] mechanism.		the chosen [SASL] mechanism.
	A server challenge is sent as a 334 reply with the text part		A server challenge is sent as a 334 reply with the text part
	containing the [BASE64] encoded string supplied by the SASL		containing the [BASE64] encoded string supplied by the SASL
	mechanism. This challenge MUST NOT contain any text other		mechanism. This challenge MUST NOT contain any text other
	than the BASE64 encoded challenge.		than the BASE64 encoded challenge.
	SMTP Service Extension for Authentication February 2007
	A client response consists of a line containing a [BASE64]		A client response consists of a line containing a [BASE64]
	encoded string. If the client wishes to cancel the		encoded string. If the client wishes to cancel the
	authentication exchange, it issues a line with a single "*".		authentication exchange, it issues a line with a single "*".
	If the server receives such a response, it MUST reject the		If the server receives such a response, it MUST reject the
	AUTH command by sending a 501 reply.		AUTH command by sending a 501 reply.
	The optional initial response argument to the AUTH command is		The optional initial response argument to the AUTH command is
	used to save a round trip when using authentication mechanisms		used to save a round trip when using authentication mechanisms
	that support an initial client response. If the initial		that support an initial client response. If the initial
	response argument is omitted and the chosen mechanism requires		response argument is omitted and the chosen mechanism requires
	skipping to change at page 1, line 206 ¶		skipping to change at page 1, line 197 ¶
	using the "*" response. In particular, servers and clients		using the "*" response. In particular, servers and clients
	MUST reject (and not ignore) any character not explicitly		MUST reject (and not ignore) any character not explicitly
	allowed by the BASE64 alphabet, and MUST reject any sequence		allowed by the BASE64 alphabet, and MUST reject any sequence
	of BASE64 characters that contains the pad character ('=')		of BASE64 characters that contains the pad character ('=')
	anywhere other than the end of the string (e.g. "=AAA" and		anywhere other than the end of the string (e.g. "=AAA" and
	"AAA=BBB" are not allowed).		"AAA=BBB" are not allowed).
	Note that these [BASE64] strings can be much longer than		Note that these [BASE64] strings can be much longer than
	normal SMTP commands. Clients and servers MUST be able to		normal SMTP commands. Clients and servers MUST be able to
	handle the maximum encoded size of challenges and responses		handle the maximum encoded size of challenges and responses
	SMTP Service Extension for Authentication February 2007
	generated by their supported authentication mechanisms. This		generated by their supported authentication mechanisms. This
	requirement is independent of any line length limitations the		requirement is independent of any line length limitations the
	client or server may have in other parts of its protocol		client or server may have in other parts of its protocol
	implementation. (At the time of writing of this document,		implementation. (At the time of writing of this document,
	12288 is considered to be sufficiently big line length limit		12288 is considered to be sufficiently big line length limit
	for handling of deployed authentication mechanisms.) If,		for handling of deployed authentication mechanisms.) If,
	during an authentication exchange, the server receives a line		during an authentication exchange, the server receives a line
	that is longer than the server's authentication buffer, the		that is longer than the server's authentication buffer, the
	server fails the AUTH command with the 500 reply. Servers		server fails the AUTH command with the 500 reply. Servers
	using the enhanced status codes extension [ESMTP-CODES] SHOULD		using the enhanced status codes extension [ESMTP-CODES] SHOULD
	skipping to change at page 1, line 257 ¶		skipping to change at page 1, line 245 ¶
	the CRLF of its success reply.		the CRLF of its success reply.
	When a security layer takes effect, the SMTP protocol is reset		When a security layer takes effect, the SMTP protocol is reset
	to the initial state (the state in SMTP after a server issues		to the initial state (the state in SMTP after a server issues
	a 220 service ready greeting). The server MUST discard any		a 220 service ready greeting). The server MUST discard any
	knowledge obtained from the client, such as the EHLO argument,		knowledge obtained from the client, such as the EHLO argument,
	which was not obtained from the SASL negotiation itself.		which was not obtained from the SASL negotiation itself.
	Likewise, the client MUST discard any knowledge obtained from		Likewise, the client MUST discard any knowledge obtained from
	the server, such as the list of SMTP service extensions, which		the server, such as the list of SMTP service extensions, which
	was not obtained from the SASL negotiation itself (Note that a		was not obtained from the SASL negotiation itself (Note that a
	SMTP Service Extension for Authentication February 2007
	client MAY compare the advertised SASL mechanisms before and		client MAY compare the advertised SASL mechanisms before and
	after authentication in order to detect an active down-		after authentication in order to detect an active down-
	negotiation attack).		negotiation attack).
	The client SHOULD send an EHLO command as the first command		The client SHOULD send an EHLO command as the first command
	after a successful SASL negotiation which results in the		after a successful SASL negotiation which results in the
	enabling of a security layer.		enabling of a security layer.
	When both [TLS] and SASL security layers are in effect, when		When both [TLS] and SASL security layers are in effect, when
	sending data the TLS encoding MUST be applied after the SASL		sending data the TLS encoding MUST be applied after the SASL
	skipping to change at page 1, line 282 ¶		skipping to change at page 1, line 267 ¶
	The service name specified by this protocol's profile of SASL		The service name specified by this protocol's profile of SASL
	is "smtp". This service name is also to be used for the		is "smtp". This service name is also to be used for the
	[SUBMIT] protocol.		[SUBMIT] protocol.
	If an AUTH command fails, the client MAY proceed without		If an AUTH command fails, the client MAY proceed without
	authentication, Alternatively, the client MAY try another		authentication, Alternatively, the client MAY try another
	authentication mechanism or present different credentials by		authentication mechanism or present different credentials by
	issuing another AUTH command.		issuing another AUTH command.
	To ensure interoperability, client and server implementations
	of this extension MUST implement the [PLAIN] SASL mechanism.
	Note: a server implementation MUST implement a configuration		Note: a server implementation MUST implement a configuration
	in which it does NOT permit any plaintext password mechanisms,		in which it does NOT permit any plaintext password mechanisms,
	unless either the STARTTLS [SMTP-TLS] command has been		unless either the STARTTLS [SMTP-TLS] command has been
	negotiated or some other mechanism that protects the session		negotiated or some other mechanism that protects the session
	from password snooping has been provided. Server sites SHOULD		from password snooping has been provided. Server sites SHOULD
	NOT use any configuration which permits a plaintext password		NOT use any configuration which permits a plaintext password
	mechanism without such a protection mechanism against password		mechanism without such a protection mechanism against password
	snooping.		snooping.
			To ensure interoperability, client and server implementations
			of this extension MUST implement the [PLAIN] SASL mechanism
			running over TLS [TLS] [SMTP-TLS]. See also section 15 for
			additional requirements on implementations of [PLAIN] over
			[TLS].
	Note that many existing client and server implementations		Note that many existing client and server implementations
	implement CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to		implement CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to
	insure interoperability with deployed software new		ensure interoperability with deployed software new
	implementations MAY implement it, however implementations		implementations MAY implement it, however implementations
	should be aware that this SASL mechanism doesn't provide any		should be aware that this SASL mechanism doesn't provide any
	server authentication. Implementations that want to provide		server authentication. Note that at the time of writing of
	server authentication are encouraged to implement SASL		this document the SASL Working Group is working on several
	mechanisms such as DIGEST-MD5 [DIGEST-MD5].		replacement SASL mechanisms that provide server authentication
			and other features.
	When the AUTH command is used together with the [PIPELINING]		When the AUTH command is used together with the [PIPELINING]
	extension, it MUST be the last command in a pipelined group of		extension, it MUST be the last command in a pipelined group of
	commands. The only exception to this rule is when the AUTH		commands. The only exception to this rule is when the AUTH
	command contains an initial response for a SASL mechanism that		command contains an initial response for a SASL mechanism that
	allows client to send data first and is known to complete in		allows client to send data first and is known to complete in
	SMTP Service Extension for Authentication February 2007
	one round-trip. Two examples of such SASL mechanisms are PLAIN		one round-trip. Two examples of such SASL mechanisms are PLAIN
	[PLAIN] and EXTERNAL [SASL].		[PLAIN] and EXTERNAL [SASL].
	4.1. Examples		4.1. Examples
	Here is an example of a client attempting AUTH using the [PLAIN]		Here is an example of a client attempting AUTH using the [PLAIN]
	SASL mechanism under a TLS layer, and making use of the initial		SASL mechanism under a TLS layer, and making use of the initial
	client response:		client response:
	S: 220-smtp.example.com ESMTP Server		S: 220-smtp.example.com ESMTP Server
	skipping to change at page 1, line 356 ¶		skipping to change at page 1, line 342 ¶
	(note: there is a single space following the 334		(note: there is a single space following the 334
	on the following line)		on the following line)
	S: 334		S: 334
	C: dGVzdAB0ZXN0ADEyMzQ=		C: dGVzdAB0ZXN0ADEyMzQ=
	S: 235 2.7.0 Authentication successful		S: 235 2.7.0 Authentication successful
	Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which		Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which
	the client does not begin the authentication exchange, and includes		the client does not begin the authentication exchange, and includes
	a server challenge:		a server challenge:
	SMTP Service Extension for Authentication February 2007
	S: 220-smtp.example.com ESMTP Server		S: 220-smtp.example.com ESMTP Server
	C: EHLO client.example.com		C: EHLO client.example.com
	S: 250-smtp.example.com Hello client.example.com		S: 250-smtp.example.com Hello client.example.com
	S: 250-AUTH DIGEST-MD5 CRAM-MD5		S: 250-AUTH DIGEST-MD5 CRAM-MD5
	S: 250-ENHANCEDSTATUSCODES		S: 250-ENHANCEDSTATUSCODES
	S: 250 STARTTLS		S: 250 STARTTLS
	C: AUTH CRAM-MD5		C: AUTH CRAM-MD5
	S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk		S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk
	dT4=		dT4=
	C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==		C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==
	skipping to change at page 1, line 405 ¶		skipping to change at page 1, line 389 ¶
	A <mailbox> (see section 4.1.2 of [SMTP]) that is associated		A <mailbox> (see section 4.1.2 of [SMTP]) that is associated
	with the identity which submitted the message to the delivery		with the identity which submitted the message to the delivery
	system, or the two character sequence "<>" indicating such an		system, or the two character sequence "<>" indicating such an
	identity is unknown or insufficiently authenticated. To comply		identity is unknown or insufficiently authenticated. To comply
	with restrictions imposed on ESMTP parameters, the <mailbox> is		with restrictions imposed on ESMTP parameters, the <mailbox> is
	encoded inside an xtext. The syntax of an xtext is described in		encoded inside an xtext. The syntax of an xtext is described in
	Section 4 of [ESMTP-DSN].		Section 4 of [ESMTP-DSN].
	Note:		Note:
	For the purposes of this discussion, "authenticated identity"		For the purposes of this discussion, "authenticated identity"
	SMTP Service Extension for Authentication February 2007
	refers to the identity (if any) derived from the authorization		refers to the identity (if any) derived from the authorization
	identity of previous AUTH command, while the terms "authorized		identity of previous AUTH command, while the terms "authorized
	identity" and "supplied <mailbox>" refer to the sender identity		identity" and "supplied <mailbox>" refer to the sender identity
	that is being associated with a particular message. Note that		that is being associated with a particular message. Note that
	one authenticated identity may be able to identify messages as		one authenticated identity may be able to identify messages as
	being sent by any number of authorized identities within a		being sent by any number of authorized identities within a
	single session. For example, this may be the case when an SMTP		single session. For example, this may be the case when an SMTP
	server (one authenticated identity) is processing its queue		server (one authenticated identity) is processing its queue
	(many messages with distinct authorized identities).		(many messages with distinct authorized identities).
	skipping to change at page 1, line 456 ¶		skipping to change at page 1, line 437 ¶
	[SMTP]. If the implementation cannot generate a valid		[SMTP]. If the implementation cannot generate a valid
	<mailbox>, it MUST transmit AUTH=<> when relaying this message.		<mailbox>, it MUST transmit AUTH=<> when relaying this message.
	If the server does not sufficiently trust the authenticated		If the server does not sufficiently trust the authenticated
	identity of the client, or if the client is not authenticated,		identity of the client, or if the client is not authenticated,
	then the server MUST behave as if the AUTH=<> parameter was		then the server MUST behave as if the AUTH=<> parameter was
	supplied. The server MAY, however, write the value of any		supplied. The server MAY, however, write the value of any
	supplied AUTH parameter to a log file.		supplied AUTH parameter to a log file.
	If an AUTH=<> parameter was supplied, either explicitly or due		If an AUTH=<> parameter was supplied, either explicitly or due
	SMTP Service Extension for Authentication February 2007
	to the requirement in the previous paragraph, then the server		to the requirement in the previous paragraph, then the server
	MUST supply the AUTH=<> parameter when relaying the message to		MUST supply the AUTH=<> parameter when relaying the message to
	any server which it has authenticated to using the AUTH		any server which it has authenticated to using the AUTH
	extension.		extension.
	A server MAY treat expansion of a mailing list as a new		A server MAY treat expansion of a mailing list as a new
	submission, setting the AUTH parameter to the mailing list		submission, setting the AUTH parameter to the mailing list
	address or mailing list administration address when relaying the		address or mailing list administration address when relaying the
	message to list subscribers.		message to list subscribers.
	skipping to change at page 1, line 505 ¶		skipping to change at page 1, line 483 ¶
	235 2.7.0 Authentication Succeeded		235 2.7.0 Authentication Succeeded
	This response to the AUTH command indicates that the authentication		This response to the AUTH command indicates that the authentication
	was successful.		was successful.
	432 4.7.12 A password transition is needed		432 4.7.12 A password transition is needed
	This response to the AUTH command indicates that the user needs to		This response to the AUTH command indicates that the user needs to
	transition to the selected authentication mechanism. This is		transition to the selected authentication mechanism. This is
	SMTP Service Extension for Authentication February 2007
	typically done by authenticating once using the [PLAIN]		typically done by authenticating once using the [PLAIN]
	authentication mechanism. The selected mechanism SHOULD then work		authentication mechanism. The selected mechanism SHOULD then work
	for authentications in subsequent sessions.		for authentications in subsequent sessions.
	454 4.7.0 Temporary authentication failure		454 4.7.0 Temporary authentication failure
	This response to the AUTH command indicates that the authentication		This response to the AUTH command indicates that the authentication
	failed due to a temporary server failure. The client SHOULD NOT		failed due to a temporary server failure. The client SHOULD NOT
	prompt the user for another password in this case, and instead		prompt the user for another password in this case, and instead
	notify the user of server failure.		notify the user of server failure.
	skipping to change at page 1, line 556 ¶		skipping to change at page 1, line 531 ¶
	538 5.7.11 Encryption required for requested authentication		538 5.7.11 Encryption required for requested authentication
	mechanism		mechanism
	This response to the AUTH command indicates that the selected		This response to the AUTH command indicates that the selected
	authentication mechanism may only be used when the underlying SMTP		authentication mechanism may only be used when the underlying SMTP
	connection is encrypted. Note that this response code is documented		connection is encrypted. Note that this response code is documented
	here for historical purposes only. Modern implementations SHOULD		here for historical purposes only. Modern implementations SHOULD
	NOT advertise mechanisms that are not permitted due to lack of		NOT advertise mechanisms that are not permitted due to lack of
	encryption, unless an encryption layer of sufficient strength is		encryption, unless an encryption layer of sufficient strength is
			currently being employed.
	SMTP Service Extension for Authentication February 2007		This document adds several new enhanced status code to the list
			defined in [ENHANCED]:
	currently being employed.		The following 3 Enhanced Status Codes were defined above:
	This document adds a new enhanced status code to the list defined in		5.7.8 Authentication credentials invalid
	[ENHANCED]:		5.7.9 Authentication mechanism is too weak
			5.7.11 Encryption required for requested authentication mechanism
	X.5.6 Authentication Exchange line is too long		X.5.6 Authentication Exchange line is too long
	This enhanced status code SHOULD be returned when the server fails		This enhanced status code SHOULD be returned when the server fails
	the AUTH command due to the client sending a [BASE64] response which		the AUTH command due to the client sending a [BASE64] response which
	is longer than the maximum buffer size available for the currently		is longer than the maximum buffer size available for the currently
	selected SASL mechanism.		selected SASL mechanism. This is useful for both permanent and
			persistent transient errors.
	7. Additional requirements on servers		7. Additional requirements on servers
	As described in Section 4.4 of [SMTP], an SMTP server that receives		As described in Section 4.4 of [SMTP], an SMTP server that receives
	a message for delivery or further processing MUST insert the		a message for delivery or further processing MUST insert the
	"Received:" header field at the beginning of the message content.		"Received:" header field at the beginning of the message content.
	This document places additional requirements on the content of a		This document places additional requirements on the content of a
	generated "Received:" header field. Upon successful authentication a		generated "Received:" header field. Upon successful authentication a
	server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when		server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when
	appropriate) keyword in the "with" clause of the Received header		appropriate) keyword in the "with" clause of the Received header
	skipping to change at page 1, line 595 ¶		skipping to change at page 1, line 574 ¶
	Form notation as specified in [ABNF]. Non-terminals referenced but		Form notation as specified in [ABNF]. Non-terminals referenced but
	not defined below are as defined by [ABNF] or [SASL]. The non-		not defined below are as defined by [ABNF] or [SASL]. The non-
	terminal <mailbox> is defined in [SMTP].		terminal <mailbox> is defined in [SMTP].
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.		accept these strings in a case-insensitive fashion.
	hexchar = "+" HEXDIG HEXDIG		hexchar = "+" HEXDIG HEXDIG
	xchar = %x21-2A / %x2C-3C / %x3E-7E		xchar = %x21-2A / %x2C-3C / %x3E-7E
	;; US-ASCII except for "+", "=", SP and CTL		;; US-ASCII except for "+", "=", SP and CTL
	xtext = *(xchar / hexchar)		xtext = *(xchar / hexchar)
	;; non-US-ASCII is only allowed as hexchar		;; non-US-ASCII is only allowed as hexchar
	SMTP Service Extension for Authentication February 2007
	auth-command = "AUTH" SP sasl-mech [SP initial-response]		auth-command = "AUTH" SP sasl-mech [SP initial-response]
	*(CRLF [base64]) [CRLF cancel-response]		*(CRLF [base64]) [CRLF cancel-response]
	CRLF		CRLF
	;; <sasl-mech> is defined in [SASL]		;; <sasl-mech> is defined in [SASL]
	auth-param = "AUTH=" xtext		auth-param = "AUTH=" xtext
	;; Parameter to the MAIL FROM command.		;; Parameter to the MAIL FROM command.
	;; This non-terminal complies with		;; This non-terminal complies with
	;; syntax defined by esmtp-param [SMTP].		;; syntax defined by esmtp-param [SMTP].
	;;		;;
	skipping to change at page 1, line 650 ¶		skipping to change at page 1, line 626 ¶
	If a client uses this extension to get an encrypted tunnel through		If a client uses this extension to get an encrypted tunnel through
	an insecure network to a cooperating server, it needs to be		an insecure network to a cooperating server, it needs to be
	configured to never send mail to that server when the connection is		configured to never send mail to that server when the connection is
	not mutually authenticated and encrypted. Otherwise, an attacker		not mutually authenticated and encrypted. Otherwise, an attacker
	could steal the client's mail by hijacking the [SMTP] connection and		could steal the client's mail by hijacking the [SMTP] connection and
	either pretending the server does not support the Authentication		either pretending the server does not support the Authentication
	extension or causing all AUTH commands to fail.		extension or causing all AUTH commands to fail.
	Before the [SASL] negotiation has begun, any protocol interactions		Before the [SASL] negotiation has begun, any protocol interactions
	are performed in the clear and may be modified by an active		are performed in the clear and may be modified by an active
	SMTP Service Extension for Authentication February 2007
	attacker. For this reason, clients and servers MUST discard any		attacker. For this reason, clients and servers MUST discard any
	knowledge obtained prior to the start of the SASL negotiation upon		knowledge obtained prior to the start of the SASL negotiation upon
	the establishment of a security layer.		the establishment of a security layer.
	This mechanism does not protect the TCP port, so an active attacker		This mechanism does not protect the TCP port, so an active attacker
	may redirect a relay connection attempt (i.e. a connection between		may redirect a relay connection attempt (i.e. a connection between
	two MTAs) to the submission port [SUBMIT]. The AUTH=<> parameter		two MTAs) to the submission port [SUBMIT]. The AUTH=<> parameter
	prevents such an attack from causing a relayed message, in the		prevents such an attack from causing a relayed message, in the
	absence of other envelope authentication, from picking up the		absence of other envelope authentication, from picking up the
	authentication of the relay client.		authentication of the relay client.
	skipping to change at page 1, line 675 ¶		skipping to change at page 1, line 648 ¶
	whenever a suitable [SASL] mechanism is advertised. Therefore, it		whenever a suitable [SASL] mechanism is advertised. Therefore, it
	may not be desirable for a submission server [SUBMIT] to advertise a		may not be desirable for a submission server [SUBMIT] to advertise a
	SASL mechanism when use of that mechanism grants the clients no		SASL mechanism when use of that mechanism grants the clients no
	benefits over anonymous submission.		benefits over anonymous submission.
	Servers MAY implement a policy whereby the connection is dropped		Servers MAY implement a policy whereby the connection is dropped
	after a number of failed authentication attempts. If they do so,		after a number of failed authentication attempts. If they do so,
	they SHOULD NOT drop the connection until at least 3 attempts to		they SHOULD NOT drop the connection until at least 3 attempts to
	authenticate have failed.		authenticate have failed.
	Implementations MUST support a configuration where SASL mechanisms		If an implementation supports SASL mechanisms that are vulnerable to
	that are vulnerable to passive eavesdropping attacks (such as		passive eavesdropping attacks (such as [PLAIN]), then the
	[PLAIN]) are not advertised or used without the presence of an		implementation MUST support at least one configuration where these
	external security layer such as [TLS].		SASL mechanisms are not advertised or used without the presence of
			an external security layer such as [TLS].
	This extension is not intended to replace or be used instead of end-		This extension is not intended to replace or be used instead of end-
	to-end message signature and encryption systems such as [S/MIME] or		to-end message signature and encryption systems such as [S/MIME] or
	[PGP]. This extension addresses a different problem than end-to-end		[PGP]. This extension addresses a different problem than end-to-end
	systems; it has the following key differences:		systems; it has the following key differences:
	1. It is generally useful only within a trusted enclave.		1. It is generally useful only within a trusted enclave.
	2. It protects the entire envelope of a message, not just the		2. It protects the entire envelope of a message, not just the
	message's body.		message's body.
	3. It authenticates the message submission, not authorship of the		3. It authenticates the message submission, not authorship of the
	message content.		message content.
	4. When mutual authentication is used along with a security		4. When mutual authentication is used along with a security
	layer, it can give the sender some assurance that the message		layer, it can give the sender some assurance that the message
	was successfully delivered to the next hop.		was successfully delivered to the next hop.
	Additional security considerations are mentioned in the [SASL]		Additional security considerations are mentioned in the [SASL]
	specification. Additional security considerations specific to a		specification. Additional security considerations specific to a
	particular SASL mechanism are described in the relevant specification.		particular SASL mechanism are described in the relevant
			specification. Additional security considerations for [PLAIN] over
	SMTP Service Extension for Authentication February 2007		[TLS] are mentioned in Section 15 of this document.
	10. IANA Considerations		10. IANA Considerations
	This document requests that the IANA update the entry for the "smtp"		This document requests that the IANA update the entry for the "smtp"
	SASL protocol name to point at this document.		SASL protocol name to point at this document.
	This document requests that the IANA updates registration of the		This document requests that the IANA updates registration of the
	Authentication SMTP service extension as defined in Section 3 of		Authentication SMTP service extension as defined in Section 3 of
	this document.		this document. This registry is currently located at
			<http://www.iana.org/assignments/mail-parameters>.
	11. Normative References		11. Normative References
	[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, October 2005.		Specifications: ABNF", RFC 4234, October 2005.
	[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data		[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[ESMTP-CODES]		[ESMTP-CODES]
	skipping to change at page 1, line 750 ¶		skipping to change at page 1, line 725 ¶
	[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,		[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.		April 2001.
	[SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over		[SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, February 2002.		Transport Layer Security", RFC 3207, February 2002.
	[StringPrep]		[StringPrep]
	Hoffman, P., Blanchet, M., "Preparation of Internationalized		Hoffman, P., Blanchet, M., "Preparation of Internationalized
	Strings ("stringprep")", RFC 3454, December 2002.		Strings ("stringprep")", RFC 3454, December 2002.
	SMTP Service Extension for Authentication February 2007
	[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",		[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail",
	RFC 4409, April 2006.		RFC 4409, April 2006.
	[SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types		[SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types
	Registration", RFC 3848, July 2004.		Registration", RFC 3848, July 2004.
	[PLAIN] Zeilenga, K. (Ed.), "The PLAIN Simple Authentication and		[PLAIN] Zeilenga, K. (Ed.), "The PLAIN Simple Authentication and
	Security Layer (SASL) Mechanism", RFC 4616, August 2006.		Security Layer (SASL) Mechanism", RFC 4616, August 2006.
			[X509] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
			Public Key Infrastructure Certificate and Certificate
			Revocation List (CRL) Profile", RFC 3280, April 2002.
	12. Informative References		12. Informative References
	[PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)",		[PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)",
	RFC 2015, October 1996.		RFC 2015, October 1996.
	[S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC		[S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
	2633, June 1999.		2633, June 1999.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[PIPELINING]		[PIPELINING]
	Freed, N., "SMTP Service Extension for Command Pipelining",		Freed, N., "SMTP Service Extension for Command Pipelining",
	RFC 2920, September 2000.		RFC 2920, September 2000.
	[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, IMAP/POP AUTHorize		[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, IMAP/POP AUTHorize
	Extension for Simple Challenge/Response", RFC 2195,		Extension for Simple Challenge/Response", RFC 2195,
	September 1997.		September 1997.
	[DIGEST-MD5]
	Melnikov, A. (Ed.), "Using Digest Authentication as a SASL
	Mechanism", draft-ietf-sasl-rfc2831bis-*.txt, a work in
	progress.
	13. Editors' Addresses		13. Editors' Addresses
	Robert Siemborski		Robert Siemborski
	Google, Inc.		Google, Inc.
	1600 Ampitheatre Parkway		1600 Ampitheatre Parkway
	Mountain View, CA 94043, USA		Mountain View, CA 94043, USA
	+1 650 623 6925		+1 650 623 6925
	robsiemb@google.com		robsiemb@google.com
	Alexey Melnikov		Alexey Melnikov
	Isode Limited		Isode Limited
	5 Castle Business Village, 36 Station Road,		5 Castle Business Village, 36 Station Road,
	Hampton, Middlesex, TW12 2BX, UK		Hampton, Middlesex, TW12 2BX, UK
	SMTP Service Extension for Authentication February 2007
	Alexey.Melnikov@isode.com		Alexey.Melnikov@isode.com
	14. Acknowledgments:		14. Acknowledgments:
	Editors would like to acknowledge the contributions of John Myers		Editors would like to acknowledge the contributions of John Myers
	and other contributors to RFC 2554, on which this document draws		and other contributors to RFC 2554, on which this document draws
	from heavily.		from heavily.
	Editors would also like to thank Ken Murchison, Mark Crispin, Chris		Editors would also like to thank Ken Murchison, Mark Crispin, Chris
	Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned Freed,		Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned Freed,
	John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther and		John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, Sam
	Lisa Dusseault for the time they devoted to reviewing of this		Hartman, Russ Housley, Cullen Jennings and Lisa Dusseault for the
	document and/or for the comments received.		time they devoted to reviewing of this document and/or for the
			comments received.
	15. Changes Since RFC 2554		15. Additional requirements when using SASL PLAIN over TLS
			This section is normative for SMTP implementations that support SASL
			[PLAIN] over [TLS].
			If an SMTP client is willing to use SASL PLAIN over TLS to
			authenticate to the SMTP server, the client verifies the server
			certificate according to the rules of [X509]. If the server has not
			provided any certificate, or if the certificate verification fails,
			the client MUST NOT attempt to authenticate using the SASL PLAIN
			mechanism.
			After a successful [TLS] negotiation, the client MUST check its
			understanding of the server hostname against the server's identity
			as presented in the server Certificate message, in order to prevent
			man-in-the-middle attacks. If the match fails, the client MUST NOT
			attempt to authenticate using the SASL PLAIN mechanism. Matching is
			performed according to the following rules:
			The client MUST use the server hostname it used to open the
			connection as the value to compare against the server name as
			expressed in the server certificate. The client MUST NOT use
			any form of the server hostname derived from an insecure remote
			source (e.g., insecure DNS lookup). CNAME canonicalization is
			not done.
			If a subjectAltName extension of type dNSName is present in the
			certificate, it SHOULD be used as the source of the server's
			identity.
			Matching is case-insensitive.
			A "*" wildcard character MAY be used as the left-most name
			component in the certificate. For example, *.example.com would
			match a.example.com, foo.example.com, etc. but would not match
			example.com.
			If the certificate contains multiple names (e.g., more than one
			dNSName field), then a match with any one of the fields is
			considered acceptable.
			16. Changes Since RFC 2554
	1. Clarify that servers MUST support the use of the AUTH=mailbox		1. Clarify that servers MUST support the use of the AUTH=mailbox
	parameter to MAIL FROM, even when the client is not		parameter to MAIL FROM, even when the client is not
	authenticated.		authenticated.
	2. Clarify the initial-client-send requirements, and give		2. Clarify the initial-client-send requirements, and give
	additional examples.		additional examples.
	3. Update references to newer versions of various specifications.		3. Update references to newer versions of various specifications.
	skipping to change at page 1, line 849 ¶		skipping to change at page 1, line 860 ¶
	9. Updated ABNF section to use RFC 4234.		9. Updated ABNF section to use RFC 4234.
	10. Clarified interaction with SMTP PIPELINING extension.		10. Clarified interaction with SMTP PIPELINING extension.
	11. Added a reference to RFC 3848.		11. Added a reference to RFC 3848.
	12. Added a new Enhanced Status Code for "authentication line too		12. Added a new Enhanced Status Code for "authentication line too
	long" case.		long" case.
	SMTP Service Extension for Authentication February 2007
	13. General other editorial clarifications.		13. General other editorial clarifications.
	16. Intellectual Property		17. Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described		to pertain to the implementation or use of the technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; nor does it represent that		rights might or might not be available; nor does it represent that
	it has made any independent effort to identify any such rights.		it has made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC		Information on the procedures with respect to rights in RFC
	documents can be found in BCP 78 and BCP 79.		documents can be found in BCP 78 and BCP 79.
	skipping to change at page 1, line 877 ¶		skipping to change at page 1, line 886 ¶
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	17. Full Copyright Statement		18. Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE		WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.		FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	SMTP Service Extension for Authentication February 2007
	Internet Society.		Internet Society.
	SMTP Service Extension for Authentication February 2007
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3		2. How to Read This Document . . . . . . . . . . . . . . . . . . . . 3
	3. The Authentication Service Extension . . . . . . . . . . . . . . 3		3. The Authentication Service Extension . . . . . . . . . . . . . . 3
	4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4		4. The AUTH Command . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. The AUTH Parameter to the MAIL FROM command . . . . . . . . . . . 9		5. The AUTH Parameter to the MAIL FROM command . . . . . . . . . . . 9
	5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 11		6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Additional requirements on servers . . . . . . . . . . . . . . . 13		7. Additional requirements on servers . . . . . . . . . . . . . . . 13
	8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
	11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16
	12. Informative References . . . . . . . . . . . . . . . . . . . . . 17		12. Informative References . . . . . . . . . . . . . . . . . . . . . 17
	13. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		13. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18
	15. Changes Since RFC 2554 . . . . . . . . . . . . . . . . . . . . . 18		15. Additional requirements when using SASL PLAIN over TLS . . . . . 18
	16. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 19		16. Changes Since RFC 2554 . . . . . . . . . . . . . . . . . . . . . 19
	17. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19		17. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 20
			18. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20
End of changes. 41 change blocks.
	85 lines changed or deleted		89 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/