This is the last post in our series on the Automatic Back Off feature in PowerMTA. In Part I we introduced you to Automatic Back Off Mode. In part II we conducted a deeper dive whereby we demonstrated that sender reputation must be managed at the local level for optimized sends. In part III, we’ll define several rules you can implement that are optimally customizable.
For greatest flexibility and granular sending control, PowerMTA™ groups messages for a particular domain within a particular VirtualMTA in its very own queue. Sender reputation monitoring categorizes defined SMTP responses (bounces) from remote hosts for each queue, with the ability to define certain actions (e.g., send an e-mail alert while throttling deliveries) upon a match. You can create highly customizable actions at different thresholds for different VirtualMTAs. The Automatic Back off mode allows you to regulate domain specific rules, limits substituting requirements, and deferral responses in real time. Each message can be shaped with individual set of rules tuned specifically for its sending environment. You can extend these capabilities with your own customized set of rules.
Queue Modality: Backoff and Normal
Queue Modality is accomplished through the introduction of queue “modes”. The two modes currently supported are “normal” and “backoff”. You can also configure PowerMTA so that, when a queue enters backoff mode, it can trigger several types of rules, many of which are granularly customizable. As an email administrator, you should be familiar with all ISP rate-limiting policies in order to configure “back-off” mode optimally. Below are a few rules you can implement when “back-off” mode is triggered:
- Send an email alert to one or more addresses
- Dynamically change the retry schedule for that queue
- Dynamically apply per-queue delivery throttling
- Dynamically reroute messages from one VirtualMTA to another VirtualMTA
- Automatically use a different IP to send the message
- Limit the amount of messages sent per hour, minute, or second
- Resume Normal Delivery speeds after a successful delivery of an email
- Reduce the amount of open connections to an ISP
Defining backoff VirtualMTAs is also relatively straightforward using the backoff-reroute-to-vmta directive. It simply specifies that PowerMTA should reroute messages to the given VirtualMTA in case the queue enters backoff mode. For example, if messages are queued for example.port25.com/vmta1 and that queue enters backoff mode while backoff-reroute-to-virtual-mta is set to vmta2, all of its messages would be rerouted to the queue example.port25. com/vmta2. Because the messages would then be queued within vmta2, that particular VirtualMTA’s settings would apply.
New messages entering the queue are also immediately rerouted to the new VirtualMTA, as long as the vmta1 queue remains in backoff mode. With this feature, if there is an SMTP pattern match for any domain for VirtualMTA mta1, any messages in that specific queue will be delivered using the domain directives and VirtualMTA parameters defined in VirtualMTA backoff-mta1. As desired, the backoff parameters will only apply to messages for the specific queue, that is, for messages in the queue whose delivery attempts matched a SMTP response. Note that because the messages are really transferred from one VirtualMTA to another, the backoff-reroute-to-vmta directive effectively takes precedence over backoff-maxmsg-per-hour and backoff-retry-after.
We hope this series on our Automatic Back Off mode was insightful. There is a ton more information in our Forum on the Automatic Back Off mode feature so, dig in.