MailAllowedServiceAccess LDAP Attribute



 Syntax 

 directory string (UTF-8), single-valued 

 OID 

 2.16.840.1.113894.1009.1.101.0.1074.1.1 



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. </li>

</ul>

Note the effect of the preceding rule:

<ul>

 If no rule is specified for mailAllowedServiceAccess, users are    allowed access to all services from all clients. </li>

 If an allow filter is explicitly specified for any service, users    are denied access to all other services that are not specified. </li>

</ul>

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 configutil utility, see Configuring Client Access to POP, IMAP, and HTTP Services.

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:,  ,  ,  ,  ,  ,  ,  and. Note that the MMP supports,  ,  ,  , and  , and. The back-end supports,  ,  ,  , and.

client_list is a comma separated list of clients (domains) to which access is being granted or denied. The following wild cards can be used for the service list: &#x2a;, ALL. Wild cards can be substituted for the client list (domains). The following table shows the legal wild cards and gives a description of each:

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&#x27;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:&#x2a; 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:&#x2a; 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:&#x2a;$+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.