You've been using Outlook for years now and you've probably established some delivery rules for yourself. Maybe mail from your manager is automatically routed to a subfolder of your inbox. If you're using Outlook 2003 or later, you've got an automatically maintained rule to handle junk mail. If you've ever set your Out Of Office, that's handled by a rule too. But how do rules actually work? What's the implementation like? Obviously, I won't get into the grimy details (trade secrets and all), but I can pass along the basics. First, the rules infrastructure is fully documented on MSDN. Those among you brave enough to explore this documentation may be inspired to write a little app which will enumerate your inbox rules and print them out on the console for detailed inspection of just what Outlook creates. I wrote such an app for internal diagnostic purposes (which means I most likely can't share it with you, sorry). Oh wait! Someone else has already published something here! A rule consists of two fundamental properties, and a bunch of other support properties which mostly won't matter for this discussion. The important ones are the rule's conditions, and the rule's actions. Simplistically, if the incoming mail passes the restriction, the rule engine subsequently carries out the actions. The rule engine itself is completely agnostic to the intentions of the rule creator. In other words, the rule engine doesn't care what the title of the rule type in Outlook's wizard is – it only applies the restriction and then if that passes, it carries out the actions. The conditions are expressed as a MAPI Restriction. As each mail is delivered, the restriction on each rule is applied to the incoming message. The restriction describes a complex property value comparison tree, such as (the received time > somedatetime AND the sender's display name starts with "Bob" AND the body contains "Loser") OR (the message size is greater than 2k). Such restrictions are also used for searching for messages, filtering views, and so on. In this case, the restriction is applied to the incoming message. This means that rules cannot check against dynamic values, such as the current system time or how big the mailbox is. It's constrained to checking properties of the message against constant values. One exception to this is how the Junk Mail rule works, which I'll describe later. Outlook has a variety of pre-canned restrictions that it uses and I won't go into the exact nature of each one (yes, I know, you're just burning to know what the precise nature of each of these is, but you can use the sample app I linked to above to study the precise nature of each of the rule types). I will point out an important design point though: rules which are of the form "FROM some DISTRIBUTION GROUP" actually means "if the sender is a direct or indirect member of that DL". This often confuses people because they create a rule like "mail from <my team DL>, move to the <my team> folder". What ends up happening is all mail from anyone on the "my team DL" starts having their mail moved to that folder. If you think about it, it makes complete sense. However, more often than not, folks really wanted the rule "mail SENT TO <my team DL>, move it". If the message meets the restriction criteria, the actions are then carried out. While Outlook rarely creates rules with multiple actions within, it's possible to have a list of actions on one rule. The possible actions are:
- Move the message to another folder*
- Copy the message to another folder*
- Reply to the message (with a given template message)
- Send an "Out Of Office" reply (with a given template message)
- Fail delivery with a specific error code
- Forward the message to another address
- Delegate the message to another address (a lot like forward, but it preserves original sender info)
- Tag the message with a specific property value
- Permanently delete the message (Outlook doesn't use this when you create a rule with a delete action. Instead, it creates a MOVE action with the Deleted Items as the destination folder)
- Mark the message as read
- And finally, the big one: defer to the client to carry out client-defined actions.
You Had Me at EHLO.