By now, the differences between Avanan and other API-based solutions are clear:

 

  • Avanan connects via API to prevent malicious emails from reaching the inbox, before end-users get a chance to see it or interact with it
  • Other API-based solutions connect via API, but can only detect and remove a malicious email after it reaches the inbox. 

(Avanan also operates in what we call Detect and Remediate mode, but most customers choose our inline prevention mode. We offer both, along with a monitor-only mode, to fit any customer need.)

However, if you go with another API-based solution, the biggest issue is time. 

These solutions will say that they can remove a malicious email from the inbox within milliseconds, making it impossible for an end-user to interact with a bad email.

This, as we've seen in their environments, is nearly impossible. Here's why.

In order to take a post-delivery action, these solutions first have to make an API call to fetch the email from the user's inbox.

The flow works like this. 

  • Email is sent
  • Email is delivered to the inbox
  • API solutions make an API call to fetch the email from the user inbox for analysis
  • API solutions make a second API call to do post-delivery remediation on malicious emails

That's two API calls in order to see the email and make a decision on whether it's good or bad. 

With API Throttling a major issue, the only way this can work in milliseconds is under the following scenario:

  • The email would have to be delivered at a very low traffic time 
  • Very few API calls are being made at the same time
  • The email will have to just text

In other words, everything has to go just right, not only with the malicious email, but with the traffic in your organization. 

Malicious emails don't arrive when it's convenient for your email solution. They arrive all the time. Waiting for perfect conditions leave you exposed.

If you use our Detect and Remediate option, we still do things differently.

We utilize journaling to receive a copy of the email as soon as it arrives at the mail server of the tenant. A copy of the email is journaled to us in parallel to the original email being delivered to the user's mailbox. Then we scan the email and take post-delivery remediation as necessary. 

So when you see marketing material talking about removing an email in milliseconds, it's not theoretically wrong. But in practice, it would almost never happen. Because email conditions are never just right. That's why we constantly hear stories of emails staying in the inbox for over three minutes at a time and a breach happening. Or, on the extreme side, eight hours and leading to a breach.

You can rely on hackers to wait until 4am on a Saturday when there's little traffic to send malicious emails.

Or you can get realistic and implement email security that is inline and scalable, no matter the time or situation.