DecryptionLast week we have made a lot of improvements across several of our products. Monday & Tuesday were bug squashing days, we went through the bugs that have been submitted via and resolved most of the outstanding issues. Remember, if you have an important bug make sure you submit it to our development queue. The rest of the week was spent implementing our new message decryption engine across several of our platforms.

One of the most common and repeating issues was in regards to rendering issues with messages viewed at and SPAM previews through ExchangeDefender. While most messages would render without any problems, there were still those handful of clients who had issues with some messages. Typically this was caused by the use of different 3rd party e-mail clients that would use an unexpected RFC type or submit the data using a weird/foreign content-encoding type. This is even more prevalent in SPAM previews, because most of the time those messages are garbled or gibberish! So that makes the decryption process even more challenging!

So these last few months, we’ve been examining a new core technology to decrypt these messages and help bring more legible content to our users and their clients. With this new decryption core it handles most MIME types flawlessly and adheres to most RFC standards for messages. We ran it through several test cases where previously: “the messages was unpleasant to read” and it converted them to “a perfect rendered instant of the original message”. However, there are still the few instances where our old engine is better than the new decryption core.

That’s why we’ve implemented dual decryption core technology. This is a custom implementation that will programmatically decide which engine is best to use on a per message basis. First, it examines the message and tries to load it with the new decryption engine, while it decodes the message it makes note of any issues that have occurred upon the decryption process. If there was an issue, it will run the message through the second decryption engine and compare the results, then render the best instance of that message.

You’re going to see a lot of rapid development over the following months here at ExchangeDefender. Like I discussed in previous posts, we’ve starting to implement SOAP across several platforms and it’s really taking hold. The Compliance Archive enhancements, Decryption Engine enhancement and even planned Shockey Monkey Dynamic Callback Mechanism have all been made possible by the use of SOAP that we’ve implemented here at ExchangeDefender over the past several months.


Hank Newman
VP Development, ExchangeDefender