Retry Schedule

Before reading this page, be sure you are familiar with the differences between the ram-queue, disk-queue and bounce-queue. These are described on the GreenArrow Concepts page.

Overview

When a message is injected into GreenArrow Engine from an external source, the first delivery attempt occurs in the ram-queue.

When GreenArrow Engine internally generates a messages, such as a bounce, the first delivery attempt occurs in the bounce-queue.

If a message in either the ram-queue or bounce-queue is deferred or throttled, it gets sent to the disk queue, which uses a quadratic formula to schedule future delivery attempts.

An exception to both the ram-queue and bounce-queue behavior is deliveries to local domain names, which are not moved to the disk-queue.

The chart in the next section shows the retry schedule. Details on how this schedule is calculated and implemented can be found in the More Details section.

Chart

More Details

This chart above is not followed precisely. GreenArrow Engine’s scheduling processes introduce some additional variability in order to smooth out the retry schedule for bursts of injected messages.

The retry schedule can be expressed as the following formula, where n is the retry attempt:

((n-1)*20)²

Override

The retry schedule above can be overridden by the retry_time directive on a per-VirtualMTA or per-domain basis.

The retry schedule for each message is the first match in the following list:

1. The retry_time configured for the recipient’s domain within the VirtualMTA requested at the time of injection.

2. The retry_time configured for the recipient’s domain within the VirtualMTA that the most recent delivery attempt used.

3. The retry_time configured for the recipient’s domain within the wildcard * ip_address block.

4. The default retry schedule.