test

Sun Java System Messaging Server 6 2005Q4 Administration Guide

Configuring Client Access to POP, IMAP, and HTTP Services

This section contains the following subsections:

Messaging Server supports sophisticated access control on a service-by-service basis for its IMAP, POP, and HTTP services 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 unsolicited bulk email specifically, see also Chapter 17, Mail Filtering and Access Control

Note –

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 Mostly Allowing for instructions on setting it up.

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:

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

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 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 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.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 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:*

Wildcard Names

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

Table 19–3 Wildcard Names for Service Filters

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: 

Host names may be unavailable due to temporary DNS server problems—in which case all filters that use UNKNOWN will match all client hosts.

A network address is unavailable when the software cannot identify the type of network it is communicating with—in which case all filters that use UNKNOWN will match all client hosts on that network.

KNOWN

Matches any user whose name is known, or any host whose name and address are known.

Use this wildcard name carefully: 

Host names may be unavailable due to temporary DNS server problems—in which case all filters that use KNOWN will fail for all client hosts.

A network address is unavailable when the software cannot identify the type of network it is communicating with—in which case all filters that use KNOWN will fail for all client hosts on that network.

DNSSPOOFER

Matches any host whose DNS name does not match its own IP address. 

Wildcard Patterns

You can use the following patterns in service 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.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)

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.

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: .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.

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.

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

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 17, Mail Filtering and Access Control

ProcedureTo Create Filters

Steps

  1. In 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, or HTTP beneath the Services folder.

  4. Click the Access tab in the right pane.

    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:

    1. Click Add to create a new filter. An Allow Filter window or Deny filter window opens; enter the text of the new filter into the window, and click OK.

    2. Select a filter and click Edit to modify the filter. An Allow Filter window or Deny filter window opens; edit the text of the filter displayed in the window, and click OK.

    3. Select a filter and click Delete to remove the filter.

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

To Create 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 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.

ProcedureTo Create Access Filters for HTTP Proxy Authentication

Steps

  1. In 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.

    The Allow field in the tab shows the existing Allow filters for proxy authentication.

  5. To create a new filter, click Add.

    An Allow filter window opens. Enter the text of the new filter into the window and click OK.

  6. To edit an existing filter, select the filter and click Edit.

    An Allow filter window opens. Edit the text of the filter display in the window, and click OK.

  7. To delete an existing filter, select a field from the Allow field, and click Delete.

  8. 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.