TCP wrapper filter syntax

TCP wrapper 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 and host addresses. Both the server and client information can include wildcard names or patterns.

The general syntax of an access filter rule is: &#x3c; "+" &#x7c; "-" &#x3e; service-list: client-list where multiple rules can be placed on the same line, separated by the  character, and where



 (allow filter)1 means the services in the   are being granted to the  ; 

 (deny filter)1 means the services are being denied to the  ; 

   is a comma separated list of services to which access is being granted or denied; 

   is a comma separated list of the clients to be allowed or denied access to the  . 



In more detail,   is a comma or space separated list of  s.   A   consists of simply a defined  , or    ,  or  the special wildcard name , or may make use of combinations of the above with the   operator. Defined service names are,  ,   ,  ,  ,  ,  ,  , and as of MS 7.0.5   .2. See TCP wrapper filter wildcard patterns for more details on host-patterns, and TCP wrapper filter EXCEPT operator for further details on the  operator.

 is a comma or space separated list of  s.  A    consists of any of a specific  , a  ,    , or in the above forms may make use of the wildcard names described in Wildcard names for TCP wrapper service filters, and optionally the TCP wrapper filter   operator.

The very simplest form of a filter is: service: host-specification where   is the name of the service (such as,   ,  , or  )   and   is the host name, IPv4 address, or  wildcard name  or  wildcard pattern that represents the client requesting access. When a TCP wrapper filter is processed, if the client seeking access matches  , access is either  allowed or denied (depending on which type of filter this is) to the service specified by  . 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, see  TCP wrapper filter wildcard names.)

Or for a more complex example, making use of a host name in a   and a user name in a  : 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 TCP wrapper filter server-host specification  and Client User-Name Specification.

When a TCP wrapper filter is processed, if the client seeking access matches any of the   entries in   ,  then access is either allowed or denied (depending on which type of filter this is) to all the services specified in  . 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 TCP wrapper filter wildcard  patterns.

The following example enables multiple services on all clients. +imap,pop,http:&#x2a; The following example shows multiple rules with the  rule separator, 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:&#x2a;$-pop:&#x2a;$-http:&#x2a; The following example shows how to restrict user access so that only SSL-encrypted POP and IMAP are permitted. Because back-end servers do not recognize the  and   service names,2 it is necessary to grant the MMP IP address(es)   and   service access; otherwise, connections between the MMP and the back-end servers will be rejected. +imaps,pops:&#x2a;$+imap,pop:MMP-IP-address(es) 1Note that use of " " and " " in access filters makes sense in values of LDAP attributes such as   or for components such that MMP which set a general access filter via a    option; but for components such as the IMAP and POP servers which separately specify Allow and Deny filters  (  and    options), the explicit " " and " " are not needed.

2Note that the MMP supports service names,  ,   ,  , and  , and. The back-end (Message Store) system (with its servers such as IMAP and POP) supports,  ,  ,   , and.

See also:
 * TCP wrapper filter wildcard names
 * TCP wrapper filter wildcard patterns
 * TCP wrapper filter EXCEPT operator
 * TCP wrapper filter server-host specification
 * tcpaccess Option
 * domainallowed Option
 * domainnotallowed Option
 * altservice Option
 * TCP wrappers