Delegation is a hodgepodge of several different bits of functionality.
The big picture idea is "someone else deals with your mail or
calendar, or you deal with theirs".


When you make someone a delegate in Outlook, the dialog lets you do a
bunch of things:

	* You can edit their permissions on all of your folders in
	  one easy place

	* If you give them "Editor" permission on your Calendar,
	  you can cause them to also get copies of your meeting
	  requests.

	* If you make at least one person get copies of your
	  meeting requests, you can make yourself not get them any
	  more.

	* You can make it possible (on a per-delegate basis) for
	  your delegates to be able to see "Private" appointments,
	  contacts, and tasks in your folders. (Normally other
	  people can't see your Private items regardless of what
	  permissions you give them.)

	* Your delegate automatically becomes able to send mail from
          your address. Outlook doesn't actually allow you do
          enable/disable this functionality independently of calling
          someone a delegate, although it's possible to do so.


Different pieces of this information are stored in different places:

	1. Permissions information is stored in the security
	   descriptors of the relevant folders. Outlook always adds
	   the user to each of the delegatable folders (Inbox,
	   Calendar, Contacts, Journal, Notes, and Tasks) even if they
	   only have "None" permission there. The user is also added
	   to the SD of the "Freebusy Data" folder in the non-IPM
	   subtree, with None or Reviewer permission if they have None
	   or Reviewer on Calendar, and Editor permission if they have
	   Author or Editor on Calendar.

	2. Who-can-send-mail-as-who data is kept in Active Directory.
           Your delegates are stored in the multivalued
           publicDelegates property on your AD entry. When you modify
           that property, AD automatically maintains back links in
           other entries' publicDelegatesBL properties. (Thus, by
           checking your own publicDelegatesBL property, you can find
           out who you are a delegate for.)

	3. Three multivalued MAPI properties on
	   NON_IPM_SUBTREE/Freebusy%20Data/LocalFreebusy.EML also
	   track your delegates:
		x6844101e  display names of delegates
		x68451102  entryids of delegates
		x686b1003  boolean "can see private items" values

	4. Meeting request forwarding is controlled by a server-side
           rule in Inbox. While we don't completely understand the
           format of server-side rule data, we can at least tell if
           someone is receiving meeting requests, because there will
           be a hidden message in Inbox with a PR_RULE_MSG_PROVIDER
	   of "Schedule+ EMS Interface" and a PR_RULE_MSG_ACTIONS
           that contains (among other stuff) the entryid of that
           delegate.


Private items can be recognized by PR_SENSITIVITY being 2. (0
corresponds to "Public" and 3 to "Confidential", but Outlook does not
hide "Confidential" items.) The server does not enforce the concept of
"private data". Thus, the client is responsible for filtering out
private items if the "can see private items" flag is not set for the
delegate. It is worth noting that since (a) the "can see private
items" flag is stored inside the "Freebusy Data" folder, and (b) a
delegate will only have read access to the "Freebusy Data" folder if
they have at least read access to the Calendar, then it is only
possible to find out if you have "can see private items" permission if
you have permission to see the Calendar.