Chapter 23 Configuring Security and Access Control

Messaging Server supports a full range of flexible security features that allow you to keep messages from being intercepted, prevent intruders from impersonating your users or administrators, and permit only specific people access to specific parts of your messaging system.

The Messaging Server security architecture is part of the security architecture of Sun Java System servers as a whole. It is built on industry standards and public protocols for maximum interoperability and consistency.

This chapter contains the following sections:

• 23.1 About Server Security

• 23.2 About HTTP Security

• 23.3 Configuring Authentication Mechanisms

• 23.4 User Password Login

• 23.5 Configuring Encryption and Certificate-Based Authentication

• 23.6 Configuring Administrator Access to Messaging Server

• 23.7 Configuring Client Access to POP, IMAP, and HTTP Services

• 23.8 Enabling POP Before SMTP

• 23.9 Configuring Client Access to SMTP Services

• 23.10 User/Group Directory Lookups Over SSL

23.1 About Server Security

Server security encompasses a broad set of topics. In most enterprises, ensuring that only authorized people have access to the servers, that passwords or identities are not compromised, that people do not misrepresent themselves as others when communicating, and that communications can be held confidential when necessary are all important requirements for a messaging system.

Perhaps because the security of server communication can be compromised in many ways, there are many approaches to enhancing it. This chapter focuses on setting up encryption, authentication, and access control. It discusses the following security-related Messaging Server topics:

• User ID and password login: requiring users to enter their user IDs and passwords to log in to IMAP, POP, HTTP, or SMTP, and the use of SMTP password login to transmit sender authentication to message recipients.

• Encryption and authentication: setting up your server to use the TLS and SSL protocols to encrypt communication and authenticate clients.

• Administrator access control: using the access-control facilities to delegate access to a Messaging Server and some of its individual tasks.

• TCP client access control: using filtering techniques to control which clients can connect to your server’s POP, IMAP, HTTP, and authenticated SMTP services.

Not all security and access issues related to Messaging Server are treated in this chapter. Security topics that are discussed elsewhere include the following:

• Physical security: Without provisions for keeping server machines physically secure, software security can be meaningless.

• Message-store access: You can define a set of message-store administrators for the Messaging Server. These administrators can view and monitor mailboxes and can control access to them. For details, see Chapter 20, Managing the Message Store

• End-user account configuration: End-user account information can be primarily maintained by using the Delegated Administrator product.

• Filtering unsolicited bulk email (UBE): See Chapter 18, Mail Filtering and Access Control

• Secure Multipurpose Internet Mail Extensions (S/MIME) is described in Chapter 24, Administering S/MIME for Communications Express Mail.

There are a large number of documents that cover a variety of security topics. For additional background on the topics mentioned here and for other security-related information, see documentation web site at http://docs.sun.com.

23.2 About HTTP Security

Messaging Server supports user ID/password authentication, client certificate authentication, and Access Manager. There are some differences, however, in how the protocols handle network connections between client and server.

When a POP, IMAP, or SMTP client logs in to Messaging Server, a connection is made and a session is established. The connection lasts for the duration of the session; that is, from login to logout. When establishing a new connection, the client must reauthenticate to the server.

When an HTTP client logs in to Messaging Server, the server provides a unique session ID to the client. The client uses the session ID to establish multiple connections during a session. The HTTP client need not reauthenticate for each connection; the client need only reauthenticate if the session is dropped and the client wants to establish a new session. (If an HTTP session remains idle for a specified time period, the server will automatically drop the HTTP session and the client is logged out; the default time period is 2 hours.)

The following techniques are used to improve the security of HTTP sessions:

• The session IDs are bound to a specific IP address.

• Each session ID has a timeout value associated with it; if the session ID is not used for a specified time period, the session ID becomes invalid.

• The server keeps a database of all open session IDs, so a client cannot forge an ID.

• The session ID is stored in the URL, but not in any cookie files.

For information about specifying configuration parameters for improved connection performance, see Chapter 5, Configuring POP, IMAP, and HTTP Services

For information on Access Manager see Chapter 6, Enabling Single Sign-On (SSO)

23.3 Configuring Authentication Mechanisms

An authentication mechanism is a particular method for a client to prove its identity to a server. Messaging Server supports authentication methods defined by the Simple Authentication and Security Layer (SASL) protocol and it supports certificate-based authentication. The SASL mechanisms are described in this section. For more information about certificate-based authentication, see 23.5 Configuring Encryption and Certificate-Based Authentication.

Messaging Server supports the following SASL authentication methods for password-based authentication.

• PLAIN - This mechanism passes the user’s plaintext password over the network, where it is susceptible to eavesdropping.

  Note that SSL can be used to alleviate the eavesdropping problem. For more information, see 23.5 Configuring Encryption and Certificate-Based Authentication

• DIGEST-MD5 - A challenge/response authentication mechanism defined in RFC 2831. (DIGEST-MD5 is not yet supported by Messaging Multiplexor.)

This feature is deprecated and will be removed in a future release.

• CRAM-MD5 - A challenge/response authentication mechanism similar to APOP, but suitable for use with other protocols as well. Defined in RFC 2195.

• APOP - A challenge/response authentication mechanism that can be used only with the POP3 protocol. Defined in RFC 1939.

• LOGIN - This is equivalent to PLAIN and exists only for compatibility with pre-standard implementations of SMTP authentication. By default the mechanism is only enabled for use by SMTP.

With a challenge/response authentication mechanism, the server sends a challenge string to the client. The client responds with a hash of that challenge and the user's password. If the client's response matches the server's own hash, the user is authenticated. The hash isn't reversible, so the user's password isn't exposed when sent over the network.

The POP, IMAP, and SMTP services support all SASL mechanisms. The HTTP service supports only the plaintext password mechanism.

Table 23–1 shows some SASL and SASL-related configutil parameters. For the latest and most complete listing of configutil parameters, see the configutil Parameters in Sun Java System Messaging Server 6.3 Administration Reference.

23.3.1 To Configure Access to Plaintext Passwords

To work, the CRAM-MD5, DIGEST-MD5, or APOP SASL authentication methods require access to the users’ plaintext passwords. You need to perform the following steps:

1. Configure Directory Server to store passwords in cleartext.

2. Configure Messaging Server so that it knows Directory Server is using cleartext passwords.

To Configure Directory Server to Store Cleartext Passwords

To enable CRAM-MD5, DIGEST-MD5, or APOP mechanisms, you must configure the Directory Server to store passwords in cleartext. If you are using a Directory Server prior to version 6 the following instructions should apply. For version 6 or later, refer to the latest Directory Server documentation (Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide): :

1. In the Directory Server Console, open the Directory Server you want to configure.

2. Click the Configuration tab.

3. Open Data in the left pane.

4. Click Passwords in the right pane.

5. From the Password encryption drop-down list, choose “cleartext”.

   ---

   Note –

   This change only impacts users created in the future. Existing users will have to transition or have their password reset after this change.

   ---

23.3.1.1 To Configure Messaging Server for Cleartext Passwords

You can now configure Messaging Server so that it knows the Directory Server is able to retrieve cleartext passwords. This makes it safe for Messaging Server to advertise APOP, CRAM-MD5, and DIGEST-MD5:

configutil -o sasl.default.ldap.has_plain_passwords -v 1

You can disable these challenge/response SASL mechanisms by setting the value to 0.

Existing users cannot use APOP, CRAM-MD5, or DIGEST-MD5 until their password is reset or migrated (see to Transition Users).

Note that MMP has an equivalent option: CRAMs.

23.3.2 To Transition Users

