7Network Working Group R. Siemborski, Ed.
8Request for Comments: 4954 Google, Inc.
9Obsoletes: 2554 A. Melnikov, Ed.
10Updates: 3463 Isode Limited
11Category: Standards Track July 2007
14 SMTP Service Extension for Authentication
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The IETF Trust (2007).
30 This document defines a Simple Mail Transport Protocol (SMTP)
31 extension whereby an SMTP client may indicate an authentication
32 mechanism to the server, perform an authentication protocol exchange,
33 and optionally negotiate a security layer for subsequent protocol
34 interactions during this session. This extension includes a profile
35 of the Simple Authentication and Security Layer (SASL) for SMTP.
37 This document obsoletes RFC 2554.
58Siemborski & Melnikov Standards Track [Page 1]
60RFC 4954 SMTP Service Extension for Authentication July 2007
65 1. Introduction ....................................................2
66 2. How to Read This Document .......................................2
67 3. The Authentication Service Extension ............................3
68 4. The AUTH Command ................................................3
69 4.1. Examples ...................................................7
70 5. The AUTH Parameter to the MAIL FROM command .....................9
71 5.1. Examples ..................................................10
72 6. Status Codes ...................................................11
73 7. Additional requirements on servers .............................12
74 8. Formal Syntax ..................................................13
75 9. Security Considerations ........................................14
76 10. IANA Considerations ...........................................15
77 11. Normative References ..........................................15
78 12. Informative References ........................................16
79 13. Acknowledgments ...............................................17
80 14. Additional Requirements When Using SASL PLAIN over TLS ........17
81 15. Changes since RFC 2554 ........................................18
85 This document defines a Simple Mail Transport Protocol (SMTP)
86 extension whereby an SMTP client may indicate an authentication
87 mechanism to the server, perform an authentication protocol exchange,
88 optionally negotiate a security layer for subsequent protocol
89 interactions during this session and, during a mail transaction,
90 optionally specify a mailbox associated with the identity that
91 submitted the message to the mail delivery system.
93 This extension includes a profile of the Simple Authentication and
94 Security Layer (SASL) for SMTP.
96 When compared to RFC 2554, this document deprecates use of the 538
97 response code, adds a new Enhanced Status Code, adds a requirement to
98 support SASLprep profile for preparing authorization identities,
99 recommends use of RFC 3848 transmission types in the Received trace
100 header field, and clarifies interaction with SMTP PIPELINING
101 [PIPELINING] extension.
1032. How to Read This Document
105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
107 document are to be interpreted as described in [KEYWORDS].
109 In examples, "C:" and "S:" indicate lines sent by the client and
110 server, respectively.
114Siemborski & Melnikov Standards Track [Page 2]
116RFC 4954 SMTP Service Extension for Authentication July 2007
1193. The Authentication Service Extension
121 1. The name of this [SMTP] service extension is "Authentication".
125 3. The AUTH EHLO keyword contains as a parameter a space-separated
126 list of the names of available [SASL] mechanisms. The list of
127 available mechanisms MAY change after a successful STARTTLS
130 4. A new [SMTP] verb "AUTH" is defined.
132 5. An optional parameter using the keyword "AUTH" is added to the
133 MAIL FROM command, and extends the maximum line length of the
136 6. This extension is appropriate for the submission protocol
141 AUTH mechanism [initial-response]
144 mechanism: A string identifying a [SASL] authentication
147 initial-response: An optional initial client response. If
148 present, this response MUST be encoded as described in Section
149 4 of [BASE64] or contain a single character "=".
153 AUTH commands may be issued in the same session. After a
154 successful AUTH command completes, a server MUST reject any
155 further AUTH commands with a 503 reply.
158 An AUTH command issued during a mail transaction MUST be
159 rejected with a 503 reply.
162 The AUTH command initiates a [SASL] authentication exchange
163 between the client and the server. The client identifies the
164 SASL mechanism to use with the first parameter of the AUTH
165 command. If the server supports the requested authentication
166 mechanism, it performs the SASL exchange to authenticate the
170Siemborski & Melnikov Standards Track [Page 3]
172RFC 4954 SMTP Service Extension for Authentication July 2007
175 user. Optionally, it also negotiates a security layer for
177 requested authentication mechanism is invalid (e.g., is not
178 supported or requires an encryption layer), the server rejects
179 the AUTH command with a 504 reply. If the server supports the
180 [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced
183 The SASL authentication exchange consists of a series of
184 server challenges and client responses that are specific to
185 the chosen [SASL] mechanism.
188 containing the [BASE64] encoded string supplied by the SASL
189 mechanism. This challenge MUST NOT contain any text other
190 than the BASE64 encoded challenge.
192 A client response consists of a line containing a [BASE64]
194 authentication exchange, it issues a line with a single "*".
196 AUTH command by sending a 501 reply.
198 The optional initial response argument to the AUTH command is
199 used to save a round-trip when using authentication mechanisms
200 that support an initial client response. If the initial
201 response argument is omitted and the chosen mechanism requires
202 an initial client response, the server MUST proceed as defined
203 in Section 5.1 of [SASL]. In SMTP, a server challenge that
204 contains no data is defined as a 334 reply with no text part.
206 the complete response line is "334 ".
208 Note that the AUTH command is still subject to the line length
209 limitations defined in [SMTP]. If use of the initial response
210 argument would cause the AUTH command to exceed this length,
211 the client MUST NOT use the initial response parameter (and
212 instead proceed as defined in Section 5.1 of [SASL]).
215 length, it MUST instead transmit the response as a single
216 equals sign ("="). This indicates that the response is
217 present, but contains no data.
219 If the client uses an initial-response argument to the AUTH
220 command with a SASL mechanism in which the client does not
221 begin the authentication exchange, the server MUST reject the
226Siemborski & Melnikov Standards Track [Page 4]
228RFC 4954 SMTP Service Extension for Authentication July 2007
231 AUTH command with a 501 reply. Servers using the enhanced
232 status codes extension [ESMTP-CODES] SHOULD return an enhanced
233 status code of 5.7.0 in this case.
236 MUST reject the AUTH command with a 501 reply (and an enhanced
237 status code of 5.5.2). If the client cannot BASE64 decode any
238 of the server's challenges, it MUST cancel the authentication
239 using the "*" response. In particular, servers and clients
240 MUST reject (and not ignore) any character not explicitly
241 allowed by the BASE64 alphabet, and MUST reject any sequence
242 of BASE64 characters that contains the pad character ('=')
243 anywhere other than the end of the string (e.g., "=AAA" and
244 "AAA=BBB" are not allowed).
246 Note that these [BASE64] strings can be much longer than
247 normal SMTP commands. Clients and servers MUST be able to
248 handle the maximum encoded size of challenges and responses
249 generated by their supported authentication mechanisms. This
250 requirement is independent of any line length limitations the
251 client or server may have in other parts of its protocol
252 implementation. (At the time of writing of this document,
254 limit for handling of deployed authentication mechanisms.)
255 If, during an authentication exchange, the server receives a
256 line that is longer than the server's authentication buffer,
257 the server fails the AUTH command with the 500 reply. Servers
258 using the enhanced status codes extension [ESMTP-CODES] SHOULD
259 return an enhanced status code of 5.5.6 in this case.
261 The authorization identity generated by this [SASL] exchange
262 is a "simple username" (in the sense defined in [SASLprep]),
263 and both client and server SHOULD (*) use the [SASLprep]
264 profile of the [StringPrep] algorithm to prepare these names
265 for transmission or comparison. If preparation of the
266 authorization identity fails or results in an empty string
267 (unless it was transmitted as the empty string), the server
268 MUST fail the authentication.
270 (*) Note: Future revision of this specification may change this
271 requirement to MUST. Currently, the SHOULD is used in order to
272 avoid breaking the majority of existing implementations.
275 the AUTH command with a 535 reply unless a more specific error code
277 exchange, the SMTP server issues a 235 reply. (Note that the SMTP
278 protocol doesn't support the SASL feature of returning additional
282Siemborski & Melnikov Standards Track [Page 5]
284RFC 4954 SMTP Service Extension for Authentication July 2007
287 data with a successful outcome.) These status codes, along with
288 others defined by this extension, are discussed in Section 6 of this
291 If a security layer is negotiated during the SASL exchange, it takes
292 effect for the client on the octet immediately following the CRLF
293 that concludes the last response generated by the client. For the
294 server, it takes effect immediately following the CRLF of its success
297 When a security layer takes effect, the SMTP protocol is reset to the
298 initial state (the state in SMTP after a server issues a 220 service
299 ready greeting). The server MUST discard any knowledge obtained from
300 the client, such as the EHLO argument, which was not obtained from
301 the SASL negotiation itself. Likewise, the client MUST discard any
302 knowledge obtained from the server, such as the list of SMTP service
303 extensions, which was not obtained from the SASL negotiation itself.
304 (Note that a client MAY compare the advertised SASL mechanisms before
305 and after authentication in order to detect an active down-
308 The client SHOULD send an EHLO command as the first command after a
309 successful SASL negotiation that results in the enabling of a
312 When an entity (whether it is the client or the server end) is
313 sending data, and both [TLS] and SASL security layers are in effect,
314 the TLS encoding MUST be applied after the SASL encoding, regardless
315 of the order in which the layers were negotiated.
317 The service name specified by this protocol's profile of SASL is
318 "smtp". This service name is also to be used for the [SUBMIT]
321 If an AUTH command fails, the client MAY proceed without
322 authentication. Alternatively, the client MAY try another
323 authentication mechanism or present different credentials by issuing
327 it does NOT permit any plaintext password mechanisms, unless either
328 the STARTTLS [SMTP-TLS] command has been negotiated or some other
329 mechanism that protects the session from password snooping has been
330 provided. Server sites SHOULD NOT use any configuration which
331 permits a plaintext password mechanism without such a protection
332 mechanism against password snooping.
338Siemborski & Melnikov Standards Track [Page 6]
340RFC 4954 SMTP Service Extension for Authentication July 2007
344 extension MUST implement the [PLAIN] SASL mechanism running over TLS
345 [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on
346 implementations of [PLAIN] over [TLS].
348 Note that many existing client and server implementations implement
349 CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure
350 interoperability with deployed software, new implementations MAY
351 implement it; however, implementations should be aware that this SASL
352 mechanism doesn't provide any server authentication. Note that at
353 the time of writing of this document the SASL Working Group is
354 working on several replacement SASL mechanisms that provide server
355 authentication and other features.
357 When the AUTH command is used together with the [PIPELINING]
358 extension, it MUST be the last command in a pipelined group of
359 commands. The only exception to this rule is when the AUTH command
360 contains an initial response for a SASL mechanism that allows the
361 client to send data first, the SASL mechanism is known to complete in
362 one round-trip, and a security layer is not negotiated by the client.
363 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL
368 Here is an example of a client attempting AUTH using the [PLAIN] SASL
369 mechanism under a TLS layer, and making use of the initial client
372 S: 220-smtp.example.com ESMTP Server
373 C: EHLO client.example.com
374 S: 250-smtp.example.com Hello client.example.com
375 S: 250-AUTH GSSAPI DIGEST-MD5
376 S: 250-ENHANCEDSTATUSCODES
379 S: 220 Ready to start TLS
380 ... TLS negotiation proceeds, further commands
381 protected by TLS layer ...
382 C: EHLO client.example.com
383 S: 250-smtp.example.com Hello client.example.com
384 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
385 C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
386 S: 235 2.7.0 Authentication successful
388 Here is another client that is attempting AUTH PLAIN under a TLS
389 layer, this time without the initial response. Parts of the
390 negotiation before the TLS layer was established have been omitted:
394Siemborski & Melnikov Standards Track [Page 7]
396RFC 4954 SMTP Service Extension for Authentication July 2007
399 ... TLS negotiation proceeds, further commands
400 protected by TLS layer ...
401 C: EHLO client.example.com
402 S: 250-smtp.example.com Hello client.example.com
403 S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
405 (note: there is a single space following the 334
406 on the following line)
408 C: dGVzdAB0ZXN0ADEyMzQ=
409 S: 235 2.7.0 Authentication successful
411 Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which
412 the client does not begin the authentication exchange, and includes a
415 S: 220-smtp.example.com ESMTP Server
416 C: EHLO client.example.com
417 S: 250-smtp.example.com Hello client.example.com
418 S: 250-AUTH DIGEST-MD5 CRAM-MD5
419 S: 250-ENHANCEDSTATUSCODES
422 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk
424 C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==
425 S: 235 2.7.0 Authentication successful
427 Here is an example of a client attempting AUTH EXTERNAL under TLS,
428 using the derived authorization ID (and thus a zero-length initial
431 S: 220-smtp.example.com ESMTP Server
432 C: EHLO client.example.com
433 S: 250-smtp.example.com Hello client.example.com
434 S: 250-AUTH GSSAPI DIGEST-MD5
435 S: 250-ENHANCEDSTATUSCODES
438 S: 220 Ready to start TLS
439 ... TLS negotiation proceeds, further commands
440 protected by TLS layer ...
441 C: EHLO client.example.com
442 S: 250-smtp.example.com Hello client.example.com
443 S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN
445 S: 235 2.7.0 Authentication successful
450Siemborski & Melnikov Standards Track [Page 8]
452RFC 4954 SMTP Service Extension for Authentication July 2007
460 A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated
461 with the identity that submitted the message to the delivery
462 system, or the two character sequence "<>" indicating such an
463 identity is unknown or insufficiently authenticated. To comply
464 with restrictions imposed on ESMTP parameters, the <mailbox> is
465 encoded inside an xtext. The syntax of an xtext is described in
466 Section 4 of [ESMTP-DSN].
469 For the purposes of this discussion, "authenticated identity"
470 refers to the identity (if any) derived from the authorization
471 identity of previous AUTH command, while the terms "authorized
472 identity" and "supplied <mailbox>" refer to the sender identity
473 that is being associated with a particular message. Note that
474 one authenticated identity may be able to identify messages as
475 being sent by any number of authorized identities within a
476 single session. For example, this may be the case when an SMTP
477 server (one authenticated identity) is processing its queue
478 (many messages with distinct authorized identities).
481 The optional AUTH parameter to the MAIL FROM command allows
482 cooperating agents in a trusted environment to communicate the
483 authorization identity associated with individual messages.
485 If the server trusts the authenticated identity of the client to
486 assert that the message was originally submitted by the supplied
487 <mailbox>, then the server SHOULD supply the same <mailbox> in
488 an AUTH parameter when relaying the message to any other server
489 which supports the AUTH extension.
491 For this reason, servers that advertise support for this
492 extension MUST support the AUTH parameter to the MAIL FROM
493 command even when the client has not authenticated itself to the
496 A MAIL FROM parameter of AUTH=<> indicates that the original
497 submitter of the message is not known. The server MUST NOT
498 treat the message as having been originally submitted by the
499 authenticated identity that resulted from the AUTH command.
506Siemborski & Melnikov Standards Track [Page 9]
508RFC 4954 SMTP Service Extension for Authentication July 2007
511 If the AUTH parameter to the MAIL FROM command is not supplied,
512 the client has authenticated, and the server believes the
513 message is an original submission, the server MAY generate a
514 <mailbox> from the user's authenticated identity for use in an
515 AUTH parameter when relaying the message to any server which
516 supports the AUTH extension. The generated <mailbox> is
517 implementation specific, but it MUST conform to the syntax of
518 [SMTP]. If the implementation cannot generate a valid
519 <mailbox>, it MUST transmit AUTH=<> when relaying this message.
521 If the server does not sufficiently trust the authenticated
522 identity of the client, or if the client is not authenticated,
523 then the server MUST behave as if the AUTH=<> parameter was
524 supplied. The server MAY, however, write the value of any
525 supplied AUTH parameter to a log file.
527 If an AUTH=<> parameter was supplied, either explicitly or due
528 to the requirement in the previous paragraph, then the server
529 MUST supply the AUTH=<> parameter when relaying the message to
530 any server which it has authenticated to using the AUTH
533 A server MAY treat expansion of a mailing list as a new
534 submission, setting the AUTH parameter to the mailing list
535 address or mailing list administration address when relaying the
536 message to list subscribers.
539 clients as being insufficiently trusted is compliant with this
540 specification. In that case, the implementation does nothing
541 more than parse and discard syntactically valid AUTH parameters
542 to the MAIL FROM command, and supply AUTH=<> parameters to any
543 servers that it authenticates to.
547 An example where the original identity of the sender is trusted and
550 C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
553 One example where the identity of the sender is not trusted or is
554 otherwise being suppressed by the client:
556 C: MAIL FROM:<john+@example.org> AUTH=<>
562Siemborski & Melnikov Standards Track [Page 10]
564RFC 4954 SMTP Service Extension for Authentication July 2007
569 The following error codes may be used to indicate various success or
570 failure conditions. Servers that return enhanced status codes
571 [ESMTP-CODES] SHOULD use the enhanced codes suggested here.
575 This response to the AUTH command indicates that the authentication
580 This response to the AUTH command indicates that the user needs to
581 transition to the selected authentication mechanism. This is
582 typically done by authenticating once using the [PLAIN]
583 authentication mechanism. The selected mechanism SHOULD then work
584 for authentications in subsequent sessions.
588 This response to the AUTH command indicates that the authentication
589 failed due to a temporary server failure. The client SHOULD NOT
590 prompt the user for another password in this case, and should instead
591 notify the user of server failure.
595 This response to the AUTH command indicates that the selected
596 authentication mechanism is weaker than server policy permits for
597 that user. The client SHOULD retry with a new authentication
602 This response to the AUTH command indicates that the authentication
603 failed due to invalid or insufficient authentication credentials. In
604 this case, the client SHOULD ask the user to supply new credentials
605 (such as by presenting a password dialog box).
607 500 5.5.6 Authentication Exchange line is too long
609 This response to the AUTH command indicates that the authentication
610 failed due to the client sending a [BASE64] response that is longer
611 than the maximum buffer size available for the currently selected
618Siemborski & Melnikov Standards Track [Page 11]
620RFC 4954 SMTP Service Extension for Authentication July 2007
625 This response SHOULD be returned by any command other than AUTH,
626 EHLO, HELO, NOOP, RSET, or QUIT when server policy requires
627 authentication in order to perform the requested action and
628 authentication is not currently in force.
633 This response to the AUTH command indicates that the selected
634 authentication mechanism may only be used when the underlying SMTP
635 connection is encrypted. Note that this response code is documented
636 here for historical purposes only. Modern implementations SHOULD NOT
637 advertise mechanisms that are not permitted due to lack of
638 encryption, unless an encryption layer of sufficient strength is
639 currently being employed.
641 This document adds several new enhanced status codes to the list
642 defined in [ENHANCED]:
644 The following 3 Enhanced Status Codes were defined above:
646 5.7.8 Authentication credentials invalid
647 5.7.9 Authentication mechanism is too weak
648 5.7.11 Encryption required for requested authentication mechanism
652 This enhanced status code SHOULD be returned when the server fails
653 the AUTH command due to the client sending a [BASE64] response which
654 is longer than the maximum buffer size available for the currently
655 selected SASL mechanism. This is useful for both permanent and
656 persistent transient errors.
6587. Additional Requirements on Servers
661 message for delivery or further processing MUST insert the
662 "Received:" header field at the beginning of the message content.
663 This document places additional requirements on the content of a
664 generated "Received:" header field. Upon successful authentication,
665 a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when
666 appropriate) keyword in the "with" clause of the Received header
674Siemborski & Melnikov Standards Track [Page 12]
676RFC 4954 SMTP Service Extension for Authentication July 2007
681 The following syntax specification uses the Augmented Backus-Naur
682 Form notation as specified in [ABNF]. Non-terminals referenced but
683 not defined below are as defined by [ABNF] or [SASL]. The non-
684 terminal <mailbox> is defined in [SMTP].
686 Except as noted otherwise, all alphabetic characters are case-
687 insensitive. The use of upper or lower case characters to define
688 token strings is for editorial clarity only. Implementations MUST
689 accept these strings in a case-insensitive fashion.
691 hexchar = "+" HEXDIG HEXDIG
693 xchar = %x21-2A / %x2C-3C / %x3E-7E
694 ;; US-ASCII except for "+", "=", SP, and CTL
697 ;; non-US-ASCII is only allowed as hexchar
700 *(CRLF [base64]) [CRLF cancel-response]
702 ;; <sasl-mech> is defined in [SASL]
705 ;; Parameter to the MAIL FROM command.
706 ;; This non-terminal complies with
707 ;; syntax defined by esmtp-param [SMTP].
709 ;; The decoded form of the xtext MUST be
710 ;; either a <mailbox> or the two
713 base64 = base64-terminal /
714 ( 1*(4base64-char) [base64-terminal] )
716 base64-char = ALPHA / DIGIT / "+" / "/"
719 base64-terminal = (2base64-char "==") / (3base64-char "=")
721 continue-req = "334" SP [base64] CRLF
722 ;; Intermediate response to the AUTH
724 ;; This non-terminal complies with
725 ;; syntax defined by Reply-line [SMTP].
730Siemborski & Melnikov Standards Track [Page 13]
732RFC 4954 SMTP Service Extension for Authentication July 2007
735 initial-response= base64 / "="
737 cancel-response = "*"
7399. Security Considerations
741 Security issues are discussed throughout this memo.
743 If a client uses this extension to get an encrypted tunnel through an
744 insecure network to a cooperating server, it needs to be configured
745 to never send mail to that server when the connection is not mutually
746 authenticated and encrypted. Otherwise, an attacker could steal the
747 client's mail by hijacking the [SMTP] connection and either
748 pretending the server does not support the Authentication extension
749 or causing all AUTH commands to fail.
751 Before the [SASL] negotiation has begun, any protocol interactions
752 are performed in the clear and may be modified by an active attacker.
753 For this reason, clients and servers MUST discard any knowledge
754 obtained prior to the start of the SASL negotiation upon the
755 establishment of a security layer.
757 This mechanism does not protect the TCP port, so an active attacker
758 may redirect a relay connection attempt (i.e., a connection between
759 two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT].
760 The AUTH=<> parameter prevents such an attack from causing a relayed
761 message and, in the absence of other envelope authentication, from
762 picking up the authentication of the relay client.
764 A message submission client may require the user to authenticate
765 whenever a suitable [SASL] mechanism is advertised. Therefore, it
766 may not be desirable for a submission server [SUBMIT] to advertise a
767 SASL mechanism when use of that mechanism grants the clients no
768 benefits over anonymous submission.
771 after a number of failed authentication attempts. If they do so,
772 they SHOULD NOT drop the connection until at least 3 attempts to
773 authenticate have failed.
775 If an implementation supports SASL mechanisms that are vulnerable to
776 passive eavesdropping attacks (such as [PLAIN]), then the
777 implementation MUST support at least one configuration where these
778 SASL mechanisms are not advertised or used without the presence of an
779 external security layer such as [TLS].
786Siemborski & Melnikov Standards Track [Page 14]
788RFC 4954 SMTP Service Extension for Authentication July 2007
791 This extension is not intended to replace or be used instead of end-
792 to-end message signature and encryption systems such as [S/MIME] or
793 [PGP]. This extension addresses a different problem than end-to-end
794 systems; it has the following key differences:
796 1. It is generally useful only within a trusted enclave.
798 2. It protects the entire envelope of a message, not just the
801 3. It authenticates the message submission, not authorship of the
804 4. When mutual authentication is used along with a security layer,
805 it can give the sender some assurance that the message was
806 successfully delivered to the next hop.
808 Additional security considerations are mentioned in the [SASL]
809 specification. Additional security considerations specific to a
810 particular SASL mechanism are described in the relevant
811 specification. Additional security considerations for [PLAIN] over
812 [TLS] are mentioned in Section 15 of this document.
81410. IANA Considerations
816 IANA updated the entry for the "smtp" SASL protocol name to point at
819 IANA updated the registration of the Authentication SMTP service
820 extension as defined in Section 3 of this document. This registry is
821 currently located at <http://www.iana.org/assignments/mail-
82411. Normative References
826 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
827 Specifications: ABNF", RFC 4234, October 2005.
829 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
830 Encodings", RFC 4648, October 2006.
832 [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning
833 Enhanced Error Codes", RFC 2034, October 1996.
835 [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
842Siemborski & Melnikov Standards Track [Page 15]
844RFC 4954 SMTP Service Extension for Authentication July 2007
847 [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
848 Service Extension Delivery Status Notifications
849 (DSNs)", RFC 3461, January 2003.
851 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
852 Requirement Levels", BCP 14, RFC 2119, March 1997.
854 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
855 and Security Layer (SASL)", RFC 4422, June 2006.
857 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
858 Names and Passwords", RFC 4013, February 2005.
860 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
863 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
864 over Transport Layer Security", RFC 3207, February
867 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
868 Internationalized Strings ("stringprep")", RFC 3454,
871 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
872 Mail", RFC 4409, April 2006.
874 [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types
875 Registration", RFC 3848, July 2004.
877 [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
878 Security Layer (SASL) Mechanism", RFC 4616, August
881 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
882 X.509 Public Key Infrastructure Certificate and
883 Certificate Revocation List (CRL) Profile", RFC 3280,
88612. Informative References
888 [PGP] Elkins, M., "MIME Security with Pretty Good Privacy
889 (PGP)", RFC 2015, October 1996.
891 [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
892 Extensions (S/MIME) Version 3.1 Message Specification",
898Siemborski & Melnikov Standards Track [Page 16]
900RFC 4954 SMTP Service Extension for Authentication July 2007
903 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
904 Security (TLS) Protocol Version 1.1", RFC 4346, April
907 [PIPELINING] Freed, N., "SMTP Service Extension for Command
908 Pipelining", STD 60, RFC 2920, September 2000.
910 [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
911 AUTHorize Extension for Simple Challenge/Response", RFC
912 2195, September 1997.
916 The editors would like to acknowledge the contributions of John Myers
917 and other contributors to RFC 2554, on which this document draws from
920 The editors would also like to thank Ken Murchison, Mark Crispin,
921 Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned
922 Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther,
923 Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for
924 the time they devoted to reviewing of this document and/or for the
92714. Additional Requirements When Using SASL PLAIN over TLS
929 This section is normative for SMTP implementations that support SASL
932 If an SMTP client is willing to use SASL PLAIN over TLS to
933 authenticate to the SMTP server, the client verifies the server
934 certificate according to the rules of [X509]. If the server has not
935 provided any certificate, or if the certificate verification fails,
936 the client MUST NOT attempt to authenticate using the SASL PLAIN
939 After a successful [TLS] negotiation, the client MUST check its
940 understanding of the server hostname against the server's identity as
941 presented in the server Certificate message, in order to prevent
942 man-in-the-middle attacks. If the match fails, the client MUST NOT
943 attempt to authenticate using the SASL PLAIN mechanism. Matching is
944 performed according to the following rules:
946 The client MUST use the server hostname it used to open the
947 connection as the value to compare against the server name as
948 expressed in the server certificate. The client MUST NOT use
954Siemborski & Melnikov Standards Track [Page 17]
956RFC 4954 SMTP Service Extension for Authentication July 2007
959 any form of the server hostname derived from an insecure remote
960 source (e.g., insecure DNS lookup). CNAME canonicalization is
963 If a subjectAltName extension of type dNSName is present in the
964 certificate, it SHOULD be used as the source of the server's
967 Matching is case-insensitive.
969 A "*" wildcard character MAY be used as the leftmost name
970 component in the certificate. For example, *.example.com would
971 match a.example.com, foo.example.com, etc., but would not match
974 If the certificate contains multiple names (e.g., more than one
975 dNSName field), then a match with any one of the fields is
976 considered acceptable.
97815. Changes since RFC 2554
980 1. Clarified that servers MUST support the use of the AUTH=mailbox
981 parameter to MAIL FROM, even when the client is not
984 2. Clarified the initial-client-send requirements, and give
987 3. Updated references to newer versions of various specifications.
989 4. Required SASL PLAIN (over TLS) as mandatory-to-implement.
991 5. Clarified that the mechanism list can change.
993 6. Deprecated the use of the 538 response code.
995 7. Added the use of the SASLprep profile for preparing authorization
998 8. Substantial cleanup of response codes and indicated suggested
999 enhanced response codes. Also indicated what response codes
1000 should result in a client prompting the user for new credentials.
1002 9. Updated ABNF section to use RFC 4234.
1004 10. Clarified interaction with SMTP PIPELINING extension.
1006 11. Added a reference to RFC 3848.
1010Siemborski & Melnikov Standards Track [Page 18]
1012RFC 4954 SMTP Service Extension for Authentication July 2007
1015 12. Added a new Enhanced Status Code for "authentication line too
1018 13. Other general editorial clarifications.
1024 1600 Ampitheatre Parkway
1025 Mountain View, CA 94043, USA
1027 Phone: +1 650 623 6925
1028 EMail: robsiemb@google.com
1033 5 Castle Business Village, 36 Station Road,
1034 Hampton, Middlesex, TW12 2BX, UK
1036 EMail: Alexey.Melnikov@isode.com
1066Siemborski & Melnikov Standards Track [Page 19]
1068RFC 4954 SMTP Service Extension for Authentication July 2007
1071Full Copyright Statement
1073 Copyright (C) The IETF Trust (2007).
1075 This document is subject to the rights, licenses and restrictions
1076 contained in BCP 78, and except as set forth therein, the authors
1077 retain all their rights.
1079 This document and the information contained herein are provided on an
1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1087Intellectual Property
1089 The IETF takes no position regarding the validity or scope of any
1090 Intellectual Property Rights or other rights that might be claimed to
1091 pertain to the implementation or use of the technology described in
1092 this document or the extent to which any license under such rights
1093 might or might not be available; nor does it represent that it has
1094 made any independent effort to identify any such rights. Information
1095 on the procedures with respect to rights in RFC documents can be
1096 found in BCP 78 and BCP 79.
1098 Copies of IPR disclosures made to the IETF Secretariat and any
1099 assurances of licenses to be made available, or the result of an
1100 attempt made to obtain a general license or permission for the use of
1101 such proprietary rights by implementers or users of this
1102 specification can be obtained from the IETF on-line IPR repository at
1103 http://www.ietf.org/ipr.
1105 The IETF invites any interested party to bring to its attention any
1106 copyrights, patents or patent applications, or other proprietary
1107 rights that may cover technology that may be required to implement
1108 this standard. Please address the information to the IETF at
1113 Funding for the RFC Editor function is currently provided by the
1122Siemborski & Melnikov Standards Track [Page 20]