The directory service stores and manages distribution lists as group entries. Each group entry is composed of attributes, for example, distribution list name, members, and so on. For example, imagine that the widget team of the Alpha Corporation is composed of the following users with associated email addresses:
|
|
Jane: jane@eng.alpha.com |
|
|
Bernie: bernie@eng.alpha.com |
|
|
Kevin: kevin@eng.alpha.com |
|
|
Amy: amy@eng.alpha.com |
|
|
Frank: frank@eng.alpha.com |
You can configure a distribution list composed of each widget team member's email address along with the associated email address widget@eng.alpha.com. In addition to distribution list members, you must also configure a distribution list owner. An owner is an individual who is responsible for the distribution list. An owner can add or delete distribution list members.
You can optionally configure a distribution list moderator. A moderator is an individual, usually the distribution list owner, who initially receives a message addressed to a distribution list. Upon receipt of a message, the moderator can forward the message to the distribution list, edit the message and then forward it, or not forward the message.
You can specify distribution list Access Control, i.e., what domains and users can or cannot distribute mail to the group. By default, if a moderator is created, only the moderator can send mail to the group and all other submissions go to the moderator. If no moderator is specified, then anyone can send mail to all the group members.
The Send Error Conditions To field enables you to specify an individual to receive a message if an error condition with a distribution list arises. An example of an error condition is when a message addressed to the distribution list cannot be delivered. Upon receipt of one of these messages, it is the specified individual's responsibility to notify the email administrator about the error. (You can specify the email administrator as the recipient of these messages.)
The Send Request Messages To field enables you to specify an individual to receive messages containing requests to be added as a distribution list member. Upon receipt of one of these message, it is the specified individual's responsibility to notify the email administrator about adding the requestor as a distribution list member. Requests are sent to <list name>_request@domain. (As with the Send Error Conditions To field, you can specify the email administrator as the recipient of these messages.)
If you don't configure the Send Error Conditions To and Send Request Messages To fields, then by default, the individual who is configured as the owner of the distribution list will receive the respective messages.
For details on group entry fields, see "Group Entries" on page 32. For information on configuring group entries, see "To Modify a Group Entry" on page 82.
The Internet Message Transfer Agent (IMTA) retrieves the group entry attributes from the directory service (via the IMTA-directory cache) when it processes a distribution list. The distribution list process is composed of the following phases:
| 1. | Routing if necessary | |
| 2. | Address processing | |
| 3. | Message expansion | |
| 4. | Routing or delivery |
Imagine that Alpha Corporation employee Steve, who is in the finance department, sends a message to distribution list widget@eng.alpha.com. The widget distribution list is composed of a group of fellow Alpha Corporation employees, who develop widgets in the engineering department.
The first phase in the distribution list process applies only to email systems that contain multiple mail servers and therefore IMTAs. If your email system has only one IMTA, then this phase does not apply. The IMTA that accepts Steve's message determines if the distribution list widget@eng.alpha.com is stored as a group entry on this particular mail server. If not, the IMTA checks its data base to determine which IMTA in the email system stores this particular group entry. If the IMTA finds this information in its data base, the message is routed to the appropriate IMTA. If the IMTA does not find the information in its data base, the message is routed to the IMTA configured as the router or smart host in that particular domain. Once the message is accepted by the mail server that stores the group entry for widget@eng.alpha.com, the IMTA processes each distribution list member's address (rewrite rules, access control, and so on).
The IMTA then expands the message or converts the message into enough copies for each distribution list member. Rather than converting the message into one copy per distribution list member, the IMTA converts the message into one copy per IMTA channel that will deliver or route the message to a distribution list member. For example, if two distribution list members have mailboxes in /var/mail and two in the Sun Message Store, the IMTA will convert the message into two copies: one for the /var/mail channel and one for the Sun Message Store channel.
The IMTA then places a copy of the message in the queue of each IMTA channel that will deliver or route the message to a distribution list member.
The Sun Internet Mail Server - Enterprise Edition supports a distribution list access control feature. If you do not implement the access control feature, any email user who knows the email address can send messages to a particular distribution list.
The access control feature enables you to configure who can send messages to a particular distribution list, thereby controlling the quantity of messages as well as the quality of information that can be sent to a distribution list. You can control access to a distribution list in the following ways:
|
|
Submitter - You can specify a list of submitters (users or groups) who are authorized to send messages to a particular distribution list and/or a list of submitters (users or groups) who are unauthorized. |
|
|
Domain - Specify a list of domains authorized to send messages to a particular distribution list and/or a list of domains that are unauthorized to send messages to a particular distribution list. |
You can specify submitters who are within the email system that you are configuring or in a different email system. The four possible configured access control lists are examined in the following order:
| 1. | Unauthorized submitter list | |
| 2. | Authorized submitter list | |
| 3. | Unauthorized domain list | |
| 4. | Authorized domain list |
FIGURE 1-3 presents the access control process visually.
FIGURE 1-3 Distribution List Access Control Process since SIMS 3.5
If a conflict arises between your configured unauthorized or authorized access control lists, the restriction configured in the submitter list will take precedence over the restriction configured in the domain list. For example, imagine that submitter steve@finance.alpha.com attempts to send a message to the distribution list widget@eng.alpha.com. If the domain finance.alpha.com is on the unauthorized domain list but user Steve is on the authorized submitter list, then the message will be delivered because of the precedence of the submitter lists over the domain lists.
TABLE 1-3 contains various ways that you may want to use the distribution list access control feature and the suggested way to achieve the desired results.
TABLE 1-3 Implementing Distribution List Access Control Feature
* Although each restriction/allowance outlined in this table can be handled in multiple ways, the documented suggested methods are the most efficient and require the least impact on performance. For example, you can restrict all submitters from a particular domain from sending messages by entering the unwanted domain on the unauthorized domain list or by not including the unwanted domain on the authorized list and having other authorized entries. However, if you restrict this domain by the latter method, the mail server has to go through two steps in the distribution list process rather than one. Therefore, the latter method is not suggested.