You can use configutil to specify information about transitioning users. An example would be if a user password changes or if a client attempts to authenticate with a mechanism for which they do not have a proper entry.

configutil -o sasl.default.auto_transition -v value

For value, you can specify one of the following:

• no or 0 - Don’t transition passwords. This is the default.

• yes or 1 - Do transition passwords.

To successfully transition users, you must set up ACIs in the Directory Server that allow Messaging Server write access to the user password attribute. To do this, perform the following steps:

To Transition Users

. If you are using a Directory Server prior to version 6 the following instructions apply. For version 6 or later, refer to the latest Directory Server documentation (Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide):

1. In Console, open the Directory Server you want to configure.

2. Click the Directory tab.

3. Select the base suffix for the user/group tree.

4. From the Object menu, select Access Permissions.

5. Select (double click) the ACI for “Messaging Server End User Administrator Write Access Rights”.

6. Click ACI Attributes.

7. Add the userpassword attribute to the list of existing attributes.

8. Click OK.

   sasl.default.mech_list can be used to enable a list of SASL mechanisms. If non-empty, this overrides the sasl.default.ldap.has_plain_passwords option as well as the service.imap.allowanonymouslogin option. This option applies to all protocols (imap, pop, smtp).

23.4 User Password Login

Requiring password submission on the part of users logging into Messaging Server to send or receive mail is a first line of defense against unauthorized access. Messaging Server supports password-based login for its IMAP, POP, HTTP, and SMTP services.

23.4.1 IMAP, POP, and HTTP Password Login

By default, internal users must submit a password to retrieve their messages from Messaging Server. You enable or disable password login separately for POP, IMAP, and HTTP services. For more information about password login for POP IMAP, and HTTP Services, see 5.2.2 Password-Based Login.

User passwords can be transmitted from the user’s client software to your server as cleartext or in encrypted form. If both the client and your server are configured to enable SSL and both support encryption of the required strength (as explained in 23.5.2 To Enable SSL and Selecting Ciphers), encryption occurs.

User IDs and passwords are stored in your installation’s LDAP user directory. Password security criteria, such as minimum length, are determined by directory policy requirements; they are not part of Messaging Server administration.

Certificate-based login is an alternative to password-based login. It is discussed in this chapter along with the rest of SSL; see 23.5.3 To Set Up Certificate-Based Login

Challenge/response SASL mechanisms are another alternative to plaintext password login.

23.4.2 SMTP Password Login

By default, users need not submit a password when they connect to the SMTP service of Messaging Server to send a message. You can, however, enable password login to SMTP in order to enable authenticated SMTP.

Authenticated SMTP is an extension to the SMTP protocol that allows clients to authenticate to the server. The authentication accompanies the message. The primary use of authenticated SMTP is to allow local users who are travelling (or using their home ISP) to submit mail (relay mail) without creating an open relay that others can abuse. The “AUTH” command is used by the client to authenticate to the server.

For instructions on enabling SMTP password login (and thus Authenticated SMTP), see 12.4.4 SMTP Authentication, SASL, and TLS.

You can use Authenticated SMTP with or without SSL encryption.

23.5 Configuring Encryption and Certificate-Based Authentication

This section contains the following subsections:

• 23.5.1 Obtaining Certificates

• 23.5.2 To Enable SSL and Selecting Ciphers

• 23.5.3 To Set Up Certificate-Based Login

• 23.5.4 How to Optimize SSL Performance Using the SMTP Proxy

Messaging Server uses the Transport Layer Security (TLS) protocol, otherwise known as the Secure Sockets Layer (SSL) protocol, for encrypted communications and for certificate-based authentication of clients and servers. Messaging Server supports SSL versions 3.0 and 3.1. TLS is fully compatible with SSL and includes all necessary SSL functionality.

For background information on SSL, see Introduction to SSL in Managing Servers With iPlanet Console 5.0. SSL is based on the concepts of public-key cryptography, described in Introduction to Public-Key Cryptography in Managing Servers With iPlanet Console 5.0.).

If transmission of messages between a Messaging Server and its clients and between the server and other servers is encrypted, there is little chance for eavesdropping on the communications. If connecting clients are authenticated, there is little chance for intruders to impersonate (spoof) them.

SSL functions as a protocol layer beneath the application layers of IMAP4, HTTP, POP3, and SMTP. SMTP and SMTP/SSL use the same port; HTTP and HTTP/SSL require different ports; IMAP and IMAP/SSL, and POP and POP/SSL can use the same port or different ports. SSL acts at a specific stage of message communication, as shown in Figure 23–1, for both outgoing and incoming messages.

Figure 23–1 Encrypted Communications with Messaging Server

SSL provides hop-to-hop encryption, but the message is not encrypted on each intermediate server.

To enable encryption for outgoing messages, you must modify the channel definition to include the tls channel keywords, such as maytls, musttls, and so on. For more information, see the 12.4.8 Transport Layer Security Manual.

Keep in mind that the extra overhead in setting up an SSL connection can put a performance burden on the server. In designing your messaging installation and in analyzing performance, you may need to balance security needs against server capacity.

23.5.1 Obtaining Certificates

Whether you use SSL for encryption or for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers. Another way of obtaining certificates is using msgcert command (described later in this section). Note that the old certutil command still works, but may be more complex to use and is not internationalized. For more information on certutil, see 23.5 Configuring Encryption and Certificate-Based Authentication and http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.

This section consists of the following subsections:

• 23.5.1.1 To Manage Internal and External Modules

• 23.5.1.2 Creating a Password File

• 23.5.1.3 Obtaining and Managing Certificates

• 23.5.1.4 About msgcert

• 23.5.1.5 Managing Certificates

• To Create a Messaging Server Certificate Database with a Default Self-signed Certificate

• To Manage Self-Signed Certificates

• 23.5.1.6 To Install Certificates of Trusted CAs

23.5.1.1 To Manage Internal and External Modules

A server certificate establishes the ownership and validity of a key pair, the numbers used to encrypt and decrypt data. Your server’s certificate and key pair represent your server’s identity. They are stored in a certificate database that can be either internal to the server or on an external, removable hardware card (smartcard).

Sun Java System servers access a key and certificate database using a module conforming to the Public-Key Cryptography System (PKCS) #11 API. The PKCS #11 module for a given hardware device is usually obtained from its supplier and must be installed into the Messaging Server before the Messaging Server can use that device. The pre-installed “Netscape Internal PKCS # 11 Module” supports a single internal software token that uses the certificate database that is internal to the server.

Setting up the server for a certificate involves creating a database for the certificate and its keys and installing a PKCS #11 module. If you do not use an external hardware token, you create an internal database on your server, and you use the internal, default module that is part of Messaging Server. If you do use an external token, you connect a hardware smartcard reader and install its PKCS #11 module.

In the following sections we will refer to the console or Directory Server Console. This refers to Directory Server prior to version 6. For version 6 or later, the graphical user interface is called the Directory Server Control Center. Refer to the latest Directory Server documentation (Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide) for more information.

You can manage PKCS #11 modules, whether internal or external, through Console. To install a PKCS #11 module:

1. Connect a hardware card reader to the Messaging Server host machine and install drivers.

2. Use the modutil found in msg-svr-base/sbin to install the PKCS #11 module for the installed driver.

Installing Hardware Encryption Accelerators. If you use SSL for encryption, you may be able to improve server performance in encrypting and decrypting messages by installing a hardware encryption accelerator. An encryption accelerator typically consists of a hardware board, installed permanently in your server machine, plus a software driver. Messaging Server supports accelerator modules that follow the PKCS #11 API. (They are essentially hardware tokens that do not store their own keys; they use the internal database for that.) You install an accelerator by first installing the hardware and drivers as specified by the manufacturer, and then completing the installation—as with hardware certificate tokens—by installing the PKCS #11 module.

