RFC 4954

SMTP Service Extension for Authentication

📅 published July 2007, from ietf

SMTP Service Extension for Authentication 💌

(Part 1 of 5 🎀)

Okay bestie, let's start with the title block 💖 This is RFC 4954, from the Network Working Group. It's a Standards Track doc, so it's the real deal 👑 It's dated July 2007 ✨

The authors are R. Siemborski, Ed. from Google, Inc., and A. Melnikov, Ed. from Isode Limited 🫶 It obsoletes RFC 2554 and updates RFC 3463 🦋

Status of This Memo 📜

So this is an Internet standards track protocol for the whole Internet community, and they're literally asking for discussion and suggestions for improvements 💅 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🌸 Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007). 🎀

Abstract ✨

Here's the main vibe 💜 This doc defines an SMTP extension (that's the Simple Mail Transport Protocol, aka the email one 📧) where an SMTP client can tell the server which authentication mechanism it wants to use 🔐 Then they do the authentication exchange, and optionally agree on a security layer for the rest of the session 🦋 It also includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP, which is giving main character energy 👑

This document obsoletes RFC 2554. 💀

Table of Contents 🗂️

1. Introduction ....................................................2
2. How to Read This Document .......................................2
3. The Authentication Service Extension ............................3
4. The AUTH Command ................................................3
   4.1. Examples ...................................................7
5. The AUTH Parameter to the MAIL FROM command .....................9
   5.1. Examples ..................................................10
6. Status Codes ...................................................11
7. Additional requirements on servers .............................12
8. Formal Syntax ..................................................13
9. Security Considerations ........................................14
10. IANA Considerations ...........................................15
11. Normative References ..........................................15
12. Informative References ........................................16
13. Acknowledgments ...............................................17
14. Additional Requirements When Using SASL PLAIN over TLS ........17
15. Changes since RFC 2554 ........................................18

1. Introduction 🌸

Okay so this doc defines an SMTP extension where a client tells the server which authentication mechanism it wants 🔐 It then does the auth protocol exchange, optionally negotiates a security layer for the rest of the session, and, during a mail transaction, can optionally specify a mailbox tied to the identity that submitted the message to the mail delivery system 📬 It's giving organized energy 💅

This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP 🫶

Compared to RFC 2554, this document:

  • deprecates use of the 538 response code 🙈
  • adds a new Enhanced Status Code ✨
  • adds a requirement to support SASLprep profile for preparing authorization identities 🔥
  • recommends use of RFC 3848 transmission types in the Received trace header field 🧚
  • clarifies interaction with SMTP PIPELINING [PIPELINING] extension 🦋

2. How to Read This Document 📖

Here's the key word situation 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. Read those carefully, they're the rules 👑

In examples, C: means lines sent by the client, and S: means lines sent by the server 💜

3. The Authentication Service Extension 🎀

Here's how the extension actually works, step by step 🧚

  1. The name of this [SMTP] service extension is "Authentication". 🌈
  2. The EHLO keyword value associated with this extension is "AUTH". 💖
  3. The AUTH EHLO keyword contains as a parameter a space-separated list of the names of available [SASL] mechanisms. The list of available mechanisms MAY change after a successful STARTTLS command [SMTP-TLS]. 🔐 Yes, the list can shift after STARTTLS, so keep an eye on it 👀
  4. A new [SMTP] verb "AUTH" is defined. 🫶
  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 by 500 characters. 📏 Iconic, the line gets 500 extra characters 💅
  6. This extension is appropriate for the submission protocol [SUBMIT]. 📮

4. The AUTH Command 🔐✨

Okay bestie, this is the main event 💅 The AUTH command is how a client starts a login, and here's the syntax:

AUTH mechanism [initial-response]

Arguments 🎀

  • mechanism: a string that names a [SASL] authentication mechanism.
  • initial-response: an optional initial client response. If it's there, this response MUST be encoded as described in Section 4 of [BASE64] or contain a single character "=".

Restrictions 🚫

Once an AUTH command has been successfully completed, no more AUTH commands may be issued in the same session. After a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply. Not allowed, periodt.

The AUTH command is not permitted during a mail transaction. An AUTH command issued during a mail transaction MUST be rejected with a 503 reply. No login mid-transaction, that's giving chaos 🙅‍♀️

Discussion 🧠

The AUTH command kicks off a [SASL] authentication exchange between the client and the server. The client names the SASL mechanism it wants with the first parameter of the AUTH command. If the server supports that mechanism, it runs the SASL exchange to authenticate the user. It can also, optionally, negotiate a security layer for the rest of the session ✨

If the requested mechanism is invalid (for example, it isn't supported or it requires an encryption layer), the server rejects the AUTH command with a 504 reply. If the server supports the [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced response code.

The SASL exchange is basically a back-and-forth. The server sends challenges and the client sends responses, and the details depend on whichever SASL mechanism was picked 🦋

A server challenge goes out as a 334 reply, and its text part holds the [BASE64] encoded string that the SASL mechanism gave it. The challenge MUST NOT contain any text other than that BASE64 encoded challenge. Nothing extra, no vibes-only commentary 😭

A client response is one line containing a [BASE64] encoded string. If the client wants to bail on the authentication exchange, it sends a line with a single "*". If the server gets that, it MUST reject the AUTH command by sending a 501 reply. Cancelled means cancelled 💀

Now the optional initial response argument. It exists to save a round-trip for mechanisms that can send an initial client response. If you leave the initial response argument out and the chosen mechanism needs an initial client response, the server MUST proceed as defined in Section 5.1 of [SASL]. In SMTP, a server challenge with no data is a 334 reply with no text part. Heads up, there's still a space after the reply code, so the full response line is 334 (yes, with the trailing space 🙈)

Also, the AUTH command still has to follow the line length limits from [SMTP]. If using the initial response argument would make the AUTH command go over that length, the client MUST NOT use the initial response parameter, and it instead proceeds as defined in Section 5.1 of [SASL] 🎀

If the client is sending an initial response of zero length, it MUST send it as one single equals sign ("="). That tells the server the response is there, it's just empty 🫶

If the client uses an initial-response argument with a SASL mechanism where the client doesn't start the exchange, the server MUST reject the AUTH command with a 501 reply. Servers that use the enhanced status codes extension [ESMTP-CODES] SHOULD return the enhanced status code 5.7.0 in this case.

If the server can't [BASE64] decode a client response, it MUST reject the AUTH command with a 501 reply (and an enhanced status code of 5.5.2). If the client can't BASE64 decode one of the server's challenges, it MUST cancel the authentication using the "*" response. Also, servers and clients MUST reject (and not ignore) any character that isn't explicitly allowed by the BASE64 alphabet. They MUST also reject any sequence of BASE64 characters where the pad character ('=') shows up anywhere other than the end of the string. So =AAA and AAA=BBB are both a no-go 🙅‍♀️

Note that these [BASE64] strings can be way longer than normal SMTP commands. Clients and servers MUST be able to handle the maximum encoded size of the challenges and responses that their supported authentication mechanisms generate. This requirement stands on its own, separate from any line length limits the client or server has elsewhere in its protocol implementation. (When this document was written, 12288 octets was considered a sufficient line length limit for handling the authentication mechanisms that were out in the wild.) If the server gets a line during an authentication exchange that's longer than its authentication buffer, it fails the AUTH command with the 500 reply. Servers using the enhanced status codes extension [ESMTP-CODES] SHOULD return the enhanced status code 5.5.6 in this case 🌸

The authorization identity from this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]). Both the client and the server SHOULD (*) use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names before transmitting or comparing them. If preparing the authorization identity fails, or if it ends up as an empty string (unless it was sent as the empty string to begin with), the server MUST fail the authentication 🔥

(*) Note: A future revision of this specification may change this requirement to MUST. Currently, the SHOULD is used in order to avoid breaking the majority of existing implementations.

If the server can't authenticate the client, it SHOULD reject the AUTH command with a 535 reply, unless a more specific error code is appropriate. If the client finishes the exchange successfully, the SMTP server issues a 235 reply. (Note that the SMTP protocol doesn't support the SASL feature of returning additional data with a successful outcome.) These status codes, along with others defined by this extension, are covered in Section 6 of this document ✨

If a security layer gets negotiated during the SASL exchange, it takes effect for the client on the octet right after the CRLF that ends the last response the client generated. For the server, it takes effect right after the CRLF of its success reply 🦋

When a security layer takes effect, the SMTP protocol resets to its initial state (the state SMTP is in after a server issues a 220 service ready greeting). The server MUST discard any knowledge it got from the client, such as the EHLO argument, that didn't come from the SASL negotiation itself. In the same way, the client MUST discard any knowledge it got from the server, such as the list of SMTP service extensions, that didn't come from the SASL negotiation itself. (A client MAY compare the advertised SASL mechanisms before and after authentication to detect an active down-negotiation attack 👀)

After a successful SASL negotiation that turns on a security layer, the client SHOULD send an EHLO command as its first command.

When an entity (client or server) is sending data and both [TLS] and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding. That's true no matter what order the layers were negotiated in 🎀

The service name in this protocol's profile of SASL is "smtp". This service name is also used for the [SUBMIT] protocol 💜

If an AUTH command fails, the client MAY go on without authentication. Or, the client MAY try a different authentication mechanism, or present different credentials, by issuing another AUTH

Note: A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS [SMTP-TLS] command has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration that permits a plaintext password mechanism without that kind of protection against password snooping. Password snooping is not it 🔐

To keep things interoperable, 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] 🌈

Many existing client and server implementations use the CRAM-MD5 [CRAM-MD5] SASL mechanism. To keep things working with deployed software, new implementations MAY implement it. Just know that this SASL mechanism doesn't provide any server authentication, so implementations should be aware of that. At the time of writing, the SASL Working Group is working on several replacement SASL mechanisms that do provide server authentication and other features ⭐

When the AUTH command is used together with the [PIPELINING] extension, it MUST be the last command in a pipelined group of commands. The only exception is when the AUTH command contains an initial response for a SASL mechanism that lets the client send data first, the SASL mechanism is known to finish in one round-trip, and the client hasn't negotiated a security layer. Two examples of those SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL] 🧚

4.1. Examples

okay so let's look at some real examples bestie 🎀 first up, a client trying AUTH with the [PLAIN] SASL mechanism under a TLS layer, and it sends the initial client response right away 🔥

S: 220-smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
  ... TLS negotiation proceeds, further commands
      protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Authentication successful

next one is another client doing AUTH PLAIN under TLS, but this time it doesn't send the initial response 💅 the early parts of the negotiation before TLS got set up were cut out to keep things short ✂️

  ... TLS negotiation proceeds, further commands
      protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN
 (note: there is a single space following the 334
  on the following line)
S: 334
C: dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Authentication successful

then we've got CRAM-MD5 [CRAM-MD5] 🧚 this one is different because the client doesn't start the exchange, and the server throws down a challenge first, which is so main character energy 👑

S: 220-smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH DIGEST-MD5 CRAM-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: AUTH CRAM-MD5
S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk
   dT4=
C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA==
S: 235 2.7.0 Authentication successful

and last but not least 🦋 a client trying AUTH EXTERNAL under TLS. It uses the derived authorization ID, so the initial client response is zero-length, which is literally just = 🙈

S: 220-smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
  ... TLS negotiation proceeds, further commands
      protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN
C: AUTH EXTERNAL =
S: 235 2.7.0 Authentication successful

5. The AUTH Parameter to the MAIL FROM command ✨

okay now the good stuff 🫶 this is where the AUTH parameter on MAIL FROM comes in, and it's basically how cooperating agents in a trusted environment pass along who the authorization identity is for each message 💌

AUTH=mailbox

Arguments:

The value is a <mailbox> (see Section 4.1.2 of [SMTP]) that's tied to the identity that submitted the message to the delivery system. Or it can be the two character sequence "<>", which just means the identity is unknown or not authenticated well enough. To follow the rules for ESMTP parameters, the <mailbox> gets encoded inside an xtext. You can read up on the xtext syntax in Section 4 of [ESMTP-DSN] 📚

Note:

quick vocab check 🧠 for this section, "authenticated identity" means the identity (if there is one) that came from the authorization identity of a previous AUTH command. Meanwhile "authorized identity" and "supplied <mailbox>" are about the sender identity that gets attached to a particular message. One authenticated identity can claim that messages come from lots of different authorized identities in a single session. Like, an SMTP server (one authenticated identity) processing its queue (tons of messages with different authorized identities) is literally the perfect example 🍓

