You can control how users are permitted to log in to the POP, IMAP, or HTTP service to retrieve mail. You can allow password-based login (for all services), and certificate-based login (for IMAP or HTTP services). This section provides background information; for the steps you follow to make these settings, see 5.5 To Configure POP Services, 5.6 To Configure IMAP Services or 5.7 To Configure HTTP Services. In addition, you can specify the valid login separator for POP logins. This section consists of the following subsections:
Some mail clients will not accept @ as the login separator (that is, the @ in an address like uid@domain). Examples of these clients are Netscape Messenger 4.76, Netscape Messenger 6.0, and Microsoft Outlook Express on Windows 2000. The workaround is as follows:
Inform POP client users that they should login with + as the login separator, not @.
A typical login involves the user entering a user ID followed by a separator and the domain name and then the password. Users in the default domain specified during installation, however, can log in without entering a domain name or separator.
To allow users of other domains to log in with just the user ID (that is, without having to use the domain name and separator) set sasl.default.ldap.searchfordomain to 0. Note that the user ID must be unique to the entire directory tree. If it is not unique, logging in without the domain name will not work.
You may wish to modify the attribute that user must enter to log in. For example if you want to allow the user to log in with a phone number (telephoneNumber) or employee number (employeeID) change the LDAP search defined by configutil parameter sasl.default.ldap.searchfilter. This parameter is a global default setting for the inetDomainSearchFilter per-domain attribute and follows the same syntax.
Refer to the Sun Java System Messaging Server 6.3 Administration Reference for further information on these parameters.
In typical messaging installations, users access their mailboxes by entering a password into their POP. IMAP or HTTP mail client. The client sends the password to the server, which uses it to authenticate the user. If the user is authenticated, the server decides, based on access-control rules, whether or not to grant the user access to certain mailboxes stored on that server.
If you allow password login, users can access POP, IMAP, or HTTP by entering a password. (Password- or SSL-based login is the only authentication method for POP services.) Passwords are stored in an LDAP directory. Directory policies determine what password policies, such as minimum length, are in effect.
If you disallow password login for IMAP or HTTP services, password-based authentication is not permitted. Users are then required to use certificate-based login, as described in the next section.
To increase the security of password transmission for IMAP and HTTP services, you can require that passwords be encrypted before they are sent to your server. You do this by selecting a minimum cipher-length requirement for login.
If you choose 0, you do not require encryption. Passwords are sent in the clear or they are encrypted, depending on client policy.
If you choose a nonzero value, the client must establish an SSL session with the server—using a cipher whose key length is at least the value you specify—thus encrypting any IMAP or HTTP user passwords the client sends.
If the client is configured to require encryption with key lengths greater than the maximum your server supports, or if your server is configured to require encryption with key lengths greater than what the client supports, password-based login cannot occur. For information on setting up your server to support various ciphers and key lengths, see 23.5.2 To Enable SSL and Selecting Ciphers.
In addition to password-based authentication, Sun Java System servers support the authentication of users through examination of their digital certificates. Instead of presenting a password, the client presents the user’s certificate when it establishes an SSL session with the server. If the certificate is validated, the user is considered authenticated.
For instructions on setting up Messaging Server to accept certificate-based user login to the IMAP or HTTP service, see 23.5.3 To Set Up Certificate-Based Login
If you have performed the tasks required to set up certificate-based login, both password-based and certificate-based login are supported. Then, if the client establishes an SSL session and supplies a certificate, certificate-based login is used. If the client does not use SSL or does not present a client certificate, it will send a password instead.