2010/01/01 by Maarten Oelering.
Hotmail throttling and PowerMTA
Windows Live Hotmail is famous for throttling senders based on their IP reputation. The following two SMTP errors might be familiar:
421 PR(ct1) The mail server IP connecting to Windows Live Hotmail server has exceeded the connection limit allowed. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. For e-mail delivery information, please go to http://postmaster.live.com
421 RP-001 The mail server IP connecting to Windows Live Hotmail server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation problems. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support
PowerMTA offers a number of parameters for tuning email delivery to specific domains. The max-connect-rate and max-msg-rate parameters can be used to prevent these errors from occurring. If you would not react to these errors and keep on pushing your mail, your reputation could become even worse. In the PowerMTA configuration, this looks like:
<domain hotmail.com> max-connect-rate 10/m max-msg-rate 1000/h # other settings </domain>
Delivery settings in PowerMTA are made within the context of a recipient domain, such as hotmail.com. PowerMTA uses a separate mail queue for each unique combination of Virtual MTA and recipient domain. But there are many other domains related to Windows Live Hotmail, such as hotmail.co.uk, hotmail.de, live.com, live.nl, live.be, msn.com, etc. All these domains and many others are handled by the same mail servers, mx1.hotmail.com to mx4.hotmail.com.
Luckily PowerMTA offers domain-macro that can be used to make settings for a set of domains. For example:
domain-macro hotmail hotmail.com, live.nl, msn.com, hotmail.co.uk, live.com max-connect-rate 10/m max-msg-rate 1000/h # other settings
This effectively creates separate queues for each domain using the same settings. But because there are more queues, the number of connections and the message rate is increased with each queue. This is far from ideal, since the mail servers of Hotmail look at all the traffic from a sender IP, whatever the recipient domain. What we want is a single queue in PowerMTA for all mail traffic going to Hotmail’s servers.
For this we have to resort to an undocumented feature of PowerMTA, the queue-to parameter. This allows us to place mails for a domain in the queue of another domain. The latter queue will send all mail to the mail servers that it’s name resolves to. We can use this to collect the mails for a list of domains in a single queue. See the configuration below:
domain-macro hotmail hotmail.com, live.nl, msn.com, hotmail.co.uk, live.com <domain $hotmail> queue-to hotmail.queue </domain> <domain hotmail.queue> route hotmail.com max-connect-rate 10/m max-msg-rate 1000/h # other settings </domain>
The route parameter is used to make the MX lookup more explicit, and allowing us to use a special, arbitrary name for the queue to make clear that it is a special queue for all mail to Hotmail.
Now we are able to control the mail traffic going to Hotmail’s servers much more accurately. However, there is one catch to this configuration, and that is that MX lookups of other domains than hotmail.com are hard-coded in your configuration. Chances may be slim, but if one of the domains listed in the domain-macro is moved to another set of MXs, all mails will bounce, because they are always routed to the MXs of hotmail.com. Also, because the list of domains that are queued to the special queue are hard-coded, there could be other domains that also resolve to Hotmail’s servers.
You can further enhance this configuration by using smtp-pattern-list to detect the errors mentioned above, and automatically put the queue into backoff mode running at a slower pace. How this is done can be found in the PowerMTA Users Guide and is beyond the scope of this post.
After analyzing the connection data during “exceeded the connection limit” errors, I concluded that it is not the connection rate that causes the errors. Instead I found a correlation between the errors and the number of concurrent connections. This suggests that max-smtp-out should be used instead of max-connect-rate to prevent these errors. A value of 1-5 concurrent connections is a good limit for volumes between 1000-10000 per hour.
If you would like to know more about how we can help you, just send us a message via our contact page.