Messaging Server 5.0
cis, single-valued
Stores access filters (rules). If no rules are specified, then user is allowed access to all services from all clients. Rules are separated by a dollar sign ($). The rules are evaluated in this manner:
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 is made with any allow or deny filters, access is granted, except in the case where there are allow filters but no deny filters. In this case, a lack of match means access is denied.
Note the effect of the preceding rule:
If no rule is specified for mailAllowedServiceAccess, users are allowed access to all services from all clients.
If an allow filter is explicitly specified for any service, users are denied access to all other services that are not specified.
For example, suppose you want to enable S/MIME for a domain. If you do not specify any allow filters or deny filters for mailAllowedServiceAccess, S/MIME is enabled.
Now suppose you specify an allow filter for the pop service. In this case, S/MIME is disabled until you also specify an allow filter for the smime service.
For a full explanation of access filters and an alternate way to control access through the administration console or the config utility, see “Configuring Client Access to POP, IMAP, and HTTP Services” in the Sun Java System Messaging Server 6 2005Q4 Administration Guide.
"+" or "-"service_list":"client_list
+ (allow filter) means the services in the service list are being granted to the client list.
- (deny filter) means the services are being denied to the client list.
service_list is a comma separated list of services to which access is being granted or denied.
Legal service names are: imap, imaps, pop, pops, smtp, smtps, http, and smime. Note that the MMP supports imap, imaps, pop, pops, and smtp, and smime. The back-end supports imap, pop, smtp, http, and smime.
client_list is a comma separated list of clients (domains) to which access is being granted or denied.
Wild cards can be substituted for the client list (domains). The following table shows the legal wild cards and gives a description of each:
Table 3–10 Wild cards
Wild cards |
Description |
---|---|
ALL, * |
The universal wild card. Matches all names. |
DNSSPOOFER |
Matches any host whose DNS name does not match its own IP address. |
KNOWN |
Matches any host whose name and address are known. Use with care. |
LOCAL |
Matches any local host (one whose name does not contain a dot character). If your installation uses only canonical names, even local host names will contain dots and thus will not match this wild card. |
UNKNOWN |
Matches any host whose name or address are unknown. Use this with care. |
The following wild cards can be used for the service list: *, ALL.
The access control system supports a single operator, EXCEPT. You can use the EXCEPT operator to create exceptions to the patterns found in a rule’s service list and client list. EXCEPT clauses can be nested. If there are multiple EXCEPT clauses in a rule, they are evaluated right to left.
The EXCEPT format is:
list1 EXCEPT list2
where list1 is a comma separated list of services and list2 is a comma separated lists of clients.
This example shows a single rule with multiple services and a single wild card for the client list.
mailAllowedServiceAccess: +imap,pop,http:*
This example shows multiple rules, but each rule is simplified to have only one service name and uses wild cards for the client list. (This is the most commonly used method of specifying access control in LDIF files.)
mailAllowedServiceAccess: +imap:ALL$+pop:ALL$+http:ALL
An example of how to disallow all services for a user is:
mailAllowedServiceAccess: -imap:*$-pop:*$-http:*
An example of a rule with an EXCEPT operator is:
mailAllowedServiceAccess: -ALL:ALL EXCEPT server1.sesta.com
This example denies access to all services for all clients except those on the host machine server1.sesta.com.
2.16.840.1.113730.3.1.777