Distribution lists
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Distribution lists
Message Queuing 3.0 allows sending applications to send a single message to a list of destination queues. That list can be constructed dynamically in the form of a multiple-element format name or can be published and kept in Active Directory in the form of a distribution list. For more information on multiple-element format names, see Multiple-element format names.
A distribution list is a set of target queues and/or distribution lists that can be used to do the following:
Send transactional and nontransactional messages to multiple destinations.
Specify one or more administration queues for sending application-generated acknowledgment messages, when acknowledgment messages are requested.
Specify one or more response queues for sending application-generated response messages, when response messages are requested.
Distribution lists and Active Directory
Distribution lists are public lists that are published as distribution group objects in Active Directory. For more information, see Message Queuing objects. The explicit members of a distribution list must be destinations published in Active Directory; that is, public queues, queue aliases, and other distribution lists. Private queues and URL-named queues cannot be elements of a distribution list.
Private queues and URL-named queues, however, can be referenced indirectly in a distribution list through queue aliases. Queue aliases provide additional benefits when they are used in distribution lists. When a queue alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias. A queue referenced by a queue alias can be modified without having to change a distribution list that references it. For more information on queue aliases, see Queue aliases.
Since distribution lists are objects in Active Directory, they cannot be used in workgroup or offline mode, in which there is no access to Active Directory. In these modes, messages can be sent to multiple destinations by using multiple-element format names, provided they do not contain an element that points to a public queue or a distribution list.
Distribution list security
Because distribution lists are objects in Active Directory, security attributes can be attached to control access to them, and their properties can be queried in Active Directory. In addition, they support encryption similar to queues. Each copy of a message can be encrypted using the public key of the destination computer for that copy.
A security descriptor is assigned to each queue and distribution list. This security descriptor lists the users and groups that are granted or denied access to the queue or distribution list, and the specific permissions assigned to those users and groups. The following specific permissions are associated with distribution lists:
Send To permission. Allows a group or user to send messages to the applicable distribution list. By default, this permission is granted to everyone.
Add/Remove Self as Member permission for a public queue or queue alias. Allows a group or user to add or remove the applicable public queue or queue alias as a member in a distribution list. All users are granted this permission by default.
Add/Remove Self as Member permission for a distribution list. Allows a group or user to add or remove the applicable distribution list as a member in another distribution list. Only the owner of a distribution list has the Add/Remove Self as Member permission for it.
When a queue or distribution list member is added to a distribution list, the set of users with the Send To permission for the distribution list containing the new member is not altered. Thus, in particular, when a distribution list with more restricted access is added to a distribution list with less restricted access, it becomes possible for clients of the expanded distribution list to access the new distribution list with more restricted access. This does not create a security risk because each distribution list can still control the set of users allowed to add members to it.
When a message is sent to a distribution list, Message Queuing verifies that the sender has the Send To permission to each of the top-level members (queues or distribution lists) in the distribution list. This is a compromise for achieving network traffic optimization. When a message is received, Message Queuing verifies that the sender has the Send To permission to the top-level members and to the destination queue itself.
To achieve security in sending operations, member containment in a distribution list is defined to be bidirectional: a member references its container and the container references its members. To respect the security restrictions on members, a member cannot be added to a member of a distribution list without permission from that member and its prospective container. In other words, both the container and the member must agree. For example, if a user wants to insert distribution list DL2 into DL1, the user must have the Add/Remove-Element permission for DL1 and the Add/Remove-Container permission for DL2. However, for the user to remove DL2 from DL1, only one of these permissions is required.
You can use Active Directory Users and Computers to create and delete distribution lists as distribution group objects, to add and delete members, and to view their properties. For more information on performing these tasks, see Create distribution lists, Delete distribution lists, and View, add, or delete elements in a distribution list.
Distribution lists can be referenced programmatically through distribution list format names. For more information on using distribution list format names and their syntax, refer to the Message Queuing Software Development Kit (SDK).
Distribution list scope
Distribution lists can be domain-scoped, global, or universal:
Universal. Members of universal groups can include other groups and accounts from any domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.
Global. Members of global groups can include other groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest. Thus, distribution lists with global scope can include queues and distribution lists from the local domain, and queues and global distribution lists from other domains in the forest. They can be moved to another domain.
Domain-scoped. Members of domain local groups can include other groups and accounts from Windows Server 2003, Windows 2000, or Windows NT domains and can be granted permissions only within a domain. Thus domain-scoped distribution lists can only contain queues and distribution lists from the local domain as members, and cannot be moved to another domain.
Sending messages to distribution lists
When a message is sent to a distribution list, Active Directory is queried to ascertain its members and to translate any queue aliases into queues. Thus, the distribution list is expanded to a list of target queues. Distribution list members can be added or removed dynamically during the expansion process. Then a copy of the message with the same message ID is sent to each of those queues. If a distribution list contains multiple references to the same destination, duplicate references are ignored when the destinations are opened for sending messages. For example, if the members of distribution list D1 include queue Q1 and another distribution list D2, it may turn out that D2 also contains Q1 or D1. If this is the case, the second reference to Q1 or D1 is ignored. Thus, recursive cycles specified by distribution lists containing other distribution lists are broken.
Distribution lists may reference a mixture of transactional and nontransactional target queues. When a nontransactional message is sent to such a mixture of targets, the message is allowed to be sent to all the transactional and nontransactional target queues on the local or a remote computer. However, when the nontransactional message reaches a transactional queue, it is rejected and transferred to the nontransactional dead-letter queue on the computer hosting the transactional queue for storage, and a negative acknowledgement message indicating that a nontransactional message was sent to a transactional queue is sent to the administration queue specified in the original message.
Sending transactional messages to distribution lists
Message Queuing guarantees that all messages sent within a transaction will arrive exactly once and in the order in which they were sent. Message Queuing also guarantees that all messages sent in consecutive transactions from a given computer to the same destination queue will also arrive exactly once and in the order in which they were sent. This means that the messages sent within the first transaction will arrive before those sent within a subsequent transaction.
These transactional semantics are also supported for distribution lists. Messages sent to the same distribution list within a transaction will be delivered to the distribution list exactly once and in the order in which they were sent. In addition, messages sent within multiple transactions from the same source computer to the same distribution list will be delivered to the distribution list exactly once and in the order in which they were sent. Thus, the delivery of transactional messages to distribution lists and to queues is identical.
This equivalence, however, does not extend to the queues referenced by distribution lists. There is no guarantee of in-order delivery to a queue for transactional messages sent to different distribution lists, even if they contain the same elements (queues). Nevertheless, the messages will be delivered exactly once. In the case of delivery failures, Message Queuing places the original message with an indication of the first failed delivery in the source computer's transactional dead-letter queue.
Consider the following examples:
Example: In-order delivery to the same distribution list:
Distribution list DL1 = Queue Q1
Send message M1 to DL1
Send message M2 to DL1
In this case, Message Queuing guarantees both in-order and exactly-once delivery.
Example: Out of order delivery to different distribution lists:
Distribution list DL1 = Queue Q1
Distribution list DL2 = Queue Q1
Send message M1 to DL1
Send message M2 to DL2
In this case, even though both distribution lists contain the same elements, messages to Q1 will not necessarily arrive in-order to Q1. However, exactly-once delivery is guaranteed, so that M1 and M2 will arrive once and only once.
In contrast, using multiple-element format names can provide this in-order guarantee for messages sent to different distribution lists, since each message sent to a multiple-element format name containing a list of target queues. For more information, see Multiple-element format names.
Dynamic distribution lists and transactions
Because distribution lists are dynamic, recipients can be added while transactional messages are in transit. Such new recipients will start to receive transactional messages on the next appropriate transaction boundary. Only messages sent after a new queue joins a distribution list will reach the new member.
Distribution list acknowledgements
When a message is sent to a distribution list, potentially a set of different acknowledgements can be generated, since some target queues might receive the message successfully, while others may not. A sender should expect at least n acknowledgment messages for a message sent to a distribution list with n ultimate recipients when acknowledgment messages are requested. More than n acknowledgment messages should be expected when a single message generates a positive acknowledgment message upon arrival at its destination and a positive or negative read acknowledgment message. Note that all distribution lists and embedded distribution lists are expanded and duplicate recipients are eliminated before any messages are sent. However, to optimize message traffic, acknowledgment messages of the same class and generated for the same original message are combined into a single acknowledgment message containing a list of the queue GUIDs that acknowledged the message.