Personal Distribution List Considerations

Microsoft designed personal distribution lists (DLs) to let users create groups of email correspondents whom they send messages to often. Another type of DL is a system or shared DL, which resides in the Exchange Server Directory Store for use by many users. Because users create and manage personal DLs as their personal data, do administrators need to be concerned about DLs? The answer depends on how well trained your users are and whether they understand the effect of list abuse.

No version of Exchange lets users create shared or system DLs. To set up a system DL, an administrator must use the Microsoft Exchange Administrator program to create the list and then pass the DL over to a user, who becomes the group administrator and maintains group membership. Only users who hold administrative permissions for the site where the list resides can modify membership; administrators can manage the list's membership through Exchange Administrator. Screen 1 shows the membership of a system DL as it appears in the Global Address List (GAL).

Users store their personal DLs in a contacts folder in Outlook 2000 or in their Personal Address Book (PAB) in earlier Outlook versions or the original Exchange client. Screen 2 shows a typical personal DL stored in a contact folder. The contact folder can be personal or shared in a public folder. Administrators have no control over these personal DLs and no way to find out how many personal DLs are actively in use on a system.

The biggest difference between personal and system DLs is the way that Exchange builds message headers. A system DL consists of a set of backward pointers to the mailbox, custom recipient, and DL objects that make up the list. When the Exchange Message Transfer Agent (MTA) resolves list membership, it consults the Exchange Directory Store and expands the set of pointers to find the recipients that it must deliver a message to. The MTA uses this information to decide how to route messages to recipients along the most efficient path. However, Exchange doesn't insert the member information into the message header, so if you examine the header, you see only the name of the list.

Exchange doesn't store personal DLs in the Directory Store, so Exchange must extract the individual recipient names and store them in the message header before it sends the message. This behavior has two side effects. First, expanding list membership and adding recipients to the header takes time, so messages addressed to personal DLs take longer for Exchange to send from Outlook than messages addressed to system DLs. Second, the size of the data in the message header is larger because Exchange must maintain a separate To, Cc, or Bcc property for each recipient. Each recipient address requires approximately 500 bytes in the header. For example, a simple message addressed to a system DL with eight members might take 1KB, whereas the same message addressed to a personal DL might require 5KB. The difference between 1KB and 5KB isn't large, but when personal DLs hold hundreds of entries, each message must transport a large amount of header information. In these situations, system DLs are much more economical. However, systems administrators usually don't know that people are using large lists until problems occur.

DL-Related Problems
Chain letters are an obvious example of a problem that can occur with personal DLs. Despite administrators' and managers' warnings to users about abusing corporate resources, users persist in sending chain mail. From an administrative perspective, the problem is twofold. Messages are often large, perhaps 200KB or more, depending on the number of recipients in the list, so transmitting, storing, and delivering the messages places strain on servers. When the messages arrive, many users react with considerable annoyance and use the Reply to all option to share their opinion with all concerned. This behavior can lead to a reply frenzy—many users reply to the original message or the replies that it generates. Each reply is larger than the original message, so you end up with increasingly larger messages flooding the network. All an administrator can do is try to track down the original sender, ask that user to stop sending chain mail, and then convince everyone else that replying to such messages isn't very intelligent either.

Changing email addresses poses an additional challenge for personal DLs. You can adjust system-generated addresses automatically if the need arises, such as when you use the Move Server Wizard to move a system into a new Exchange organization or site or when you change a company's basic email address as a result of a rebranding exercise, corporate amalgamation, or divestiture. The same problem arises if users decide to change their email address because you can't find out what lists the address is in so you can update them. Personal data (e.g., contacts, PABs, DLs) is the user's responsibility; administrative tools aren't available to update addresses automatically. Unfortunately, users frequently believe that because administrators changed the email address, the administrators must make sure that the email addresses continue to work afterward. These circumstances generate a great deal of angst in Help desk calls.

Generally, I prefer to avoid personal DLs as much as possible. They're excellent tools when things go right, but a real pain when anything goes awry. Keep in mind that the more mailboxes a server supports, the more work you need to do if email addresses change. If you need to change email addresses for any reason, make sure that your project plan incorporates time to work out how to support your users' personal data.