Smart Delivery Optimization (SDO)

Retarus uses a mechanism for Inbound and Outbound Smart Delivery Optimization that controls the dispatch and reception for emails. The outbound Smart Delivery Optimization automatically adapts the customer's sending behavior to the feedback from individual ISPs and/or ESPs to keep the throughput of messages at the ISPs and/or ESPs high. In exceptional cases, the optimized dispatch control can lead to a reduction of the agreed processing capacity.

SDO Inbound

The guaranteed hourly capacity is enforced on the customer level as defined in the contractual agreement by the SDO Inbound feature. All incoming requests over REST or SMTP APIs to the Retarus infrastructure are checked against the defined limit within your customer number. To cover possible rounding errors, we implicitly extend the hourly booked capacity by up to 25%, this is however not a guaranteed capacity.

Such an hourly capacity is set to protect both the Retarus infrastructure but also your own consumption in the case of malicious activity (like being hacked).

How is the hourly capacity working?

The 5-minute timeframe concept

While the limit is configured per hour, the throttling is enforced in blocks of 5 minutes, so the value per hour is interpolated into 5-minute windows. We check the traffic distribution using 5-minute timeframes and make sure the throughput is proportional to the booked hourly capacity.

As an example, for a guaranteed hourly capacity of 150.000 requests/hour, your guaranteed maximum throughput would be:

• (150.000 requests/hour) / (12 timeframes/hour) = 12.500 requests/timeframe;

• With the implicit capacity extension of 25%, the throughput could reach a maximum of up to 15.625 requests/timeframe;

• In that case, you can send 15.625 requests per timeframe, meaning 15.625 requests every 5 minutes.

The default hourly capacity is set to 5000 requests per hour, meaning 520 requests for every 5-minute window.

How is the hourly capacity count incremented?

• First, there are 2 separate counters, one by facade. These 2 counters are independent;

• The capacity per hour can be different per facade (SMTP or REST). The best practice is to have the same value set for both facades;

• The capacity per hour value is shared by both datacenters in the case of Active-Active setup. This means the hourly capacity count sums all JobRequests going through both datacenters;

• The capacity per hour is calculated by considering the traffic coming from all Technical Accounts you used during the 5-minute timeframe;

• The capacity per hour sums the accepted and rejected JobRequests:

  • In case of a rejected JobRequest, the capacity per hour count is incremented by +1;

  • In case of an accepted JobRequest, the capacity per hour count is incremented by the number of recipients (To:, Cc:, Bcc:) specified in the JobRequest.

What happens when the hourly capacity is reached?

When the hourly capacity is reached by one of the entry facades (REST or SMTP), any further JobRequests using the same facade will be rejected. You will receive an HTTP synchronous response with code „429 - LIMIT_EXCEEDED“.

These rejected JobRequests due to limit exceeded are not queued, are not processed at all by Transactional Email service, therefore emails are not delivered. We don’t keep these rejected JobRequests for processing them later.

Potential scenario:

• the hourly capacity for your REST interface is reached;

• REST facade refuses now any further REST JobRequests;

• but SMTP JobRequests can still be sent and will be accepted if the hourly capacity for the SMTP facade has not been reached yet.

Example of HTTP response with status code 429

{
   "meta":{
      "jobId":"41455798-70c6-4cd4-bae8-df03d1a6aa29",
      "state":{
         "type":"REJECTED",
         "subType":"LIMIT_EXCEEDED",
         "phase":"PRE_PROCESS",
         "description":"Request rate limit of %d recipients per hour exceeded."
      },
      "account":"m4a_test_user"
   }
}

What to do when you reach to limit?

As limits are usually very high, we require all our customers to distribute the booked capacity evenly across the hour, as it is not possible to send the defined limit all at once. Thus, the guaranteed hourly capacity comes with an essential precondition that you have a mechanism staggering the traffic evenly across the hour on your side, ensuring an even spread of the workload.

We recommend you use a retry mechanism for this scenario.

SDO Outbound

The SDO Outbound Solution checks the transmission logs to the recipient-ISP/ESP. During a high-volume transmission, receiving ISPs/ESPs cannot process many messages at the same time and give us feedback in the form of a SOFT_BOUNCE.

Sample of ISP soft bounces

[4.0.0] deferred (host freemx2.sinamail.sina.com.cn [113.108.216.47] said: 452 Too many recipients received this hour. Please refer to http://chengxin.mail.sina.com.cn/info/qa.php?p=ca1-452 XX.XX.XX.XX (in reply to DATAcommand))

[4.7.652] deferred (host outlook-com.olc.protection.outlook.com [104.47.37.33] said: 451 4.7.652 The mail server [XX.XX.XX.XX] has exceeded the maximum number of connections. (S3115) [CY1NAM02FT045.eop-nam02.prod.protection.outlook.com]

[4.4.2] deferred (host extmail.bigpond.com [XX.XX.XX.XX] refused to talk to me: 421 4.4.2 Connection refused due to exceed max concurrent connections . IB007)

[4.0.0] deferred (host smtp-in.orange.fr[XX.XX.XX.XX] refused to talk to me: 421 mwinf5c84 ME Trop de connexions, veuillez verifier votre configuration. Too many connections, slow down. OFR004_104 [104])

We aim to send all messages smoothly. In case of a hit, we throttle the outbound channel, to prevent receiving ISPs/ESPs put us on a Graylist or Blocklist. We’ve implemented a four-tier outbound channel, with different speeds for transmission. During the whole transmission, our service checks the behavior of the ISP/ESP. Using the SMTP information, we can detect if we can switch the transmission back to normal or if we have to switch to the next lower channel.

SDO Outbound Monitoring

Retarus provides status information on every email sent via the API callback (HTTP Push Notifications). You will be informed about newly created events e.g., delivery status, reasons for undeliverability, blocking of emails to recipients listed in the Suppression List, etc.

Within our API Callback solution, you will be informed in case that we have throttled your transmission with the following event types: