Weaknesses of Microsoft Exchange Archiving and Filtering

The Exchange™ message transport and delivery mechanisms generate some substantial issues when it comes to archiving and filtering, including:

Lack of clearly separate transport and storage mechanisms. Although the MTA is a separate service to the Exchange™ server's Information Store within the Windows™ operating system, the Exchange™ MTA is not truly independent of the Exchange™ store. In practice, the Exchange™ MTA is not used absent the Information Store, and the Information Store will not run unless the MTA is present. This close cross-coupling between the MTA and the Information Store within Exchange™ means that there is no clear and hard distinction between the transport of messages (at which time they can be filtered and/or archived) and the storage of messages, making it hard or impossible to introduce services like filtering and/or archiving within the Exchange™ MTA.
Closed proprietary and undocumented inter-message-transport communication. An even more serious problem for archiving and filtering under Exchange™ is the fact that Exchange™ MTAs use a proprietary network protocol to communicate with one another. This protocol, often called ESMTP (Extended SMTP), carries Exchange™ meta-data from server to server along with basic email information. ESMTP is not supported by third-party archiving or filtering products, nor by third-party MTAs - so it is not possible to place an open-standards-based filter, archiving product or MTA in-line between two Exchange™ MTAs.
Efficient and cost-effective standards-based virus filters that support standard SMTP but not ESMTP are often deployed at the edge of an enterprise (where the enterprise connects to the Internet) because the email traffic there is SMTP and so the edge-filter can be connected in-line in order to filter incoming and outgoing traffic. However, these kinds of virus filters cannot be deployed within an Exchange™-based organization because they cannot handle Microsoft-proprietary ESMTP.
Reliance on proprietary at-the-server anti-virus APIs. In an attempt to ameliorate the inability to use standards-based (i.e. SMTP-based) virus filters within an Exchange™ farm, Microsoft has provided Exchange-specific virus filtering APIs on their servers. Exchange™-only virus-filtering solutions can be expensive, and they can also slow system performance dramatically, to such an extent that Microsoft often advises customers not to run server-based virus filtering at all.
Reliance on proprietary deprecated Journaling mechanisms for archiving. Similarly, in an Exchange™ environment, it is simply not possible to use the message transport to deliver a copy of messages to an archival system. Instead, archiving tools that attach to Exchange™ typically make use of the Exchange™-specific "Journaling" mechanism, even though Microsoft deprecated Journaling in the 2003 version of their software. The Journal is a complex mechanism, partly client and partly server based, that makes a record of every transaction carried out on the server. By turning on the Journal within Outlook™ and Exchange™, then extracting information from the Journal and retransmitting it to an archival store, archival software installed at the Exchange™ server creates the archival record. Again, these Exchange™-specific solutions can be expensive, can dramatically reduce server performance, are hard to configure, and can be vulnerable to being accidentally or deliberately by-passed.