You have considerable latitude in how you implement the specifics of the InboundMsgHook and OutboundMsgHook methods. In general, these methods compare one or more properties of the input message against the rules the hook provider implements. Based on these comparisons, the message can be modified, moved to a different message store, moved to a different folder by returning a different folder entry identifier, or marked for deletion by the MAPI spooler by returning a null folder entry identifier.
In addition, these methods return one or both of the flags HOOK_CANCEL and HOOK_DELETE to indicate how the MAPI spooler should react to the InboundMsgHook method's actions. The HOOK_CANCEL flag indicates that no other hook providers should be called for the message. The HOOK_DELETE flag indicates that the MAPI spooler should delete the message; the hook provider should never use calls to the message store provider to delete the message directly but should set the HOOK_DELETE flag and allow the MAPI spooler to delete the message.
Hook providers can create additional messages based on the input message if desired. However, if the hook provider intends for an additional message to be submitted for sending, the message must be created using the default message store provider object provided by the MAPI spooler.
The InboundMsgHook and OutboundMsgHook methods are nearly identical as far as interaction with message objects and message stores. The only architectural difference is that the MAPI spooler calls them at different times. Many hook provider implementations can share substantial portions of code between these methods because they are so similar in function.
See InboundMsgHook and OutboundMsgHook for details on how to treat the flags and folder entry identifier parameters.