23.5.1.2 Creating a Password File

On most Sun Java System servers for which SSL is enabled, the administrator is prompted at startup to supply the password required to decrypt the key pair. On Messaging Server, however, to alleviate the inconvenience of having to enter the password multiple times (it is needed by at least three server processes), and to facilitate unattended server restarts, the password is read from a password file. Passwords themselves are generated when their certificate database is created using the msgcert generate_certdb command.

The password file is named sslpassword.conf and is in the directory msg-svr-base/config/. Entries in the file are individual lines with the format

moduleName:password

where moduleName is the name of the (internal or external) PKCS #11 module to be used, and password is the password that decrypts that module’s key pair. The password is stored as clear (unencrypted) text.

Messaging Server provides a default version of the password file, with the following single entry (for the internal module and default password):

Internal (Software) Token:netscape!

If you specify anything but the default password when you install an internal certificate, you need to edit the above line of the password file to reflect the password you specified. If you install an external module, you need to add a new line to the file, containing the module name and the password you specified for it.

Because the administrator is not prompted for the module password at server startup, it is especially important that you ensure proper administrator access control to the server and proper physical security of the server host machine and its backups.

23.5.1.3 Obtaining and Managing Certificates

Whether you use SSL for encryption or for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers. The primary mechanism for obtaining and managing certificates is using the msgcert. However, if the Administration Server is installed, you can also use the Administration Console.

The rest of this section describes how to use msgcert.

23.5.1.4 About msgcert

msgcert allows you to generate a certificate request, add a certificate to the certificate database, list certificates in the database and so on. For detailed information enter the following at the command line:

msg-svr-base/sbin/msgcert --help

This is shown below.

# ./msgcert --help

Usage: msgcert SUBCMD [GLOBAL_OPTS] [SUBCMD_OPTS] [SUBCMD_OPERANDS]
Manages the Messaging Servers Certificate Database
The accepted values for SUBCMD are:

add-cert              Adds a certificate to the certificate database
add-selfsign-cert     Creates and adds a selfsign certificate to the 
                      certificate database
export-cert           Exports a certificate and its keys from the database
generate-certDB       Creates Messaging Server Databases cert8.db key3.db 
                      secmod.db and sslPassword
import-cert           Adds a new certificate and its keys to the cert database
import-selfsign-cert  Adds a new selfsign certificate and its keys to the 
                      cert database
list-certs            Lists all certificates in the Certificate database
remove-cert           Removes a certificate from the database
renew-cert            Renews a certificate
renew-selfsign-cert   Renews a selfsign certificate
request-cert          Generates a certificate request
show-cert             Displays a certificate

The accepted value for GLOBAL_OPTS is:-?, --help
                Displays SUBCMD help

NOTE: You must stop all the TLS or SSL-enabled servers before making any 
changes to the Certificate Database.

Each of the sub-commands shown above performs a specific certificate management function. Details about these sub-commands and their functions can be obtained by entering the following:

msgcert SUBCMD –help

The remainder of this section will describe some common certificate management procedures.

23.5.1.5 Managing Certificates

This section describes how to manage SSL certificates in Messaging Server To run SSL on Messaging Server, you must either use a self-signed certificate or a Public Key Infrastructure (PKI) solution which involves an external Certificate Authority (CA). For a PKI solution, you need a CA-signed server certificate which contains both a public and a private key. This certificate is specific to one Messaging Server. You also need a trusted CA certificate, which contains a public key. The trusted CA certificate ensures that all server certificates from your CA are trusted. This certificate is sometimes also called a CA root key or root certificate.

Configuring the Certificate Database Password

When managing certificates, you do not need to type a certificate password or specify the password file. You can simply pass the password as -W argument. Example:

echo "password22" > /tmp/certdbpwd
echo "password22" > /tmp/certdbpwd
# ./msgcert list-certs -W /tmp/certdbpwd

To Create a Messaging Server Certificate Database with a Default Self-signed Certificate

1. To create a Messaging Server Certificate Database run the following command:

   msgcert generate-certDB

   This reads the certificate database password from CERT_PW_FILE (Default: prompt for password)

2. You can view this certificate by using the command:

   msgcert show-cert Server-Cert

To Manage Self-Signed Certificates

If you are using certificates for test purposes, you can use self-signed certificates. In deployment configurations, you might prefer to use trusted Certificate Authority (CA) certificates. You can also use the Directory Server Admin Console to perform this task.

1. When you create the certificate database, a default self-signed certificate is automatically provided. If you want to use a self-signed certificate with non-default settings, use the msgcert add-selfsign-cert command. Example:

   msgcert add-selfsign-cert --name siroe --org comms --org-unit Messaging --city SantaClara --state ca --country us MySelfSigned-Cert

   A self-signed certificate is valid for three months.

2. When your self-signed certificate expires, renew the certificate with the command:

   msgcert renew-selfsign-cert cert_alias

23.5.1.6 To Install Certificates of Trusted CAs

Use ./msgcert add-cert to install the certificates of certificate authorities. A CA certificate validates the identity of the CA itself. The server uses these CA certificates in the process of authenticating clients and other servers.

If, for example, you set up your enterprise for certificate-based client authentication in addition to password-based authentication (see “Setting Up Certificate-Based Login” on page 157), you need to install the CA certificates of all CAs that are trusted to issue the certificates that your clients may present. These CAs may be internal to your organization or they may be external, representing commercial or governmental authorities or other enterprises. (For more details on the use of CA certificates for authentication, see Introduction to Public-Key Cryptography in in Managing Servers With iPlanet Console 5.0.)

When installed, Messaging Server initially contains CA certificates for several commercial CAs. If you need to add other commercial CAs or if your enterprise is developing its own CA for internal use (using Sun Java System Certificate Server), you need to obtain and install additional CA certificates.

The CA certificates automatically provided with Messaging Server are not initially marked as trusted for client certificates. You need to edit the trust settings if you want to trust client certificates issued by these CAs. For instructions, see 23.5.1 Obtaining Certificates.

The following procedure describes the process of requesting and installing CA-signed server and trusted CA certificates for use with Messaging Server.

To Request a CA-Signed Server Certificate

You can also use the Directory Server Admin Console to perform this task.

1. Generate a CA--signed server certificate request.

   msgcert request-cert [-W CERT_PW_FILE] {-S DN|--name NAME [--org ORG] [--org-unit ORG-UNIT] [--city CITY] [--state STATE] [--country COUNTRY] } [-F FORMAT] [-o OUTPUT_FILE]

   Below is an example of a request for a CA-signed server certificate. It returns the certificate in binary format:

   ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -o my_ca_signed_request_cert

   To return the certificate in ASCII format use the command as follows:

   ./msgcert request-cert --name aqua --org siroe --org-unit Messaging -F ascii -o my_casigned_request_cert

   Certificate Authorities usually require all of the attributes that are shown in this example in order to completely identify the server. For a description of each attribute, enter ./msgcert request-cert --help. When you request a certificate by using msgcert request-cert, the resulting certificate request is a binary certificate request unless you specify ASCII as output format. If you specify ASCII, the resulting certificate request is a PKCS #10 certificate request in PEM format. PEM is the Privacy Enhanced Mail format specified by RFCs 1421 through 1424 and used to represent a base64-encoded certificate request in US-ASCII characters. The content of the request look similar to the following example:

   -----BEGIN NEW CERTIFICATE REQUEST----- MIIBdTCB3wIBADA2MRIwEAYDVQQLEwlNZXNzYWdpbmcxDjAMBgNVBAoTBXNpcm9l MRAwDgYDVQQDEwdhcXVhdGljMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDt KEh5Fnj/h9GEu18Da6DkJpcNShkwxanjnKs2883ZoUV5Sp4pN7U6Vfbh0414WXZh D26m3t81q9b9h47Klkf0pW1X3BB6LOjGOHSt2VoNBI8n3hJ6XiN2zYbrlLTgdKuo y0YrSG/kHFnqKghikag9O/Ox+cwD+mpjl2QnsPZgswIDAQABoAAwDQYJKoZIhvcN AQEEBQADgYEArqgWQIwNZDC2d3EZawI23Wj9o6Pyvu9J1rkb+NYgIEnNp9jugxqX F326N0ABLdHXXNX/2ZvC5TKOgS4RidTBM89N9xJvokmvRGfc+1x80uxy474YdNlZ s+nP8AYo9dW9mrLOammozx9HLPSVYNFp4FxekgV2n8QG7WC5rkN5bCE= -----END NEW CERTIFICATE REQUEST-----

