Complete Contents
About This Guide
Chapter 1 Getting Started with Netscape Messaging Server
Chapter 2 Configuring POP, IMAP, and HTTP Services
Chapter 3 Configuring SMTP Services
Chapter 4 Managing Mail Users and Mailing Lists
Chapter 5 Managing the Message Store
Chapter 6 Security and Access Control
Chapter 7 Working with SMTP Plugins
Chapter 8 Filtering Unsolicited Bulk Email
Chapter 9 Message Routing
Chapter 10 Monitoring and Maintaining Your Server
Chapter 11 Logging and Log Analysis
Chapter 12 Program Delivery
Chapter 13 Messaging Multiplexor
Appendix A Command Line Utilities
Appendix B sendmail Migration and Compatibility
Appendix C SNMP MIB
Glossary
Index
Messaging Server Administrator's Guide: Security and Access Control
Previous Next Contents Index


Chapter 6 Security and Access Control

Netscape 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 Netscape servers as a whole. It is built on industry standards and public protocols for maximum interoperability and consistency. To implement Messaging Server security policies, therefore, you will need not only this chapter but several other documents as well. In particular, information in Managing Servers with Netscape Console is required for setting up Messaging Server security.

This chapter has the following sections:


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:

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

Netscape has produced 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 the Security page on the Netscape DevEdge Web site.


About HTTP Security
Messaging Server supports the same security features for the HTTP protocol as it does for the IMAP protocol--both user ID/password authentication and client certificate authentication are supported. 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.)

HTTP session connections remain secure because:

For information about specifying configuration parameters for improved connection performance, see Performance Parameters.


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.

IMAP, POP, and HTTP Password Login

By default, 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 Password-Based Login.

User passwords can be transmitted from the user's client software to your server as clear text or in encrypted form (IMAP and HTTP only). If both the client and your server are configured to enable SSL and both support encryption of the required strength (as explained in Enabling SSL), 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 Setting Up Certificate-Based Login.

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, in which message-sender authentication accompanies a message, thus permitting the receiver of the message to know that the sender was authenticated by the sender's messaging server. Authenticated SMTP is designed for use within a set of trusted servers in which no server-to-server certificate authentication is being employed. For instructions on enabling SMTP password login (and thus Authenticated SMTP), see Enabling Authenticated SMTP.

Figure 6.1 summarizes how Authenticated SMTP works. When SMTP password login is enabled, clients and servers follow this process:

  1. When the client connects to its SMTP server to send a message, it first transmits an auth plain command after its EHLO command to let the server know that authentication should accompany this message.
  2. The client typically requires the user to enter a password only once per session, regardless of how many messages the user sends.

  3. When the sending client's server connects to the next server in the chain of transmission, it performs these two tasks related to client authentication:
  4. Note: Because server-password information is stored in an enterprise's LDAP directory, the authentication exchange can occur only between servers that share an LDAP directory--which typically means only servers within a single enterprise. Authenticated SMTP is usually not applied to external message transmission.

  5. When the recipient's messaging server receives the message, it stores the message in the user's mailbox along with an indication that the sender's name is authenticated.
  6. When the user's mail client retrieves the message, it appends an indication of the authentication to the message header. In the Netscape mail client, the word "Internal" appears next to the authenticated sender's name.
You can use Authenticated SMTP with or without SSL encryption.

Figure 6.1 Message transmission with Authenticated SMTP


Configuring SSL Encryption and Authentication
Messaging Server uses the Secure Sockets Layer (SSL) protocol for encrypted communications and for certificate-based authentication of clients and servers. See Introduction to SSL (reproduced as an appendix to Managing Servers with Netscape Console) for background information on SSL. SSL itself is based on the concepts of public-key cryptography, described in Introduction to Public-Key Cryptography (also reproduced as an appendix to Managing Servers with Netscape Console).

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, and SMTP. SMTP and SMTP/SSL use the same port; HTTP and HTTP/SSL require different ports; IMAP and IMAP/SSL can use the same port or different ports. SSL acts at a specific stage of message communication, as shown in Figure 6.2 for both outgoing and incoming messages.

