Be wary of any next-gen, API-based email security provider when they use the term, “milliseconds”.  This should be an automatic red-flag for which they must be able to explain in a common sense way that doesn’t suspend reason and logic.  In other words, they need to explain why they think gravity doesn’t apply to them.  More specifically, how do they overcome:

  1. Latency

  2. Throttling

As the earth is round and water is wet, latency and throttling are a fact of life.  Don't let the slick salespeople convince you otherwise.  

Latency

To really understand latency, let’s take a look at what milliseconds actually look like.  Do a simple ping to microsoft.com or google.com.  In this case, we did a ping of the AWS CloudFront.  The ping command “sends out an echo request. If it finds the target system, the remote host sends back an echo reply”.  This is the most basic of commands that involves almost zero processing.  This response is clearly milliseconds. 

ping

Now, let’s play this out in terms of how this relates to the API vendor “milliseconds” claim.  When you think about how an API vendor does its “magic”, it’s much more complex than a ping command.  Rather than a ping command, an API vendor interacts with the cloud email provider using numerous API calls per email.  These calls include:

  1.       An API call to learn about the new email
  2.       An API call to retrieve a copy of the email & its content
  3.       An API call to download the attachment
  4.       Processing by the API vendor to determine if the email or its attachment is malicious
  5.       If it’s malicious, an API call to move or delete the email or remove it from the user’s inbox

Are we really supposed to believe all of this happens within the same time as a ping command?  Multiple calls plus advanced processing.  Even if they are successful in fooling people to believe milliseconds, they have to take another giant leap to convince the same folks that such an approach is better than zero seconds.  See a demonstration below. 

 

Throttling

The nail in the coffin in terms of the milliseconds claim comes when you take into consideration throttling, which is what Microsoft and Google both do when there are too many API requests coming in.  As Microsoft explains,

“When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail.”

Further, if you google “microsoft API throttling limits 429 error” you’ll see overwhelming evidence that throttling is real and does absolutely happen.  The question for your API provider, is not “Are you throttled?” but “What happens when you are throttled?”  In the article above, Microsoft lays out a whole series of best practices for vendors to implement when throttling does occur.

The reality is that when throttling does occur, expect the dwell time to be “15-30 minutes” as one customer described it.  Even in small environments throttling is a problem as this user describes here. 

And there’s no way to “increase throttling limits” as this developer discovered.  Basically, the advice from Microsoft is to reduce the number of calls, reduce the frequency, and avoid immediate retries on the 429 error.  These best practices will increase the inbox dwell time.  And it's why the millisecond myth is just that--a myth.