2. Transmit the certificate request to your Certificate Authority, according to its procedures.

   The process for obtaining your Certificate Authority certificate differs depending on the certificate authority you use. Some commercial CAs provide a website that allows you to automatically download the certificate. Other CAs will email it to you upon request.

   After you have sent your request, you must wait for the CA to respond with your certificate. Response time for your request varies. For example, if your CA is internal to your company, the CA might only take a day or two to respond to your request. If your selected CA is external to your company, the CA could take several weeks to respond to your request.

3. Save the certificate you receive back from the Certificate Authority.

   You should back up your certificates in a safe location. If you ever lose the certificates, you can reinstall them by using your backup file. You can save them in text files. The PKCS #11 certificate in PEM format looks similar to the following example.

   -----BEGIN CERTIFICATE----- MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6 6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo= -----END CERTIFICATE-----

To Add the CA-Signed Server Certificate and Trusted CA Certificate

You can also use the Directory Server Admin Console to perform this task.

1. Add the CA--signed server certificate using the following command:

   msgcert add-cert cert_alias cert_file

   Where cert_alias is a name which you give to identify your certificate, and cert_file is the text file containing the PKCS #11 certificate in PEM format.

   For example, to install a CA-signed server certificate, you might use a command similar to:

   msgcert add-cert /my_cert/server-cert-file

   The certificate is now installed, but is not yet trusted. To trust the CA-signed server certificate, you must install the Certificate Authority certificate.

2. Add the trusted Certificate Authority certificate using the following command:

   msgcert add-cert -C cert_alias cert_file

   The -C option indicates that the certificate is a trusted Certificate Authority certificate.

   For example, to install a trusted certificate from a Certificate Authority, you might use the command:

   msgcert add-cert -C CA-cert /my_cert/ca-cert-file

3. Optionally, use the following command to verify your installed certificates:

   To list all server certificates, showing information such as alias and validity dates:

   msgcert list-certs

   The Messaging server will have a default certificate called Server-Cert when generated with ./msgcert generate-CertDB . The text Same as issuer indicates that the default certificate is a self-signed server certificate. For example:

   # ./msgcert list-certs Enter the certificate database password: Alias Valid from Expires on Self- Issued by Issued to signed ------------ ---------------- --------------- ------ --------------------- -------------- SelfSignedCrt 2006/07/28 12:58 2006/10/28 12:58 y CN=SFO,L=SC,ST=ca,C=us Same as issuer Server-Cert 2006/07/28 07:47 2006/10/28 07:47 y CN=perseids Same as issuer 2 certificates found

   To list trusted CA certificates:

   msgcert list-certs -C

   To view the details of a certificate, including the certificate expiry date:

   msgcert show-cert cert_alias

   For example, to show a self-signed certificate:

   # ./msgcert show-cert MySelfSigned-Cert Enter the certificate database password: Certificate: Data: Version: 3 (0x2) Serial Number: 00:83:35:37:94 Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us" Validity: Not Before: Fri Jul 28 19:58:31 2006 Not After : Sat Oct 28 19:58:31 2006 Subject: "CN=siroe,O=comms,OU=Messaging,L=SantaClara,ST=ca,C=us" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: aa:9d:3d:23:b2:59:39:f3:77:c8:69:7f:b0:d1:ac:d2: 4e:81:c8:51:0f:27:6f:a1:21:4b:a9:27:46:d7:0f:b4: c8:44:86:32:5e:4f:2f:1c:2f:a9:b8:a3:49:b5:b8:ab: 51:a8:a5:ba:1c:e8:90:7d:46:67:f9:a7:44:c5:1d:24: e6:bd:e8:8f:07:b4:5a:68:41:b1:19:f2:ea:98:ba:25: 55:b8:ba:9c:af:bb:43:c3:c0:8f:14:a7:4c:2b:50:b4: ac:df:b5:cd:68:de:a6:14:9d:68:77:d3:8b:7f:de:c0: 5d:35:d7:55:8d:b5:c3:14:2a:60:a9:bf:de:96:90:a9 Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 15:86:f1:cc:85:c9:08:0f:ff:d3:56:d8:e2:c8:ea:3c: 8e:45:36:be:8b:b0:7d:2f:e9:cd:e3:b4:ad:8c:70:59: c8:a5:14:da:9c:fa:7f:70:86:64:34:0b:21:ae:c4:28: d2:f5:94:5c:a6:78:0f:d9:fd:fc:c5:5e:37:49:25:a9: bc:12:59:cb:fb:4e:e9:d4:8a:8d:3d:41:12:ae:f1:7f: 8d:d3:10:ac:fb:33:51:5d:0c:1b:dc:23:5f:95:d5:6d: c6:1d:e5:ed:13:8b:16:41:89:5b:4d:de:c0:c7:56:a2: 48:82:38:32:5a:99:d5:21:20:c5:0d:5c:ea:0c:84:aa Fingerprint (MD5): EF:76:A3:6C:09:4E:BC:6B:87:76:A3:35:70:1F:B2:C4 Fingerprint (SHA1): BB:1C:20:4B:79:3A:F1:49:F0:83:FB:CC:9C:56:10:D3:06:97:AA:07 Certificate Trust Flags: SSL Flags: Valid CA Trusted CA User Trusted Client CA Email Flags: User Object Signing Flags: User

Renewing an Expired CA-Signed Server Certificate

When your CA-signed server certificate (public and private key) expires, you can renew it by using the following procedure. You can also use the Directory Server Admin Console to perform this task.

1. Obtain an updated CA-signed server certificate from your Certificate Authority.

2. Once you receive the updated certificate, install the certificate.

   msgcert renew-cert cert_alias cert_file

To Export and Import a CA-Signed Server Certificate

In some cases you might want to export a certificate so that you can later import the certificate, for example, to another host. You can also use the Directory Server Admin Console to perform this task.

1. Export the certificate.

   msgcert export-cert [-o OUTPUT_FILE] CERT_ALIAS

   For example:

   $ ./msgcert export-cert -o /tmp/first-certificate "First Certificate" $./msgcert export-cert -o /tmp/first-server-certificate Server-Cert Choose the PKCS#12 file password: Confirm the PKCS#12 file password: $ls /tmp first-server-certificate /tmp/first-certificate

2. Import the certificate.

   $ msgcert import-cert CERT_FILE

   For example, to import the certificate

   $ msgcert import-cert /tmp/first-server-certificate Enter the PKCS#12 file password: $

23.5.2 To Enable SSL and Selecting Ciphers

