Delegate access refers to the user's ability to send a message as another user or receive a message for another user. Delegate access is a service provider-independent feature of MAPI that transport providers can support if they choose. However, no provider is required to do so. Delegate access is valuable when it is necessary for a user to send messages as, or filter incoming messages for, another user or when a user must access another user's message store. Before allowing a delegate user to connect to another user's store, the message store provider must verify that the delegate user has the proper authority.
There are two groups of properties that are used to support delegate access:
PR_SENT_REPRESENTING_EMAIL_ADDRESS
PR_SENT_REPRESENTING_SEARCH_KEY
PR_RCVD_REPRESENTING_EMAIL_ADDRESS
PR_RCVD_REPRESENTING_SEARCH_KEY
On outgoing messages, the PR_SENT_REPRESENTING properties identify the messaging user that should act as the sender. Clients can set these properties as an option. If the PR_SENT_REPRESENTING properties are not set by the time the message reaches a transport provider that supports delegate access, it is the provider's responsibility to set them along with the PR_SENDER properties.
On incoming messages, the PR_RCVD_REPRESENTING properties identify the user that should act as the recipient. Transport providers responsible for delivering delegate messages must set both the PR_RCVD_REPRESENTING and PR_RECEIVED_BY properties. Clients receiving a delegate message should copy the values of the PR_SENT_REPRESENTING properties to the corresponding PR_RCVD_REPRESENTING properties.
For example, suppose John is receiving Sally's messages while Sally is on vacation. The PR_RCVD_REPRESENTING properties identify John as the delegate recipient. When John sends a reply to a message that he has received for Sally, the message's PR_SENDER properties identify John as the sender. Because John is representing Sally, the PR_SENT_REPRESENTING properties identify Sally.
Transport providers handling incoming delegate messages should usually deliver these messages as the messaging user identified by the PR_SENT_REPRESENTING properties rather than as the user identified by the PR_SENDER properties. The exception to this rule is when it is necessary to match access privilege and transport types. In this case, a transport provider can choose a sending identity.
If the PR_SENT_REPRESENTING properties are unavailable for an incoming delegate message, the transport provider handling delivery must set them, using the values of the corresponding PR_SENDER properties. If the PR_SENT_REPRESENTING properties are available but the transport provider does not support delegate access, it can use the PR_SENDER properties for delivery.