This section contains the following subsections:
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 220.127.116.11 Mostly Allowing for instructions on setting it up.
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.
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:
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 18.104.22.168 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:
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: firstname.lastname@example.org
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 22.214.171.124 Server-Host Specification and 126.96.36.199 Client User-Name Specification
Finally, at its most general, a filter has the form:
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 188.8.131.52 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.
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.)
An example of how to disallow all services for a user is:
You can use the following wildcard names to represent service names, host names or addresses, or user names:Table 23–3 Wildcard Names for Service Filters
The universal wildcard. Matches all names.
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.
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.
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.
Matches any host whose DNS name does not match its own IP address.
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 184.108.40.206.
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 220.127.116.11/255.255.255.128 matches every address in the range 18.104.22.168 through 22.214.171.124.
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)
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:
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.
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:
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.
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.
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:
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.
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.
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:
This filter denies all services to all remote hosts whose IP addresses don’t match their DNS host names.
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:
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.
If you wish to allow users to access Webmail, but not access IMAP, create a filter like this:
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.
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
Command Line. You can also specify access and deny filters at the command line as follows:
To create or edit access filters for services:
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
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.
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.