Thank you for your pithy response.

For clarification, monitoring the content is not difficult, however, for monitoring applications to deliver useful information they must be able to re-assemble these detected events for comprehensive managerial review. Below is my understanding of the technical limitations that these protocols bring to DLP.

Active FTP has a control session and a data session. This means that while each can be monitored they may not be successfully aggregated. This difficulty is not necessarily a problem with DLP but rather one of the consequences of using FTP. As an example if a network uses NAT, the NAT gateway must be stateful. The gateway needs to translate the IP address to the address assigned to the client. If the gateway doesn’t perform these operations correctly, FTP can fail. DLP applications need to maintain state and recombine the content. This frequently does not occur because unless all parts of the data stream are captured the reviewer is left to review only partial content.

Ajax applications running on a browser communicate with the Web server in an asynchronous manner and only update portions of the page. Applications that take advantage of Ajax techniques provide a rich, browser-based user experience, however for a DLP system to replay or recombine all of the content into a meaningful state would require the capturing of content that is not considered sensitive or at risk, thus making page reconstruction for reviewers of detected content difficult.

Lastly, within IM there must be a pre-determined amount of time that a session can be left open. If there is a significant amount of time (whether it is 50 seconds or 50 minutes) then the “conversation” will be broken. The context of a conversation is lost and the ability to monitor based on the context is also lost. Many DLP vendors are limited to monitoring only one message at a time. One interesting solution is to collate all messages from two users over a predetermined amount of time and then send the content in its entirety to the Message Processing Engine for a full context analysis (We currently have a solution with Facetime that does this very thing). The only shortfall here is that there is no ability to block or stop the communication.

The purpose of the post was an attempt to illustrate that the above difficulties encountered within these other protocols are not present in SMTP, therefore, whatever funds you are prepared to spend to protect your brand and reputation should be spent on email.

is quite frankly wrong. Packet reassembly is a TCP concept and has well defined algorithms on how to do it.

FTP is not difficult to monitor and AJAX makes very little difference as the underlying requests are all still just plain old HTTP.

Most IM clients use the SIP protocol and again this is relatively easy to monitor.