Figure 6.2 Encrypted communications with Messaging Server

Complete end-to-end encryption of message transmission may require the use of all SSL-related protocols.

Note: To enable SSL encryption for outgoing messages, you must use the configutil command to modify the configuration parameter, service.smtp.sslusesslrelay. This parameter is not turned on by default. For more information on using configutil, see configutil.

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.

Netscape Messaging Server supports only SSL version 3.0.

Note: Because all Netscape servers support SSL, and the interface for enabling and configuring SSL through Netscape Console is nearly identical across all servers, several of the tasks described in this section are documented more completely in the SSL chapter of Managing Servers with Netscape Console. For those tasks, this chapter gives summary information only.

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.

Managing 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).

Likewise, the software module that manages the keys and certificates database can be either internal or external. Netscape servers support both internal and external modules that conform to the Public-Key Cryptography System (PKCS) #11 protocol.

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.

You can manage PKCS #11 modules, whether internal or external, through Netscape 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 PKCS #11 Management interface in Netscape Console to connect the PKCS #11 module to the installed driver.
(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

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. Netscape Messaging Server supports accelerator modules that follow the PKCS #11 protocol. (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.

Requesting a Server Certificate

You request a server certificate by opening your server in Netscape Console and running the Certificate Setup Wizard. You can access the Wizard from the Console menu or from the Messaging Server Encryption tab. Using the Wizard, you perform the following tasks:

  1. Generate a certificate request.
  2. Send the request by email to the certificate authority (CA) that is to issue the certificate.
When the email response from the CA arrives, you save it as a text file.

(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Creating a Password File

On any Netscape server, when you use the Certificate Setup Wizard to request a certificate, the wizard creates a key pair to be stored in either the internal module's database or in an external database (on a smartcard). The wizard then prompts you for a password, which it uses to encrypt the stored key pair. Only that same password can later be used to decrypt the keys. The wizard does not retain the password nor store it anywhere.

On most Netscape 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 4.1, 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.

The password file is named sslpassword.conf and is in the directory installDirectory/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 4.1 provides a default version of the password file, with the following single entry (for the internal module and default password):

Communicator Certificate DB: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.

Caution: 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 server backups.

Installing the Certificate

Installing is a separate process from requesting. Once the email response to your request for a certificate has arrived from the CA and been saved as a text file, run the Certificate Setup Wizard once more to install the file as a certificate:

  1. Specify that you are installing a certificate that you have already obtained.
  2. Paste the text of your certificate into a field when prompted to do so.
(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Note: This is also the process you follow to install a CA certificate (described next), which your server uses to determine whether to trust the certificates presented by clients.

Installing Certificates of Trusted CAs

You also use the Certificate Setup Wizard to install the certificates of certificate authorities. A CA certificate validates the identity of the CA itself. Your 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), 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. (See Introduction to Cryptography for more details on the use of CA certificates for authentication.)

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 Netscape Certificate Server), you need to obtain and install additional CA certificates.

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

To request and install a new CA certificate, you:

  1. Contact the certificate authority (possibly through the Web or by email) and request a CA certificate.
  2. Save the received text of the certificate as a text file.
  3. Use the Certificate Setup Wizard, as described in the previous section, to install the certificate.
(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Managing Certificates and Trusted CAs

Your server can have any number of certificates of trusted CAs that it uses for authentication of clients.

You can view, edit the trust settings of, or delete any of the certificates installed in your Messaging Server by opening your server in Netscape Console and choosing the Certificate Management Command in the Console menu. For instructions, see the chapter on SSL in Managing Servers with Netscape Console.

Enabling SSL

You can use Netscape Console to enable SSL and to select the set of encryption ciphers that Messaging Server can use in its encrypted communications with clients.

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. Netscape Messaging Server 4.1 can support up to 6 combinations of cipher and key length.

Table 6.1 lists the ciphers that Messaging Server supports for use with SSL 3.0. The table summarizes information that is available in more detail in Introduction to SSL; please consult that document before making final decisions on what ciphers to support.

Table 6.1 SSL ciphers for Messaging Server

Cipher
Description
RC4 with 128-bit encryption and MD5 message authentication
The fastest encryption cipher (by RSA) and a very high-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
Triple DES with 168-bit encryption and SHA message authentication
A slower encryption cipher (a U.S. government-standard) but the highest-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
DES with 56-bit encryption and SHA message authentication
A slower encryption cipher (a U.S. government-standard) and a moderate-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
RC4 with 40-bit encryption and MD5 message authentication
The fastest encryption cipher (by RSA) and a lower-strength combination of cipher and encryption key. Suitable for international use.
RC2 with 40-bit encryption and MD5 message authentication
A slower encryption cipher (by RSA) and a lower-strength combination of cipher and encryption key. Suitable for international use.
No encryption, only MD5 message authentication
No encryption; use of a message digest for authentication alone.

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. Basically, key lengths of greater than 40 bits can be used only in the United States and Canada. For details, see Export Restrictions on International Saleson the Netscape DevEdge Web site. In general, Messaging Server cannot use the higher-strength encryption for any communication with international versions of client software.

Enabling SSL and Selecting Ciphers

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

  1. In Netscape Console, open the Messaging Server whose cipher settings you want to modify.
  2. Click the Configuration tab in the left pane and select the Services folder.
  3. Click the Encryption tab in the right pane.
  4. Check the Enable SSL box to enable SSL on your server.
  5. Check the RSA box if you want to enable RSA ciphers.
  6. Check the Fortezza box if you want to enable Fortezza ciphers.
  7. You'll see the Fortezza box only if you have an export version of the server.

  8. From the Token drop-down list, choose the token you want to use.
  9. From the Certificate drop-down list, choose the certificate you want to use.
  10. Click Cipher Preferences to open the list of available ciphers.
  11. Click the boxes to select the encryption cipher or ciphers that you want your server to support.
To disable SSL completely, deselect the Enable SSL box.

Note: To enable SSL encryption for outgoing messages, you must use the configutil command to modify the configuration parameter, service.smtp.sslusesslrelay. This parameter is not turned on by default. For more information on using configutil, see configutil.

Command Line

You can also set values for these parameters at the command line as follows:

To enable or disable SSL:

configutil -o nsserversecurity -v [ on | off ]

To enable or disable RSA ciphers:

configutil -o encryption.rsa.nssslactivation -v [ on | off ]

To specify a token:

configutil -o encryption.rsa.nsssltoken -v tokenname

To specify a certificate:

configutil -o encryption.rsa.nssslpersonalityssl -v certname

Note: If you enable RSA ciphers, you must also specify a token and a certificate.

To choose a cipher preference:

configutil -o encryption.nsssl3ciphers -v cipherlist

where cipherlist is a comma-separated list of ciphers.

Setting Up Certificate-Based Login

In addition to password-based authentication, Netscape 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:

  1. Obtain a server certificate for your server. (For details, see 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 Installing Certificates of Trusted CAs.)
  3. 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.

  4. Turn on SSL. (For details, see Enabling SSL.)
  5. (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.
  6. 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 if 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 Netscape 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 (see 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.

For more details on setting up your entire installation of Netscape servers and clients to use certificate-based authentication, see the Single Sign-On Deployment Guide.


Configuring Administrator Access to Messaging Server
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 administration. Delegated administration is a feature of all Netscape servers; it refers to the capability of an administrator to provide other administrators with selective access to individual servers and server features. For an overview of delegated administration, see the chapter on delegating server administration in Managing Servers with Netscape Console.

Note: Most tasks described in this section are common to all Netscape servers, and are therefore described fully only in the chapter on delegating server administration in Managing Servers with Netscape Console. This chapter briefly summarizes the tasks.

Hierarchy of Delegated Administration

When you install the first Netscape 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 for Messaging Server:

  1. Configuration administrator. The "super user" for the network of Netscape servers. Has complete access to all resources.
  2. Domain administrator. The configuration administrator typically creates one or more other groups, each with more restricted access. For example the configuration administrator might create a Domain Administrators group and give it access to all servers for a specific administrative domain in the network. (An administrative domain is the set of hosts and servers on the network that share the same user directory for looking up account information.)
  3. 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.
  4. 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).
Netscape Console provides convenient interfaces that allow an administrator to perform the following tasks:

Providing Access to the Server as a Whole

To give a user or group permission to access a given instance of Messaging Server, you:

  1. Log in to Netscape Console as an administrator with access to the Messaging Server you want to provide access to.
  2. Select that server in the Console window, and choose Set Access Permissions in the Console menu.
  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 Netscape 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.

Restricting 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 Netscape Console (see Figure 1.13).

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 that a connected user or group can have, you:

  1. Log in to the Netscape 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.
  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 Netscape Console.)

For example, suppose you want to create a group of administrators responsible for log analysis, and you also have an individual (Dimitria) who is responsible for filtering out unsolicited bulk email (UBE). You can:

  1. Create a group called Logging Admins and add the appropriate people to it.
  2. Use Set Access Permissions for the Netscape Console Configuration window to give both Logging Admins and Dimitria access to the Messaging Server.
  3. Use Set Access Permissions for the Messaging Server Tasks form to place ACIs on the various tasks, making sure that the Logging Admin group sees (and thus has access to) only the logging-related tasks, and that Dimitria sees only the UBE filter-configuration task.
ACIs and how to create them are described more fully in the chapter on delegating server administration in Managing Servers with Netscape Console.


Configuring Client Access to TCP Services
Messaging Server supports sophisticated access control on a service-by-service basis for its TCP-based services (IMAP, POP, HTTP, and SMTP), so that you can exercise far-ranging and fine-grained control over which clients can gain access to your server.

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 spam mail (unsolicited bulk email) specifically, see also Chapter 8, Filtering Unsolicited Bulk Email.

Note: If controlling user access 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 the section Mostly Allowing for instructions on setting it up.

How Client Access Filters Work

The Messaging Server access-control facility for TCP clients is an implementation of the TCP wrapper concept. A TCP wrapper 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. The design of the Messaging Server TCP wrapper is based on the Unix Tcpd access-control facility (created by Wietse Venema) and the identd service (described in Internet draft RFC 1413).

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:

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 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 Creating Access Filters for Services gives the procedure for creating access filters.

Filter Syntax

Filter statements contain both server information and client information. The server 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 hostSpec, 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.airius.com

pop: ALL

http: ALL

If these are Allow filters, the first one grants the host roberts.newyork.airius.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 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:

smtp@mailServer1.airius.com: ALL

imap: srashad@xyz.europe.airius.com

If these are Deny filters, the first filter denies all clients access to the SMTP service on the host mailServer1.airius.com. The second filter denies the user srashad at the host xyz.europe.airius.com access to the IMAP service. (For more information on when to use these expanded server and client specifications, see Server-Host Specification and 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.airius.com .newyork.airius.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.airius.com and newyork.airius.com. For information on using a leading dot or other pattern to specify domains or subnet, see Wildcard Patterns.

Wildcard Names

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

Table 6.2 Wildcard names

Wildcard Name
Explanation
ALL
The universal wildcard. Matches all names.
LOCAL
Matches any local host (one whose name does not contain a dot character). However, if your installation uses only canonical names, even local host names will contain dots and thus will not match this wildcard.
UNKNOWN
Matches any user whose name is unknown, or any host whose name or address is unknown.

Use this wildcard name carefully:
KNOWN
Matches any user whose name is known, or any host whose name and address are known.

Use this wildcard name carefully:
DNSSPOOFER
Matches any host whose DNS name does not match its own IP address.

Wildcard Patterns

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

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.airius.com

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

EXCEPT clauses can be nested. The expression:

list1 EXCEPT list2 EXCEPT list3 

is evaluated as if it were:

list1 EXCEPT (list2 EXCEPT list3)

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.

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 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. For an example and discussion, see Allowing Only Identified Users.

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.

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: .airius.com EXCEPT externalserver.airius.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 airius.com domain, with the exception of the host externalserver.airius.com.

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.airius1.com, .airius.asia.com

ALL EXCEPT pop: contractor.airius1.com, .airius.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.

Allowing Only Identified Users

You can use the following Deny filter to exclude all users but those known to a client host's identd service:

ALL: UNKWOWN@ALL

The filter denies all services to all unknown users from all domains.

You could write a more specific Deny filter, with a clientSpec entry of UNKNOWN@host. When it receives a request from host, the access-control system then uses the ident service on host to find out whether that host actually sent the request and what the user name of the requestor is. If the host responds that the sending user is unknown, that may be evidence of an attack. (However, note also that, if the client's host does not support the identd service, all requestors will match the UNKNOWN@host filter.)

Employing user-name lookups in Allow filters is less trustworthy. Suppose you write an Allow filter with a clientSpec entry of KNOWN@host. Because an intruder can spoof both the client connection and the ident lookup, a match with the KNOWN@host filter is not strong evidence of absence of spoofing. Furthermore, if the client system has been compromised (as noted earlier), ident may return false information.

For more information, see Client User-Name Specification.

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.

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.airius1.com: @.airius1.com

ALL@msgServer.airius2.com: @.airius2.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.airiusN.com. All other connections are denied.

Denying an Individual User

If you must deny access to an especially notorious individual user, the most general Deny filter you can apply is the following:

ALL: badUser@ALL

This filter cannot, of course, guard against the same person attempting to gain access under a different user name.

Creating Access Filters for Services

You can create Allow and Deny filters for the IMAP, POP, HTTP, or SMTP services. Follow these steps to create filters:

  1. In Netscape Console, open the Messaging Server that you want to create access filters for.
  2. Click the Configuration tab.
  3. Open the Services folder in the left pane and select IMAP, POP, HTTP, or SMTP beneath the Services folder.
  4. Click the Access tab in the right pane.
  5. The Allow and Deny fields in the tab show the existing Allow and Deny filters for that service. Each line in the field represents one filter. For either of the fields, you can specify the following actions:

Note: If you need to rearrange the order of Allow or Deny filters, you can do so by performing a series of Delete and Add actions.

For a specification of filter syntax and a variety of examples, see Filter Syntax. For additional examples, see Filter Examples.

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 smtp, pop, imap, or http and filter follows the syntax rules described in Filter Syntax.

To create or edit deny filters for services:

configutil -o service.service.domainnotallowed -v filter

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

Creating Access Filters for HTTP Proxy Authentication

Any store administrator can proxy authenticate to any service. (For more information about store administrators, see Specifying Administrator Access to the Store.) For the HTTP service only, any user can proxy authenticate to the service if the user 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, Netscape offers an authentication SDK for Messenger Express.

This section describes how to create allow filters for HTTP proxy authentication. 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 Netscape representative.

To create access filters for proxy authentication to the HTTP service:

  1. In Netscape Console, open the Messaging Server that you want to create access filters for.
  2. Click the Configuration tab.
  3. Open the Services folder in the left pane and select HTTP beneath the Services folder.
  4. Click the Proxy tab in the right pane.
  5. The Allow field in the tab shows the existing Allow filters for proxy authentication.

  6. To create a new filter, click Add.
  7. An Allow filter window opens. Enter the text of the new filter into the window and click OK.

  8. To edit an existing filter, select the filter and click Edit.
  9. An Allow filter window opens. Edit the text of the filter display din the window, and click OK.

  10. To delete an existing filter, select a field from the Allow field, and click Delete.
  11. When you are finished making changes to the Proxy tab, click Save.
For more information about allow filter syntax, see Filter Syntax.

Command Line

You can also 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 Filter Syntax.


Interface Reference: Security and Access Control
This section describes the Netscape Console interface elements that allow you to configure security settings and access control for Messaging Server. See Managing Servers with Netscape Console for information on using Netscape Console to manage Messaging Server and other servers.


Encryption Tab
The Encryption tab allows you to enable SSL and to select the encryption ciphers that your Messaging Server uses for communication with clients.

For more information, see also Enabling SSL.

The Encryption tab has the following elements:

Enable SSL. Check this box to enable SSL on your server. All other SSL encryption options listed here become available to you only when you enable SSL by checking this box.

Cipher Family. When you enable SSL, you can choose the cipher families you want to use. Netscape currently supports two types of cipher families: RSA and FORTEZZA. The internal token supports only RSA. If you're using a FORTEZZA card, you'll see the FORTEZZA cipher family in this list. Select the cipher families you want to use.

Token. From the drop-down list, choose the token you want to use. If the key is stored in the local key database, choose internal (software). If the key is stored on an external device, such as a Smart Card, choose one of the device-based tokens.

Certificate. From the drop-down list, choose your server's certificate. If you're not sure about which certificate to use, view the Certificate Management dialog box for more information. To view the Certificate Management dialog box, from the Console menu, choose Certificate Management.

Cipher Preferences. Click this button to open a window that allows you to view or edit the cipher preferences you've enabled (see Cipher Preferences Window).

Standard Buttons

Save. Click this button to save any settings you have made in the Encryption tab.

Reset. Click this button to reset the tab to the previously-saved settings.


Cipher Preferences Window
The Cipher Preferences window allows you to view or edit cipher preferences. For more information about these ciphers, see About Ciphers.

SSL is enabled if one or more of these ciphers is checked and your server has an installed server certificate.

Note: Export versions of Netscape Messaging Server may not support all ciphers available on Domestic U.S. versions.


IMAP Access Tab
The IMAP Access tab allows you to control user access to the IMAP service.

For more information, see also:

The IMAP Access tab has the following elements:

Allow Filters

Allow. This field displays Allow filters--access-control rules that permit access to the IMAP service. Any IMAP client that matches any of the Allow filters in this field is allowed IMAP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking Edit or Delete.

Add. Click this button to open a window (see IMAP Allow Filter Window) that allows you to add a new Allow filter to the Allow field.

Edit. Click this button to open a window (see IMAP Allow Filter Window) that allows you to edit the Allow filter that is currently highlighted in the Allow field.

Delete. Click this button to delete the Allow filter that is currently highlighted in the Allow field.

Deny Filters

Deny. This field displays Deny filters--access-control rules that deny access to the IMAP service. Any IMAP client that matches any of the Deny filters in this field is denied IMAP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking either Edit or Delete.

Add. Click this button to open a window (see IMAP Deny Filter Window) that allows you to add a new Deny filter to the Deny field.

Edit. Click this button to open a window (see IMAP Deny Filter Window) that allows you to edit the Deny filter that is currently highlighted in the Deny field.

Delete. Click this button to delete the Deny filter that is currently highlighted in the Deny field.

Standard Buttons

Save. Click this button to save any settings you have made in the IMAP Access tab.

Reset. Click this button to reset the tab to the previously-saved settings.


IMAP Allow Filter Window
The IMAP Allow Filter window allows you to add or edit Allow filters, the rules by which clients are permitted to access the IMAP service.

For more information, see also:

The IMAP Allow Filter window has the following elements:

ALLOW filter. Use this field to enter a new IMAP Allow filter or edit the one currently being displayed. A typical Allow filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (imap in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the ALLOW filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of IMAP Allow filters unchanged.


IMAP Deny Filter Window
The IMAP Deny Filter window allows you to add or edit Deny filters, the rules by which clients are explicitly excluded from access to the IMAP service.

For more information, see also:

The IMAP Deny Filter window has the following elements:

DENY filter. Use this field to enter a new IMAP Deny filter or edit the one currently being displayed. A typical Deny filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be denied (imap in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be prevented from accessing the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the DENY filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of IMAP Deny filters unchanged.


POP Access Tab
The POP Access tab allows you to control user access to the POP service.

For more information, see also:

The POP Access tab has the following elements:

Allow Filters

Allow. This field displays Allow filters--access-control rules that permit access to the POP service. Any POP client that matches any of the Allow filters in this field is allowed POP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking either Edit or Delete.

Add. Click this button to open a window (see POP Allow Filter Window) that allows you to add a new Allow filter to the Allow field.

Edit. Click this button to open a window (see POP Allow Filter Window) that allows you to edit the Allow filter that is currently highlighted in the Allow field.

Delete. Click this button to delete the Allow filter that is currently highlighted in the Allow field.

Deny Filters

Deny. This field displays Deny filters--access-control rules that deny access to the POP service. Any POP client that matches any of the Deny filters in this field is denied POP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking either Edit or Delete.

Add. Click this button to open a window (see POP Deny Filter Window) that allows you to add a new Deny filter to the Deny field.

Edit. Click this button to open a window (see POP Deny Filter Window) that allows you to edit the Deny filter that is currently highlighted in the Deny field.

Delete. Click this button to delete the Deny filter that is currently highlighted in the Deny field.

Standard Buttons

Save. Click this button to save any settings you have made in the POP Access tab.

Reset. Click this button to reset the tab to the previously-saved settings.


POP Allow Filter Window
The POP Allow Filter window allows you to add or edit Allow filters, the rules by which clients are permitted to access the POP service.

For more information, see also:

The POP Allow Filter window has the following elements:

ALLOW filter. Use this field to enter a new POP Allow filter or edit the one currently being displayed. A typical Allow filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (in this case, pop), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the ALLOW filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of POP Allow filters unchanged.


POP Deny Filter Window
This window allows you to add or edit Deny filters, the rules by which clients are explicitly excluded from access to the POP service.

For more information, see also:

The POP Deny Filter window has the following elements:

DENY filter. Use this field to enter a new POP Deny filter or edit the one currently being displayed. A typical Deny filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be denied (in this case, pop), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be prevented from accessing the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the DENY filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of POP Deny filters unchanged.


HTTP Access Tab
The HTTP Access tab allows you to control user access to the HTTP service.

For more information, see also:

The HTTP Access tab has the following elements:

Allow Filters

Allow. This field displays Allow filters--access-control rules that permit access to the HTTP service. Any HTTP client that matches any of the Allow filters in this field is allowed HTTP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking Edit or Delete.

Add. Click this button to open a window (see HTTP Allow Filter Window) that allows you to add a new Allow filter to the Allow field.

Edit. Click this button to open a window (see HTTP Allow Filter Window) that allows you to edit the Allow filter that is currently highlighted in the Allow field.

Delete. Click this button to delete the Allow filter that is currently highlighted in the Allow field.

Deny Filters

Deny. This field displays Deny filters--access-control rules that deny access to the HTTP service. Any HTTP client that matches any of the Deny filters in this field is denied HTTP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking either Edit or Delete.

Add. Click this button to open a window (see HTTP Deny Filter Window) that allows you to add a new Deny filter to the Deny field.

Edit. Click this button to open a window (see HTTP Deny Filter Window) that allows you to edit the Deny filter that is currently highlighted in the Deny field.

Delete. Click this button to delete the Deny filter that is currently highlighted in the Deny field.

Standard Buttons

Save. Click this button to save any settings you have made in the HTTP Access tab.

Reset. Click this button to reset the tab to the previously-saved settings.


HTTP Allow Filter Window
The HTTP Allow Filter window allows you to add or edit Allow filters, the rules by which clients are permitted to access the HTTP service.

For more information, see also:

The HTTP Allow Filter window has the following elements:

ALLOW filter. Use this field to enter a new HTTP Allow filter or edit the one currently being displayed. A typical Allow filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (http in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the ALLOW filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of HTTP Allow filters unchanged.


HTTP Deny Filter Window
The HTTP Deny Filter window allows you to add or edit Deny filters, the rules by which clients are explicitly excluded from access to the HTTP service.

For more information, see also:

The HTTP Deny Filter window has the following elements:

DENY filter. Use this field to enter a new HTTP Deny filter or edit the one currently being displayed. A typical Deny filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be denied (http in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be prevented from accessing the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the DENY filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of HTTP Deny filters unchanged.


HTTP Proxy Tab
The HTTP Proxy tab allows you to enable the proxy authentication mechanism and to create allow filters for proxy authentication. (Proxy authentication allows other services, such as a portal site, to authenticate users and pass the authentication credentials to the Messenger Express login service.)

For more information, see also:

Allow Filters

Allow. This field displays Allow filters--access-control rules that permit access to the HTTP service. Any HTTP client that matches any of the Allow filters in this field is allowed HTTP access. You can edit the contents of this field by clicking the Add button, or by selecting a line in this field and then clicking Edit or Delete.

Add. Click this button to open a window (see HTTP Proxy Allow Filter Window) that allows you to add a new Allow filter to the Allow field.

Edit. Click this button to open a window (see HTTP Proxy Allow Filter Window) that allows you to edit the Allow filter that is currently highlighted in the Allow field.

Delete. Click this button to delete the Allow filter that is currently highlighted in the Allow field.


HTTP Proxy Allow Filter Window
The HTTP Proxy Allow Filter window allows you to add or edit Allow filters for HTTP proxy authentication.

For more information, see also:

The HTTP Proxy Allow Filter window has the following elements:

ALLOW filter. Use this field to enter a new HTTP Proxy Allow filter or edit the one currently being displayed. A typical Allow filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (http in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the Proxy ALLOW filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of HTTP Proxy Allow filters unchanged.


SMTP Access Tab
The SMTP Access tab allows you to control client access to the SMTP service.

For more information, see also:

The SMTP Access tab has the following elements:

Allow Filters

Allow. This field displays Allow filters--access control rules that permit access to the SMTP service. Any SMTP client that matches any of the Allow filters in this field is allowed SMTP access. You can edit the contents of this field by selecting a line in this field and then clicking one of the following three buttons.

Add. Click this button to open a window (see SMTP Allow Filter Window) that allows you to add a new Allow filter to the Allow field.

Edit. Click this button to open a window (see SMTP Allow Filter Window) that allows you to edit the Allow filter that is currently highlighted in the Allow field.

Delete. Click this button to delete the Allow filter that is currently highlighted in the Allow field.

Deny Filters

Deny. This field displays Deny filters--access control rules that deny access to the SMTP service. Any SMTP client that matches any of the Deny filters in this field is denied SMTP access. You can edit the contents of this field by selecting a line in this field and then clicking one of the following three buttons.

Add. Click this button to open a window (see SMTP Deny Filter Window) that allows you to add a new Deny filter to the Deny field.

Edit. Click this button to open a window (see SMTP Deny Filter Window) that allows you to edit the Deny filter that is currently highlighted in the Deny field.

Delete. Click this button to delete the Deny filter that is currently highlighted in the Deny field.

Standard Buttons

Save. Click this button to save any settings you have made in the SMTP Access tab.

Reset. Click this button to reset the tab to the previously-saved settings.


SMTP Allow Filter Window
The SMTP Allow Filter window allows you to add or edit Allow filters, the rules by which clients are permitted to access the SMTP service.

For more information, see also:

The SMTP Allow Filter window has the following elements:

Allow filter. Use this field to enter a new SMTP Allow filter or edit the one currently being displayed. A typical Allow filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (smtp in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the ALLOW filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of SMTP Allow filters unchanged.


SMTP Deny Filter Window
The SMTP Deny Filter window allows you to add or edit Deny filters, the rules by which clients are explicitly excluded from access to the SMTP service.

For more information, see also:

The SMTP Deny Filter window has the following elements:

Deny filter. Use this field to enter a new SMTP Deny filter or edit the one currently being displayed. A typical Deny filter has the format:

serviceSpec:clientSpec

where serviceSpec is generally the name of the service to be accessed (smtp in this case), and clientSpec is typically a host name, domain name, or wildcard name or pattern. Clients that match the information in clientSpec are to be allowed access to the service specified in serviceSpec.

Standard Buttons

OK. Click this button to save the entry or the edits you have made in the DENY filter field.

Cancel. Click this button to cancel the entry or edit, leaving the set of SMTP Deny filters unchanged.

 

© Copyright 1999 Netscape Communications Corp., a subsidiary of America Online, Inc. All rights reserved.