Discussion:

the optional AUTH parameter to MAIL FROM lets cooperating agents in a trusted environment share the authorization identity for each message 🤝

if the server trusts the authenticated identity of the client to say the message was originally submitted by the supplied <mailbox>, then the server SHOULD supply that same <mailbox> in an AUTH parameter when it relays the message to any other server that supports the AUTH extension 🚀

because of that, servers that advertise this extension MUST support the AUTH parameter to MAIL FROM even when the client hasn't authenticated itself to the server 💖

an AUTH parameter of AUTH=<> means the original submitter of the message is not known 🙈 in that case the server MUST NOT treat the message as having been originally submitted by the authenticated identity that came from the AUTH command. no sneaky mixups allowed 😭

if the AUTH parameter to MAIL FROM isn't supplied, the client has authenticated, and the server thinks the message is an original submission, then the server MAY generate a <mailbox> from the user's authenticated identity to use in an AUTH parameter when it relays the message to any server that supports the AUTH extension. The generated <mailbox> is implementation specific, but it MUST conform to the syntax of [SMTP]. If the implementation can't generate a valid <mailbox>, it MUST transmit AUTH=<> when relaying this message 🧩

if the server doesn't sufficiently trust the authenticated identity of the client, or if the client isn't authenticated at all, then the server MUST behave as if the AUTH=<> parameter was supplied. The server MAY, however, write the value of any supplied AUTH parameter to a log file 📝

if an AUTH=<> parameter was supplied, either explicitly or because of the requirement in the previous paragraph, then the server MUST supply the AUTH=<> parameter when it relays the message to any server it has authenticated to using the AUTH extension 💅

a server MAY treat expansion of a mailing list as a new submission, setting the AUTH parameter to the mailing list address or mailing list administration address when relaying the message to list subscribers 📬

and finally, an implementation that's hard-coded to treat every client as insufficiently trusted is still compliant with this specification 🎀 in that case it just parses and discards syntactically valid AUTH parameters on MAIL FROM, and supplies AUTH=<> parameters to any servers it authenticates to. honestly iconic for simplicity 👑

5.1. Examples

here are a couple of examples to make it click ✨ first, the original identity of the sender is trusted and known:

C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
S: 250 OK

and here's one where the identity of the sender isn't trusted, or the client is deliberately suppressing it 🫣

C: MAIL FROM:<john+@example.org> AUTH=<>
S: 250 OK

6. Status Codes 💀

these are the error codes you might see when the goal is to tell someone whether the success or failure conditions happened. Servers that return enhanced status codes [ESMTP-CODES] SHOULD use the enhanced codes suggested here. Lowkey the best part of this section is that the whole thing is organised by code, so it's super easy to skim 🔍

235 2.7.0 Authentication Succeeded

this response to the AUTH command means the authentication was successful 🎉

432 4.7.12 A password transition is needed

this response to the AUTH command means the user needs to switch to the selected authentication mechanism. That's usually done by authenticating once with the [PLAIN] authentication mechanism. After that, the selected mechanism SHOULD work for authentications in later sessions 🔄

454 4.7.0 Temporary authentication failure

this response to the AUTH command means authentication failed because of a temporary server failure. In this case the client SHOULD NOT prompt the user for another password, and should instead tell the user that the server failed 🫠

534 5.7.9 Authentication mechanism is too weak

this response to the AUTH command means the selected authentication mechanism is weaker than what server policy allows for that user. The client SHOULD retry with a new authentication mechanism 🔐

535 5.7.8 Authentication credentials invalid

this response to the AUTH command means authentication failed because the credentials were invalid or insufficient. In this case the client SHOULD ask the user to supply new credentials (like by showing a password dialog box) 🙋‍♀️

500 5.5.6 Authentication Exchange line is too long

this response to the AUTH command means authentication failed because the client sent a [BASE64] response that's longer than the maximum buffer size available for the currently selected SASL mechanism. It's giving "too much, too fast" 😭

530 5.7.0 Authentication required

this response SHOULD be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication before the requested action can happen, and authentication isn't currently in force 🚫