You can use Console to enable SSL and to select the set of encryption ciphers that Messaging Server can use in its encrypted communications with clients. You can also install the SSL certificate using the msgcert utility and run the appropriate configutil or edit the appropriate configuration files necessary to enable SSL for that particular service.

23.5.2.1 About Ciphers

A cipher is the algorithm used to encrypt and decrypt data in the encryption process. Some ciphers are stronger than others, meaning that a message they have scrambled is more difficult for an unauthorized person to unscramble.

A cipher operates on data by applying a key—a long number—to the data. Generally, the longer the key the cipher uses during encryption, the harder it is to decrypt the data without the proper decryption key.

When a client initiates an SSL connection with a Messaging Server, the client lets the server know what ciphers and key lengths it prefers to use for encryption. In any encrypted communication, both parties must use the same ciphers. Because there are a number of cipher-and-key combinations in common use, a server should be flexible in its support for encryption. Messaging Server can support up to 6 combinations of cipher and key length.

Table 23–2 lists the ciphers that Messaging Server supports for use with SSL 3.0. The table summarizes information that is available in more detail in the Introduction to SSL section of Managing Servers with iPlanet Console.

Unless you have a compelling reason for not using a specific cipher, you should support them all. However, note that export laws restrict the use of certain encryption ciphers in certain countries. Also, some client software produced before the relaxation of United States Export Control laws cannot use the higher strength encryption. Be aware that while the 40-bit ciphers might hinder the casual eavesdropper, they are not secure and therefore will not stop a motivated attack.

To enable SSL and select encryption ciphers, follow these command line steps:

To specify a certificate:

configutil -o encryption.rsa.nssslpersonalityssl -v certname

There is also a per-service configuration setting for the SSL server certificate nickname. The new configutil settings are as follows:

local.imta.sslnicknames for the SMTP and Submit servers; local.imap.sslnicknames for the IMAP server; local.pop.sslnicknames for the POP server; local.http.sslnicknames for web mail server.

They have the same meaning (and override) the encryption.rsa.nssslpersonalityssl setting. Specifically, this is a comma-separated list of NSS certificate nicknames. Although more than one nickname is permitted in the list, each nickname must refer to a different type of certificate (for example, an RSA cert and a DSS cert) so the setting will almost always be only one nickname. A nickname can be unqualified in which case the NSS software token or default token will be searched, or it can have the form security-module:nickname" in which case the specified security module will be searched for that nickname. This is needed for certificates stored in hardware tokens or places other than the default NSS database.

This does not permit the use of more than one NSS software token in the product. In particular, there is only one cert8.db, key3.db and secmod.db for IMAP, POP, SMTP and HTTP. NSS doesn't permit that.

To enable SSL encryption for outgoing messages, you must modify the channel definition to include the tls channel keywords, such as maytls, musttls, and so on. For more information, see the 12.4.8 Transport Layer Security Manual.

23.5.3 To Set Up Certificate-Based Login

In addition to password-based authentication, Sun Java System servers support authentication of users through examination of their digital certificates. In certificate-based authentication, the client establishes an SSL session with the server and submits the user’s certificate to the server. The server then evaluates whether the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.

To set up your Messaging Server for certificate-based login:

To Set Up Certificate-Based Login

