23.7.2 Filter Syntax

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

The very simplest form of a filter is:

service: hostSpec

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

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

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

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

serviceSpec: clientSpec

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

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

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

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

serviceList: clientList

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

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

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

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

You can also use the following syntax:

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

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

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

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

$ separates rules.

This example enables multiple services on all clients.

+imap,pop,http:*

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

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

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

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

23.7.2.1 Wildcard Names

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

Table 23–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.

23.7.2.2 Wildcard Patterns

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

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

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

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

23.7.2.3 EXCEPT Operator

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

list1 EXCEPT list2

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

Here is an example:

ALL: ALL EXCEPT isserver.siroe.com

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

EXCEPT clauses can be nested. The expression:

list1 EXCEPT list2 EXCEPT list3

is evaluated as if it were:

list1 EXCEPT (list2 EXCEPT list3)

23.7.2.4 Server-Host Specification

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

service@hostSpec

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

23.7.2.5 Client User-Name Specification

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

user@hostSpec

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

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

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

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

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

  serviceList: @xyzcorp.com ALL@ALL

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

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