538 5.7.11 Encryption required for requested authentication mechanism

this response to the AUTH command means the selected authentication mechanism can only be used when the underlying SMTP connection is encrypted. Heads up, this response code is only documented here for historical purposes 🕰️ modern implementations SHOULD NOT advertise mechanisms that aren't permitted because there's no encryption, unless an encryption layer of sufficient strength is currently in use 🔒

this document adds some brand new enhanced status codes to the list defined in [ENHANCED] 🌈

the following 3 Enhanced Status Codes were defined above:

5.7.8 Authentication credentials invalid
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

this enhanced status code SHOULD be returned when the server fails the AUTH command because the client sent a [BASE64] response that's longer than the maximum buffer size for the currently selected SASL mechanism. It's useful for both permanent and persistent transient errors, so it's a keeper ✨

7. Additional Requirements on Servers 🧚

last bit of this part, and it's about Received headers 📮 as described in Section 4.4 of [SMTP], an SMTP server that gets a message for delivery or further processing MUST insert the "Received:" header field at the beginning of the message content. This document adds extra requirements on what a generated "Received:" header field looks like. Once authentication succeeds, a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] keyword (when appropriate) in the "with" clause of the Received header field 💜

8. Formal Syntax ✨

okay bestie, this is the grammar section and it is giving very serious main character energy 💅 The syntax is written in [ABNF], which is the notation full of little symbols. Anything we use but don't define here comes from [ABNF] or [SASL], and the non-terminal <mailbox> is defined in [SMTP] 🎀

Unless it says otherwise, letters here don't care about capitals 🌸 Using upper or lower case to name the token strings is just for editorial clarity, it's not a rule. Implementations MUST accept these strings in a case-insensitive fashion 🫶

      hexchar         = "+" HEXDIG HEXDIG

      xchar           = %x21-2A / %x2C-3C / %x3E-7E
                        ;; US-ASCII except for "+", "=", SP, and CTL

      xtext           = *(xchar / hexchar)
                        ;; non-US-ASCII is only allowed as hexchar

      auth-command    = "AUTH" SP sasl-mech [SP initial-response]
                        *(CRLF [base64]) [CRLF cancel-response]
                        CRLF
                        ;; <sasl-mech> is defined in [SASL]

      auth-param      = "AUTH=" xtext
                        ;; Parameter to the MAIL FROM command.
                        ;; This non-terminal complies with
                        ;; syntax defined by esmtp-param [SMTP].
                        ;;
                        ;; The decoded form of the xtext MUST be
                        ;; either a <mailbox> or the two
                        ;; characters "<>"

      base64          = base64-terminal /
                        ( 1*(4base64-char) [base64-terminal] )

      base64-char     = ALPHA / DIGIT / "+" / "/"
                        ;; Case-sensitive

      base64-terminal = (2base64-char "==") / (3base64-char "=")

      continue-req    = "334" SP [base64] CRLF
                        ;; Intermediate response to the AUTH
                        ;; command.
                        ;; This non-terminal complies with
                        ;; syntax defined by Reply-line [SMTP].

      initial-response= base64 / "="

      cancel-response = "*"

9. Security Considerations 🔐

okay now the serious part, so pay attention, bestie 👀 Security issues are discussed throughout this memo, so keep your eyes open the whole way through 🦋

If a client uses this extension to get an encrypted tunnel through a sketchy network to a cooperating server, it has to be set up to never send mail to that server unless the connection is mutually authenticated and encrypted 😭 Otherwise, an attacker could steal the client's mail by hijacking the [SMTP] connection and either pretending the server doesn't support the Authentication extension or making every AUTH command fail. Literally a nightmare.

Before the [SASL] negotiation has begun, any protocol interactions happen in the clear and an active attacker can modify them 💀 For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer 🫶

This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt (i.e., a connection between two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT]. The AUTH=<> parameter stops that attack from making a relayed message, and, when there's no other envelope authentication, from picking up the authentication of the relay client 🛡️

A message submission client may require the user to authenticate whenever a suitable [SASL] mechanism is advertised. So it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when using that mechanism gives clients no benefits over anonymous submission 🙈

