After messages are sent by any transport providers, the MAPI spooler calls each preprocessor's RemovePreprocessInfo function. This gives the preprocessor a chance to undo any changes it made to the input message before the message is passed to any hook providers. For example, a preprocessor for a FAX-based transport can generate a bitmap representation of the input message for sending to receiving fax machines; there will be little reason for that bitmap to be archived by any hook providers, so the RemovePreprocessInfo function can take the bitmap out of the input message before any hook providers process the message.
If multiple message preprocessors are being used, the individual RemovePreprocessInfo functions are called in the opposite order as the PreprocessMessage functions. This is so that RemovePreprocessInfo implementations that depend on positions within the message can locate the information they should remove without interference by the actions of other preprocessors. For example, a preprocessor that adds an automatic closing or signature to a message's PR_BODY or PR_RTF_COMPRESSED properties will probably use a position or offset from the end of the property to locate the information it should remove. If another preprocessor modifies these properties later, then that preprocessor's RemovePreprocessInfo function should undo its actions before the first preprocessor undoes its actions.
Note There is no requirement that the RemovePreprocessInfo function actually undoes the effects of the associated PreprocessMessage function. However, if the RemovePreprocessorInfo does not undo the effects of the PreprocessMessage, then the PreprocessMessage function should take care to make its changes in such a way as to minimize interference with RemovePreprocessInfo implementations that do, or make an effort to inform the user that the transport provider which registers the preprocessor should be installed into the user's profile ahead of other transports.