I was the victim of a parachute drop this week. What is a parachute drop? It is where there is a problem somewhere and your boss calls you and says, you need to be on the next plane to “insert name of city in the world here that you weren’t planning on being at tomorrow”. I got the notice and less than 24 hours later I was in city in the Western US in the mountains, only about 6-8 hours or so of airport and airline time from Michigan. I dislike parachute drops. They tend to really muck with you and throw you all out of sync.
The problem ended up being a multitude of things all stacked up upon each other. This actually seems to be the case more often than not with Exchange based problems. Exchange has this habit of running fairly ok right up until so many things are misbehaving that it just pukes. Unfortunately the complexity of the system is such that people don’t like to look at it normally to see if it is running properly and are just lucky that not enough things have gone pear shaped yet to impact user experience.
Anyway, I learned something entirely new. It seems that there is this rule you can apply called “From a DL”. I never realized it was there because I always used, “To a DL”. The thing is, in Exchange, if someone sends a message to a DL, it doesn’t come to you saying it is from the DL, it comes to you saying it was from the user. So what in the world does “From a DL” do? Does it even work? If so, does it work properly? If so, that could possibly break Exchange or AD if used very heavily…
There are four ways that I can think of to implement this rule on the server side. Two wouldn’t work very well, the other two could possibly hurt Exchange and/or AD.
The first mechanism, which is safest for Exchange is to enumerate the memberOf attribute of the user the mail is coming from. Very simple single query. However it will miss all nested groups and any groups that aren’t kept in the members attribute of the GC that is queried. So that means group nesting and group scope could both break the functioning of the rule. And the group scope could break it in an inconsistent manner in a multi-domain forest, it would entirely depend on the GC queried…
The second mechanism is like the first, but it chases group nesting. This can still break based on group scope and what GC is queried but could also break Exchange if the nesting is very deep.
The third mechanism is to query the DL and ask for the membership to see if the user who sent the message is a member and then query every member to get the Exchange specific info. If the first query goes to a GC, again, group scope could cause it to fail. Also again, nesting would be completely ignored.
The fourth mechanism is like the third, but chases the nested groups. You still have the group scope issue if it uses a GC and you could also break Exchange if the nesting is very deep again…
So no good way to handle that rule… I would say to you… avoid it.
