We talk often about the differences between API-based vendors.

There's Avanan's approach, which blocks malicious messages before the inbox. This is prevention.

Then there's everyone else, who can only remove a threat after it reaches the inbox.

Most companies will say this takes milliseconds, that it's impossible for a user to even have a chance to click on something. But in reality, it's not true. For one, the email provider and the security system have to establish a connection. That can take a second, but it can take even longer when hundreds of connections need to be made. We've written about this before.

After the connection is made, the email in question needs to be downloaded. The connection needs to be terminated. Then it needs to be scanned. If the email is malicious, then another connection needs to be made in order to quarantine. Then it needs to be quarantined. This can take, on average, about three minutes.

But it can be a lot longer, especially when there is throttling in play. API is the second priority to email processing. If there’s load, then API is the first to suffer. This makes sense from an implementation standpoint, but for email security to rely on a second-priority API is very risky.

So think about this when you hear this story we recently heard. One company, using an API-based email security company, saw a threat get delivered to a number of users. It sat in those user's inboxes for eight hours before being removed.

It wasn't just sitting idly by. The threat caused damage and caused the company to be attacked. 

For real-time emails Avanan uses SMTP. It’s scalable and it can be inline.

Remember, if you're not preventing the threat from coming into the inbox, it will enter the inbox.  Once a threat is in your environment, whether it's three for five minutes or eight hours, it's already too late.