1. Obtain a server certificate for your server. (For details, see 23.5.1 Obtaining Certificates

2. Run the Certificate Setup Wizard to install the certificates of any trusted certificate authorities that will issue certificates to the users your server will authenticate. (For details, see 23.5.1.6 To Install Certificates of Trusted CAs

   Note that as long as there is at least one trusted CA in the server’s database, the server requests a client certificate from each connecting client.

3. Turn on SSL. (For details, see 23.5.2 To Enable SSL and Selecting Ciphers

4. (Optional) Edit your server’s certmap.conf file so that the server appropriately searches the LDAP user directory based on information in the submitted certificates.

   Editing the certmap.conf file is not necessary if the email address in your users’ certificates matches the email address in your users’ directory entries, and you do not need to optimize searches or validate the submitted certificate against a certificate in the user entry.

   For details of the format of certmap.conf and the changes you can make, see the SSL chapter of Managing Servers with iPlanet Console.

   Once you have taken these steps, when a client establishes an SSL session so that the user can log in to IMAP or HTTP, the Messaging Server requests the user’s certificate from the client. If the certificate submitted by the client has been issued by a CA that the server has established as trusted, and if the identity in the certificate matches an entry in the user directory, the user is authenticated and access is granted (depending on access-control rules governing that user).

   There is no need to disallow password-based login to enable certificate-based login. If password-based login is allowed (which is the default state), and if you have performed the tasks described in this section, both password-based and certificate-based login are supported. In that case, 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 supply a certificate, the server requests a password.

23.5.4 How to Optimize SSL Performance Using the SMTP Proxy

Most sites should not use the SMTP proxy as it adds additional latency to the SMTP protocol. However, a large-scale site which makes heavy use of SSL to protect SMTP connections may wish to maximize their investment in SSL accelerator hardware by performing all SSL operations for all protocols on a server which does nothing other than SSL and proxy. The SMTP proxy allows SSL to be processed by a front end proxy server while the mail queues are on a separate MTA machine. This way hardware optimized for each task can be separately configured and purchased.

See Using the MMP SMTP Proxy in Sun Java Communications Suite 5 Deployment Planning Guide and 23.8 Enabling POP Before SMTP for instructions on how to install the SMTP Proxy.

23.6 Configuring Administrator Access to Messaging Server

This section mostly pertains to the Sun Java System LDAP Schema v. 1. This section contains the following subsections:

• 23.6.1 Hierarchy of Delegated Administration

• To Provide Access to the Server as a Whole

• 23.6.2 To Restrict Access to Specific Tasks

This section describes how to control the ways in which server administrators can gain access to Messaging Server. Administrative access to a given Messaging Server and to specific Messaging Server tasks occurs within the context of delegated server administration.

Delegated server administration is a feature of most Sun Java System servers; it refers to the capability of an administrator to provide other administrators with selective access to individual servers and server features. This chapter briefly summarizes delegated server tasks. For more detailed information, see the chapter on delegating server administration in Managing Servers with iPlanet Console.

23.6.1 Hierarchy of Delegated Administration

When you install the first Sun Java System server on your network, the installation program automatically creates a group in the LDAP user directory called the Configuration Administrators group. By default, the members of the Configuration Administrators group have unrestricted access to all hosts and servers on your network.

The Configuration Administrators group is at the top of an access hierarchy, such as the following, that you can create to implement delegated administration (if Sun Java System LDAP Schema v. 1 is used) for Messaging Server:

1. Configuration administrator. The “super user” for the network of Sun Java System servers. Has complete access to all resources.

2. Server administrator. A domain administrator might create groups to administer each type of server. For example, a Messaging Administrators group might be created to administer all Messaging Servers in an administrative domain or across the whole network. Members of that group have access to all Messaging Servers (but no other servers) in that administrative domain.

3. Task administrator. Finally, any of the above administrators might create a group, or designate an individual user, with restricted access to a single Messaging Server or a set of Messaging Servers. Such a task administrator is permitted to perform only specific, limited server tasks (such as starting or stopping the server only, or accessing logs of a given service).

Console provides convenient interfaces that allow an administrator to perform the following tasks:

• Grant a group or an individual access to a specific Messaging Server, as described in “Providing Access to the Server as a Whole” (next).

• Restrict that access to specific tasks on a specific Messaging Server, as described in 23.6.2 To Restrict Access to Specific Tasks.

To Provide Access to the Server as a Whole

This section describes to give a user or group permission to access a given instance of Messaging Server.

1. Log in to Console as an administrator with access to the Messaging Server you want to provide access to.

2. Select that server in the Console window.

   From the Console menu, choose Object, then choose Set Access Permissions.

3. Add or edit the list of users and groups with access to the server.

   (For more complete instructions, see the chapter on delegating server administration in Managing Servers with iPlanet Console.)

   Once you have set up the list of individuals and groups that have access to the particular Messaging Server, you can then use ACIs, as described next, to delegate specific server tasks to specific people or groups on that list.

23.6.2 To Restrict Access to Specific Tasks

An administrator typically connects to a server to perform one or more administrative tasks. Common administrative tasks are listed in the Messaging Server Tasks form in Console.

By default, access to a particular Messaging Server means access to all of its tasks. However, each task in the Task form can have an attached set of access-control instructions (ACIs). The server consults those ACIs before giving a connected user (who must already be a user with access permissions to the server as a whole) access to any of the tasks. In fact, the server displays in the Tasks form only those tasks to which the user has permission.

If you have access to a Messaging Server, you can create or edit ACIs on any of the tasks (that is, on any of the tasks to which you have access), and thus restrict the access that other users or groups can have to them.

To Restrict the Task Access of a User or Group

1. Log in to the Console as an administrator with access to the Messaging Server you want to provide restricted access to.

2. Open the server and select a task in the server’s Tasks form by clicking on the Task text.

3. From the Edit menu, choose Set Access Permissions, and add or edit the list of access rules to give a user or group the kind of access you want them to have.

4. Repeat the process for other tasks, as appropriate.

   (For more complete instructions, see the chapter on delegating server administration in Managing Servers with iPlanet Console.)

   ACIs and how to create them are described more fully in the chapter on delegating server administration in Managing Servers with iPlanet Console.

23.7 Configuring Client Access to POP, IMAP, and HTTP Services

This section contains the following subsections:

• 23.7.1 How Client Access Filters Work

• 23.7.2 Filter Syntax

• 23.7.3 Filter Examples

• 23.7.4 To Create Access Filters for Services

• 23.7.5 To Create Access Filters for HTTP Proxy Authentication

Messaging Server provides two methods of access control on a service-by-service basis for its IMAP, POP, and HTTP services. These processes allow you to exercise far-ranging and fine-grained control over which clients can gain access to your server. The first method allows you to specify control over specific internal users and domains. You do this by setting the LDAP attributes mailAllowedServiceAccess in Sun Java Communications Suite 5 Schema Reference or mailDomainAllowedServiceAccess in Sun Java Communications Suite 5 Schema Reference.

The second method, which is described in this section, uses the configutil parameters service.service.domainallowed, service.service.domainnotallowed and service.service.proxydomainallowed.

If you are managing messaging services for a large enterprise or an Internet service provider, these capabilities can help you to exclude spammers and DNS spoofers from your system and improve the general security of your network. For control of unsolicited bulk email specifically, see also Chapter 18, Mail Filtering and Access Control

If controlling access by IP address is not an important issue for your enterprise, you do not have to create any of the filters described in this section. If minimal access control is all you need, see 23.7.3.2 Mostly Allowing for instructions on setting it up.

23.7.1 How Client Access Filters Work

The Messaging Server access-control facility is a program that listens at the same port as the TCP daemon it serves; it uses access filters to verify client identity, and it gives the client access to the daemon if the client passes the filtering process.

As part of its processing, the Messaging Server TCP client access-control system performs (when necessary) the following analyses of the socket end-point addresses:

• Reverse DNS lookups of both end points (to perform name-based access control)

• Forward DNS lookups of both end points (to detect DNS spoofing)

• Identd callback (to check that the user on the client end is known to the client host)

The system compares this information against access-control statements called filters to decide whether to grant or deny access. For each service, separate sets of Allow filters and Deny filters control access. Allow filters explicitly grant access; Deny filters explicitly forbid access.

When a client requests access to a service, the access-control system compares the client’s address or name information to each of that service’s filters—in order—using these criteria:

• The search stops at the first match. Because Allow filters are processed before Deny filters, Allow filters take precedence.

• Access is granted if the client information matches an Allow filter for that service.

• Access is denied if the client information matches a Deny filter for that service.

• If no match with any Allow or Deny filter occurs, access is granted—except in the case where there are Allow filters but no Deny filters, in which case lack of a match means that access is denied.

The filter syntax described here is flexible enough that you should be able to implement many different kinds of access-control policies in a simple and straightforward manner. You can use both Allow filters and Deny filters in any combination, even though you can probably implement most policies by using almost exclusively Allows or almost exclusively Denies.

The following sections describe filter syntax in detail and give usage examples. The section 23.7.4 To Create Access Filters for Services gives the procedure for creating access filters.

23.7.2 Filter Syntax

Filter statements contain both service information and client information. The service information can include the name of the service, names of hosts, and addresses of hosts. The client information can include host names, host addresses, and user names. Both the server and client information can include wildcard names or patterns.

The very simplest form of a filter is:

service: hostSpec

where service is the name of the service (such as smtp, pop, imap, or http) and hostSpec is the host name, IP address, or wildcard name or pattern that represents the client requesting access. When a filter is processed, if the client seeking access matches client, access is either allowed or denied (depending on which type of filter this is) to the service specified by service. Here are some examples:

imap: roberts.newyork.siroe.com
pop: ALL
http: ALL

If these are Allow filters, the first one grants the host roberts.newyork.siroe.com access to the IMAP service, and the second and third grant all clients access to the POP and HTTP services, respectively. If they are Deny filters, they deny those clients access to those services. (For descriptions of wildcard names such as ALL, see 23.7.2.1 Wildcard Names.)

Either the server or the client information in a filter can be somewhat more complex than this, in which case the filter has the more general form of:

serviceSpec: clientSpec

where serviceSpec can be either service or service@hostSpec, and clientSpec can be either hostSpec or user@hostSpec. user is the user name (or a wildcard name) associated with the client host seeking access. Here are two examples:

pop@mailServer1.siroe.com: ALL
imap: srashad@xyz.europe.siroe.com

If these are Deny filters, the first filter denies all clients access to the SMTP service on the host mailServer1.siroe.com. The second filter denies the user srashad at the host xyz.europe.siroe.com access to the IMAP service. (For more information on when to use these expanded server and client specifications, see 23.7.2.4 Server-Host Specification and 23.7.2.5 Client User-Name Specification

Finally, at its most general, a filter has the form:

serviceList: clientList

where serviceList consists of one or more serviceSpec entries, and clientList consists of one or more clientSpec entries. Individual entries within serviceList and clientList are separated by blanks and/or commas.

In this case, when a filter is processed, if the client seeking access matches any of the clientSpec entries in clientList, then access is either allowed or denied (depending on which type of filter this is) to all the services specified in serviceList. Here is an example:

pop, imap, http: .europe.siroe.com .newyork.siroe.com

If this is an Allow filter, it grants access to POP, IMAP, and HTTP services to all clients in either of the domains europe.siroe.com and newyork.siroe.com. For information on using a leading dot or other pattern to specify domains or subnet, see 23.7.2.2 Wildcard Patterns.

You can also use the following syntax:

“+” or “-” serviceList:*$next_rule

+ (allow filter) means the daemon list services are being granted to the client list.

- (deny filter) means the services are being denied to the client list.

* (wildcard filter) allow all clients to used these services.

$ separates rules.

This example enables multiple services on all clients.

+imap,pop,http:*

This example shows multiple rules, but each rule is simplified to have only one service name and uses wildcards for the client list. (This is the most commonly used method of specifying access control in LDIF files.)

+imap:ALL$+pop:ALL$+http:ALL

An example of how to disallow all services for a user is:

-imap:*$-pop:*$-http:*

23.7.2.1 Wildcard Names

You can use the following wildcard names to represent service names, host names or addresses, or user names:

23.7.2.2 Wildcard Patterns

You can use the following patterns in service or client addresses:

• A string that begins with a dot character (.). A host name is matched if the last components of its name match the specified pattern. For example, the wildcard pattern.siroe.com matches all hosts in the domain siroe.com.

• A string that ends with a dot character (.). A host address is matched if its first numeric fields match the specified pattern. For example, the wildcard pattern 123.45. matches the address of any host in the subnet 123.45.0.0.

• A string of the form n.n.n.n/m.m.m.m. This wildcard pattern is interpreted as a net/mask pair. A host address is matched if net is equal to the bitwise AND of the address and mask. For example, the pattern 123.45.67.0/255.255.255.128 matches every address in the range 123.45.67.0 through 123.45.67.127.

23.7.2.3 EXCEPT Operator

The access-control system supports a single operator. You can use the EXCEPT operator to create exceptions to matching names or patterns when you have multiple entries in either serviceList or clientList. For example, the expression:

list1 EXCEPT list2

means that anything that matches list1 is matched, unless it also matches list2.

Here is an example:

ALL: ALL EXCEPT isserver.siroe.com

If this were a Deny filter, it would deny access to all services to all clients except those on the host machine isserver.siroe.com.

EXCEPT clauses can be nested. The expression:

list1 EXCEPT list2 EXCEPT list3

is evaluated as if it were:

list1 EXCEPT (list2 EXCEPT list3)

23.7.2.4 Server-Host Specification

You can further identify the specific service being requested in a filter by including server host name or address information in the serviceSpec entry. In that case the entry has the form:

service@hostSpec

You might want to use this feature when your Messaging Server host machine is set up for multiple internet addresses with different internet host names. If you are a service provider, you can use this facility to host multiple domains, with different access-control rules, on a single server instance.

23.7.2.5 Client User-Name Specification

For client host machines that support the identd service as described in RFC 1413, you can further identify the specific client requesting service by including the client’s user name in the clientSpec entry in a filter. In that case the entry has the form:

user@hostSpec

where user is the user name as returned by the client’s identd service (or a wildcard name).

Specifying client user names in a filter can be useful, but keep these caveats in mind:

• The identd service is not authentication; the client user name it returns cannot be trusted if the client system has been compromised. In general, do not use specific user names; use only the wildcard names ALL, KNOWN, or UNKNOWN.

• identd is not supported by most modern client machines and thus provides little added value in modern deployments. We are considering removal of identd support in a future version, so please inform Sun Java System if this feature is of value to your site.

• User-name lookups take time; performing lookups on all users may slow access by clients that do not support identd. Selective user-name lookups can alleviate this problem. For example, a rule like:

  serviceList: @xyzcorp.com ALL@ALL

  would match users in the domain xyzcorp.com without doing user-name lookups, but it would perform user-name lookups with all other systems.

The user-name lookup capability can in some cases help you guard against attack from unauthorized users on the client’s host. It is possible in some TCP/IP implementations, for example, for intruders to use rsh (remote shell service) to impersonate trusted client hosts. If the client host supports the ident service, you can use user-name lookups to detect such attacks.

23.7.3 Filter Examples

The examples in this section show a variety of approaches to controlling access. In studying the examples, keep in mind that Allow filters are processed before Deny filters, the search terminates when a match is found, and access is granted when no match is found at all.

The examples listed here use host and domain names rather than IP addresses. Remember that you can include address and netmask information in filters, which can improve reliability in the case of name-service failure.

23.7.3.1 Mostly Denying

In this case, access is denied by default. Only explicitly authorized hosts are permitted access.

The default policy (no access) is implemented with a single, trivial deny file:

ALL: ALL

This filter denies all service to all clients that have not been explicitly granted access by an Allow filter. The Allow filters, then, might be something like these:

ALL: LOCAL @netgroup1

ALL: .siroe.com EXCEPT externalserver.siroe.com

The first rule permits access from all hosts in the local domain (that is, all hosts with no dot in their host name) and from members of the group netgroup1. The second rule uses a leading-dot wildcard pattern to permit access from all hosts in the siroe.com domain, with the exception of the host externalserver.siroe.com.

23.7.3.2 Mostly Allowing

In this case, access is granted by default. Only explicitly specified hosts are denied access.

The default policy (access granted) makes Allow filters unnecessary. The unwanted clients are listed explicitly in Deny filters such as these:

ALL: externalserver.siroe1.com, .siroe.asia.com
ALL EXCEPT pop: contractor.siroe1.com, .siroe.com

The first filter denies all services to a particular host and to a specific domain. The second filter permits nothing but POP access from a particular host and from a specific domain.

23.7.3.3 Denying Access to Spoofed Domains

You can use the DNSSPOOFER wildcard name in a filter to detect host-name spoofing. When you specify DNSSPOOFER, the access-control system performs forward or reverse DNS lookups to verify that the client’s presented host name matches its actual IP address. Here is an example for a Deny filter:

ALL: DNSSPOOFER

This filter denies all services to all remote hosts whose IP addresses don’t match their DNS host names.

23.7.3.4 Controlling Access to Virtual Domains

If your messaging installation uses virtual domains, in which a single server instance is associated with multiple IP addresses and domain names, you can control access to each virtual domain through a combination of Allow and Deny filters. For example, you can use Allow filters like:

ALL@msgServer.siroe1.com: @.siroe1.com
ALL@msgServer.siroe2.com: @.siroe2.com
...

coupled with a Deny filter like:

ALL: ALL

Each Allow filter permits only hosts within domainN to connect to the service whose IP address corresponds to msgServer.siroeN.com. All other connections are denied.

23.7.3.5 Controlling IMAP Access While Permitting Access to Webmail

If you wish to allow users to access Webmail, but not access IMAP, create a filter like this:

+imap:access_server_host, access_server_host

This permits IMAP only from the access server hosts. You can set the filter at the IMAP server level using service.imap.domainallowed, or at the domain/user level with LDAP attributes.

23.7.4 To Create Access Filters for Services

You can create Allow and Deny filters for the IMAP, POP, or HTTP services. You can also create them for SMTP services, but they have little value because they only apply to authenticated SMTP sessions. See Chapter 18, Mail Filtering and Access Control

To Create Filters

1. Command Line. You can also specify access and deny filters at the command line as follows:

   To create or edit access filters for services:

   configutil -o service.service.domainallowed -v filter

   where service is pop, imap, or http and filter follows the syntax rules described in 23.7.2 Filter Syntax.

   To create or edit deny filters for services:

   configutil -o service.service.domainnotallowed -v filter

   where service is pop, imap, or http and filter follows the syntax rules described in 23.7.2 Filter Syntax. For a variety of examples, see 23.7.3 Filter Examples

23.7.5 To Create Access Filters for HTTP Proxy Authentication

Any store administrator can proxy authenticate to any service. (For more information about store administrators, see 20.4 Specifying Administrator Access to the Store authenticate to the service if their client host is granted access via a proxy authentication access filter.

Proxy authentication allows other services, such as a portal site, to authenticate users and pass the authentication credentials to the HTTP login service. For example, assume a portal site offers several services, one of which is Messenger Express web-based email. By using the HTTP proxy authentication feature, end users need only authenticate once to the portal service; they need not authenticate again to access their email. The portal site must configure a login server that acts as the interface between the client and the service. To help configure the login server for Messenger Express authentication, Sun Java System offers an authentication SDK for Messenger Express.

This section describes how to create allow filters to permit HTTP proxy authentication by IP address. This section does not describe how to set up your login server or how to use the Messenger Express authentication SDK. For more information about setting up your login server for Messenger Express and using the authentication SDK, contact your Sun Java System representative.

To Create Access Filters for HTTP Proxy Authentication

1. Command Line. Specify access filters for proxy authentication to the HTTP service at the command line as follows:

   configutil -o service.service.proxydomainallowed -v filter

   where filter follows the syntax rules described in 23.7.2 Filter Syntax.

23.8 Enabling POP Before SMTP

SMTP Authentication, or SMTP Auth (RFC 2554) is the preferred method of providing SMTP relay server security. SMTP Auth allows only authenticated users to send mail through the MTA. However, some legacy clients only provide support for POP before SMTP. If this is the case for your system, you may enable POP before SMTP as described below. If possible, however, encourage your users to upgrade their POP clients rather than using POP before SMTP. Once POP before SMTP is deployed at a site users will become dependent on clients which fail to follow Internet security standards, putting end users at greater risk of hacking and slowing your site with the unavoidable performance penalty because of the necessity of having to track and coordinate IP addresses of recent successful POP sessions.

The Messaging Server implementation of POP before SMTP is completely different from either SIMS or Netscape Messaging Server. POP before SMTP is supported by configuring a Messaging Multiplexor (MMP) to have both a POP and SMTP proxy. When an SMTP client connects to the SMTP proxy, the proxy will check an in-memory cache of recent POP authentications. If a POP authentication from the same client IP address is found, the SMTP proxy will inform the SMTP server that it should permit messages directed to both local and non-local recipients.

To Install the SMTP Proxy

For guidelines on using the SMTP proxy see Using the MMP SMTP Proxy in Sun Java Communications Suite 5 Deployment Planning Guide.

1. Install a Messaging Multiplexor (MMP).

   See the Sun Java Communications Suite 5 Installation Guide for instructions.

2. Enable the SMTP proxy on the MMP.

   Add the string:

   msg-svr-base/lib/SmtpProxyAService@25|587

   to the ServiceList option in the msg-svr-base/config/AService.cfg file. That option is one long line and can’t contain line breaks.

   ---

   Note –

   When the MMP is upgraded, four new files which correspond to the existing four configuration files for the MMP are created. The new files are:

   AService-def.cfg, ImapProxyAService-def.cfg, PopProxyAService-def.cfg, and SmtpProxyAService-def.cfg

   The four configuration files described in the documentation are not created or affected by the install process. When the MMP starts up, it will look for the normal configuration file (as currently documented). If it doesn’t find the normal configuration file, it will attempt to copy the respective *AService-def.cfg file to the corresponding *AService.cfg file name.

   ---

3. Set the PROXY_PASSWORD option in the SMTP channel option file tcp_local_option at each SMTP relay server.

   When the SMTP proxy connects to the SMTP server, it has to inform the SMTP server of the real client IP address and other connection information so that the SMTP server can correctly apply relay blocking and other security policy (including POP before SMTP authorization). This is a security sensitive operation and must be authenticated. The proxy password configured on both the MMP SMTP Proxy and the SMTP server assures that a third party cannot abuse the facility.

   Example: PROXY_PASSWORD=A_Password

4. Make sure the IP address that the MMP uses to connect to the SMTP server is not treated as “internal” by the INTERNAL_IP mapping table.

   See the 18.6 To Add SMTP Relaying of the Chapter 18, Mail Filtering and Access Control for information about the INTERNAL_IP mapping table.

5. Configure the SMTP proxy to Support POP before SMTP.

   1. Edit the msg-svr-base /config/SmtpProxyAService.cfg configuration file.

      The following SMTP proxy options operate identically to the same options for the IMAP and POP proxies (see Chapter 7, Configuring and Administering Multiplexor Services these options in the Encryption (SSL) Option section in the Encryption (SSL) Option in Sun Java System Messaging Server 6.3 Administration Reference.

      LdapURL, LogDir, LogLevel, BindDN, BindPass, Timeout, Banner, SSLEnable, SSLSecmodFile, SSLCertFile, SSLKeyFile, SSLKeyPasswdFile, SSLCipherSpecs, SSLCertNicknames, SSLCacheDir, SSLPorts, CertMapFile, CertmapDN, ConnLimits, TCPAccess

      Other MMP options not listed above (including the BacksidePort option) do not currently apply to the SMTP Proxy.

      Add the following five options:

      SmtpRelays is a space-separated list of SMTP relay server hostnames (with optional port) to use for round-robin relay. These relays must support the XPROXYEHLO extension. This option is mandatory with no default.

      Example: default:SmtpRelays manatee:485 gonzo mothra

      SmtpProxyPassword is a password used to authorize source channel changes on the SMTP relay servers. This option is mandatory with no default and must match the PROXY_PASSWORD option on the SMTP servers.

      Example: default:SmtpProxyPassword A_Password

      EhloKeywords option provides a list of EHLO extension keywords for the proxy to pass through to the client, in addition to the default set. The MMP will remove any unrecognized EHLO keywords from the EHLO list returned by an SMTP relay. EhloKeywords specifies additional EHLO keywords which should not be removed from the list. The default is empty, but the SMTP proxy will support the following keywords, so there is no need to list them in this option: 8BITMIME, PIPELINING, DSN, ENHANCEDSTATUSCODES, EXPN, HELP, XLOOP, ETRN, SIZE, STARTTLS, AUTH

      The following is an example that might be used by a site which uses the rarely used “TURN” extension:

      Example: default:EhloKeywords TURN

      PopBeforeSmtpKludgeChannel option is set to the name of an MTA channel to use for POP before SMTP authorized connections. The default is empty and the typical setting for users who want to enable POP before SMTP is tcp_intranet. This option is not required for optimizing SSL performance (see 23.5.4 How to Optimize SSL Performance Using the SMTP Proxy.

      Example: default:PopBeforeSmtpKludgeChannel tcp_intranet

      ClientLookup option defaults to no. If set to yes, a DNS reverse lookup on the client IP address will be performed unconditionally so the SMTP relay server doesn’t have to do that work This option may be set on a per hosted domain basis.

      Example: default:ClientLookup yes

   2. Set the PreAuth option and the AuthServiceTTL option in PopProxyAService.cfg configuration file. This option is not required for optimizing SSL performance. (See 23.5.4 How to Optimize SSL Performance Using the SMTP Proxy

      These options specify how long in seconds a user is authorized to submit mail after a POP authentication. The typical setting is 900 to 1800 (15-30 minutes).

      Example:

      default:PreAuth yes default:AuthServiceTTL 900

   3. You may optionally specify how many seconds the MMP will wait for an SMTP Relay to respond before trying the next one in the list.

      The default is 10 (seconds). If a connection to an SMTP Relay fails, the MMP will avoid trying that relay for a number of minutes equivalent to the failover time-out (so if the failover time-out is 10 seconds, and a relay fails, the MMP won’t try that relay again for 10 minutes).

      Example: default:FailoverTimeout 10

23.9 Configuring Client Access to SMTP Services

For information about configuring client access to SMTP services, see Chapter 18, Mail Filtering and Access Control

23.10 User/Group Directory Lookups Over SSL

It is possible to do user/group directory lookups over SSL for MTA, MMP and IMAP/POP/HTTP services. The prerequisite is that Messaging Server must be configured in SSL mode. Set the following configutil parameters to enable this feature: local.service.pab.ldapport to 636, local.ugldapport to 636, local.ugldapusessl to 1.