Servers MAY implement a policy where the connection is dropped after a number of failed authentication attempts. If they do so, they SHOULD NOT drop the connection until at least 3 attempts to authenticate have failed 🌈

If an implementation supports SASL mechanisms that are vulnerable to passive eavesdropping attacks (such as [PLAIN]), then the implementation MUST support at least one configuration where those SASL mechanisms are not advertised or used without the presence of an external security layer such as [TLS] 🚨

This extension is not meant to replace end-to-end message signature and encryption systems such as [S/MIME] or [PGP], and it's not meant to be used instead of them either 🎀 It solves a different problem than end-to-end systems, and the key differences are:

  1. It is generally useful only within a trusted enclave.
  2. It protects the entire envelope of a message, not just the message's body.
  3. It authenticates the message submission, not authorship of the message content.
  4. When mutual authentication is used along with a security layer, it can give the sender some assurance that the message was successfully delivered to the next hop.

Additional security considerations are mentioned in the [SASL] specification 📚 Additional security considerations specific to a particular SASL mechanism are described in the relevant specification for that mechanism. Additional security considerations for [PLAIN] over [TLS] are mentioned in Section 15 of this document 💖

10. IANA Considerations 🦋

IANA updated the entry for the "smtp" SASL protocol name so it points at this document ✨

IANA updated the registration of the Authentication SMTP service extension as defined in Section 3 of this document. This registry is currently located at <http://www.iana.org/assignments/mail-parameters> 🌸

11. Normative References 📚

  • [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
  • [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
  • [ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
  • [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
  • [ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
  • [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
  • [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
  • [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
  • [SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
  • [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 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 🧚

  • [PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
  • [S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
  • [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
  • [PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
  • [CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.

13. Acknowledgments 🫶

The editors would like to acknowledge the contributions of John Myers and other contributors to RFC 2554, on which this document draws from heavily 💜

The editors would also like to thank Ken Murchison, Mark Crispin, Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for the time they gave to reviewing this document and/or for the comments they sent in 🌟

14. 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 hasn't 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, 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 done according to these 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 leftmost 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.

15. Changes since RFC 2554 🎀

okay bestie, this is the glow-up list 💅 here's everything that changed since RFC 2554:

  1. Clarified that servers MUST support the use of the AUTH=mailbox parameter to MAIL FROM, even when the client is not authenticated. 🔐
  2. Clarified the initial-client-send requirements, and give additional examples. 📨
  3. Updated references to newer versions of various specifications. 📚
  4. Required SASL PLAIN (over TLS) as mandatory-to-implement. 🔒
  5. Clarified that the mechanism list can change. 🔄
  6. Deprecated the use of the 538 response code. 🙅‍♀️
  7. Added the use of the SASLprep profile for preparing authorization identities. ✨
  8. Substantial cleanup of response codes and indicated suggested enhanced response codes. Also indicated what response codes should result in a client prompting the user for new credentials. 🧹
  9. Updated ABNF section to use RFC 4234. 🧩
  10. Clarified interaction with SMTP PIPELINING extension. 🚰
  11. Added a reference to RFC 3848. 🔖
  12. Added a new Enhanced Status Code for "authentication line too long" case. 📏
  13. Other general editorial clarifications. 🌸

Editors' Addresses 💌

the editors, in their own words:

Robert Siemborski
Google, Inc.
1600 Ampitheatre Parkway
Mountain View, CA 94043, USA

Phone: +1 650 623 6925
EMail: robsiemb@google.com


Alexey Melnikov
Isode Limited
5 Castle Business Village, 36 Station Road,
Hampton, Middlesex, TW12 2BX, UK

EMail: Alexey.Melnikov@isode.com

Copyright (C) The IETF Trust (2007). 🌈

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜

The legal bit, verbatim because it matters 🫶:

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

the IETF takes no position on whether any Intellectual Property Rights or other rights might be claimed to cover the technology in this document, or how available any license under those rights might be, and it hasn't independently gone looking for any such rights either 🙈. if you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, assurances of licenses to be made available, and the results of attempts to get a general license or permission for implementers or users are all available from the IETF's online IPR repository at http://www.ietf.org/ipr 🔎.

the IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🙏

funding for the RFC Editor function is currently provided by the Internet Society. thank you, legends 💖

📦 where this page comes from