SASL (RFC 2222) provides additional authentication mechanisms for POP, IMAP, and SMTP user access protocols. Messaging Server has SASL support for the user access protocols listed in Table 13–3:
Table 13–3 SASL Authentication User Access Protocols Support Matrix
|
Plain |
Login |
CRAM-MD5 |
Digest-MD5 |
Certificate |
APOP |
---|---|---|---|---|---|---|
SMTP AUTH |
Yes |
Yes |
Yes |
Deprecated |
Yes |
- |
POP |
Yes |
- |
Yes |
Deprecated |
Yes |
Yes |
IMAP |
Yes |
- |
Yes |
Deprecated |
Yes |
- |
HTTP (Messenger Express) |
Yes |
- |
- |
- |
Yes |
- |
When using CRAM-MD5, passwords must be stored in plain text format in the LDAP directory server.
Digest-MD5 was never supported by the MMP and its use is deprecated in other cases.
To use APOP, CRAM-MD5 or DIGEST-MD5, passwords must be stored in plain text format in the LDAP directory server.
If you use SASL, user name and passwords are not encrypted unless SSL is used for the session. (For more information on SSL, see Encryption with SSL.) The SASL mechanisms, PLAIN and LOGIN, encode authentication information, but can be easily decoded if captured. Despite this limitation, SASL is useful because it can be combined with SMTP AUTH (described in Enabling Authenticated SMTP) to allow only authenticated users to relay mail through your system. For example, legitimate users can authenticate to the SMTP server, and the SMTP server can then be configured to switch to a different channel. In this way, the message from an authenticated session can come from a different TCP channel than a user that did not authenticate. A message from a user in your internal network can also be switched to differentiate it from a message coming from other sources just based on the IP address of the incoming connection.
For more information on SASL, see Chapter 23, Configuring Security and Access Control, in Sun Java System Messaging Server 6.3 Administration Guide.