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.