mailAllowedServiceAccess

Origin

Messaging Server 5.0

Syntax

cis, single-valued

Object Classes

inetMailUser

Definition

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.3 Administration Guide.

Rule Syntax

"+" 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.

Except Operator

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.

Example

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.

The following example shows how to restrict user access to SSL-encrypted POP and IMAP access only:

mailAllowedServiceAccess: +imaps,pops:*$+imap,pop:MMP IP address

In the preceding example, note that the back-end servers do not recognize the pops and imaps service names, so it is necessary to grant the MMP IP address(es) pop and imap service access. Otherwise, connections for that user between the MMP and the back-end servers will be rejected.

OID

2.16.840.1.113730.3.1.777