Negotiating an SMTP AUTH Authentication Mechanism

By Weldon Whipple <>

Carnegie Mellon University's Cysus SASL (Simple Authentication and Security Layer), can be built into sendmail (and other mail submission agents) to authenticate clients who want to submit mail for the mail server to relay elsewhere. A number of authentication "mechanisms" are available. The mechanism actually selected is negotiated between the mail server and the e-mail client.

The PLAIN and LOGIN Mechanisms

If a PLAIN or LOGIN mechanism is negotiated, the client sends his/her user name and password to the server in plain text (base64 encoded). (See Appendix A for an example PLAIN conversation; see Appendix B for a LOGIN conversation.)

Client Considerations

The LOGIN mechanism is supported by Microsoft's Outlook Express, as well as by some other clients. (The LOGIN mechanism is the only mechanism that Microsoft supports). Most other clients support the PLAIN authentication mechanism.

Since the vast majority of e-mail clients support only PLAIN or LOGIN, mail server administrators will probably want to consider using STARTTLS to provide an encryption "tunnel" between the client and server, to protect the user name and password.

Server Considerations

Servers that support only the PLAIN and LOGIN authentication mechanisms can let SASL compare user name and password against the standard Unix password file, using PAM (Portable Authentication Module).

The CRAM-MD5 Authentication Mechanism

The CRAM-MD5 (Challenge Response Authentication Mechanism-Message Digest 5) is one of the set of authentication mechanisms that encrypts the client's user name and password. For clients that support this mechanism, the authentication information is more secure than if LOGIN or PLAIN is used.

Client Considerations

The standard Eudora client (downloadable from tries to use CRAM-MD5 by default. Some other clients claim to use CRAM-MD5, but the writer hasn't succeeded in getting them to work.

If all users that need to relay through your e-mail server use Eudora, there is no need to use STARTTLS to encrypt the user name and password.

Server Considerations

The access control list for encrypted mechanisms can't be the Unix password file. Cyrus SASL requires that the user name and password be stored in a special database file that is under the control of SASL. This means that clients that want to relay with CRAM-MD5 (for example), will either need to shell to the mail server and issue the saslpasswd2 command to store their user name and password, or the administrator will need to provide some other method for clients to place information in the SASL database.

Other Authentication Mechanisms

As the author encounters other authentication mechanisms, he will add them to this document.

Appendix A: A PLAIN SMTP AUTH Conversation

A PLAIN SMTP Authentication conversation looks something like the following (after the mail server has indicated its support for the PLAIN AUTH mechanism):

S: 334
C: AHdlbGRvbgB3M2xkMG4=
S: 235 2.0.0 OK Authenticated

The third line of the above conversation is a base64 encoding of the string "^@weldon^@w3ld0n", where "^@" is a byte whose bits are all zeroes. In this example, the user name is "weldon" and the password is "w3ld0n".


  1. Base64 encoding is described in section 6.8 of RFC 2045.
  2. Users of the emacs editor can easily encode/decode base64 strings in the scratch buffer with the base64-encode-region and base64-decode-region commands.
  3. The openssl enc subcommand can also be used to encode and decode base64.

Appendix B: A LOGIN SMTP AUTH Conversation

A LOGIN SMTP Authentication conversation looks something like the following (after the mail server has indicated its support for the LOGIN mechanism):

S: 334 VXNlcm5hbWU6
C: d2VsZG9u
S: 334 UGFzc3dvcmQ6
C: dzNsZDBu
S: 235 2.0.0 OK Authenticated

Lines 2-5 of the conversation contain base64-encoded information. The same conversation, with base64 strings decoded, reads:

S: 334 Username:
C: weldon
S: 334 Password:
C: w3ld0n
S: 235 2.0.0 OK Authenticated