By Weldon Whipple <weldon@whipple.org>
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.
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.)
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.
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 (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.
The standard Eudora client (downloadable from www.eudora.com 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.
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.
As the author encounters other authentication mechanisms, he will add them to this document.
A PLAIN SMTP Authentication conversation looks something like the following (after the mail server has indicated its support for the PLAIN AUTH mechanism):
C: AUTH PLAIN 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".
A LOGIN SMTP Authentication conversation looks something like the following (after the mail server has indicated its support for the LOGIN mechanism):
C: AUTH LOGIN 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:
C: AUTH LOGIN S: 334 Username: C: weldon S: 334 Password: C: w3ld0n S: 235 2.0.0 OK Authenticated