You can control the way Exchange distributes mail to members of groups used as distribution lists. To start, select a mail-enabled group in Active Directory Users and Computers and open the Properties window. The Exchange General tab comes up first, as shown in Figure 5.10.
The Message Restrictions settings give you control over these and other situations. For example, let's say you have a group titled Corporate Executives that contains the accounts of, well, corporate executives. You probably don't want folks sending messages to this group saying, "This company really sucks!"
unless that person has been authorized to voice such an opinion.
You can set the Message Restrictions
so that only members of specified groups can send messages to
the Corporate Executives group.
If you don't want users from outside the company to send messages to a particular group, you can check the From Authenticated Users Only option. This prevents spammers from targeting a corporate distribution list on a public-facing Exchange server.
If a sender does not meet the Message Restrictions criteria, Exchange returns a Non-Delivery Report (NDR) stating that the sender does not have permission to send to this recipient.
Select the Exchange Advanced tab in the group's Properties window. Figure 5.11 shows an example. Use settings in this tab to hide groups from the GAL and to specify NDR handling.
You can help prevent users from sending inappropriate messages to a group by hiding the group from the GAL. You can still send messages to the group (or any mail-enabled object that has been hidden from the GAL) by entering the recipient's full SMTP address; for example, email@example.com.
Do not send delivery reports
If the system fails to deliver a message to one or more members of a group, you might want the sender to get an NDR. Exchange disables this option by default because it exposes the distribution lists to spammers and other unauthorized persons. If you send a message to a distribution list and get an NDR for each invalid address, you now have a clue about who is and isn't in the company, both a security violation and a privacy violation.
Administrative group affiliation
Groups do not have mailboxes, so it might surprise you to see that a group has an Administrative Group associated with it. Exchange uses this Administrative Group to build an X.400 proxy address for mail-enabled objects. This is true even if the organization has been shifted to Exchange Native mode.
If you do not use X.400 connectors, then this requirement doesn't have an impact on production. If you do use X.400 connectors, then be sure to affiliate a mail-enabled group with the correct Administrative Group, so that messages sent to the group get routed correctly through the connector.
Hiding group members
When you mail-enable a group, you expose the group's membership list to MAPI clients. An Outlook user can open the GAL, right-click a group, and select Properties to see the group members, as shown in Figure 5.12.
You might not want Outlook users to see a group's membership because of privacy concerns for the members or because the Windows administrators don't want to expose the contents of mail-enabled Security groups.
You can hide the group membership using the Exchange Tasks Wizard for the group. Right-click the group in Active Directory Users and Computers, select Exchange Tasks from the flyout menu, then select Hide Membership in the Exchange Task Wizard, as shown in Figure 5.13.
Hiding group membership requires some fancy footwork on the part of Exchange. Here's why.
An Active Directory group object has an attribute called Member that holds the list of accounts that belong to the group. If you want to block all Outlook users from seeing the group's membership, Exchange must set a Deny Read permission on the Member attribute for the Everyone group.
But it's not that simple. An Exchange server needs to see the Member attribute so it can send email to the members. That means Exchange can't simply deny access to the Everyone group, because Everyone includes the Exchange server's account.
Exchange solves this problem by changing the sort order for the Access Control List entries on a group object with hidden membership. You can see this for yourself. Use the Exchange Task Wizard to hide the membership of a group; then open the Properties window for that group in Active Directory Users and Computer, and select the Security tab. You'll get a warning that the contents can't be modified. Acknowledge the warning and proceed.
Click Advanced to view the Advanced view of the Security tab, as shown in Figure 5.14. This view shows the access control entries in the order that the operating system evaluates them when determining access authorization. Each line corresponds to an access control entry (ACE), which contains the SID of a user or group and the permissions assigned to that SID. (The interface communicates with a Global Catalog server to replace the bare SIDs with their friendly names.)
You'll see that Exchange played a little shell game with the access list. It did indeed give the Everyone group a Deny Read on the Member attribute, but it also put an Allow Read on the same attribute for the Exchange Domain Servers group, the Domain Admins group, and the Account Operators group.
The security subsystem in Windows evaluates access control entries in the order you see them in the ACL Editor. Because the security subsystem encounters the Allow Read assigned to an Exchange server before it encounters the Deny Read assigned to the Everyone group, it gives the Exchange server access to the Member attribute while blocking users and other computers.
This is called non-canonical sorting. As shown in Figure 5.14, you can recognize non-canonical sorting when you see a Deny ACE placed below Allow ACEs in the same level of the hierarchy.
Because the ACL Editor always enforces canonical sorting when changing security settings, don't use the Security tab in the Properties page of a group to change the permission settings if the group has been configured to have hidden membership in Exchange.
15 tips in 15 minutes: Managing recipients and distribution lists
Tip 1: Exchange security groups
Tip 2: Group membership expansion
Tip 3: Managing Exchange group email properties
Tip 4: Exchange 2003 Query-Based Distribution Groups
Tip 5: DSAccess for Exchange
Tip 6: DSProxy for Exchange
Tip 7: Managing Exchange recipient policies
Tip 8: Exchange Recipient Update Service and proxy addresses
Tip 9: Restricting mail storage on an Exchange server
Tip 10: The Exchange server mailbox management service
Tip 11: Blocking a user's email access
Tip 12: Accessing another user's mailbox in Outlook
Tip 13: Exchange mail retention
Tip 14: Managing recipients with system policies
Tip 15: Managing recipients with Global Settings
This chapter excerpt from Learning Exchange Server 2003 by William Boswell is printed with permission from Addison-Wesley Professional, Copyright 2004. Click here for the chapter download or to purchase the book.