Five new delivery controls in PowerMTA 4.5

PowerMTA (PMTA 4.5) always had a strong focus on ‘doing one thing, and doing it right’. That one thing is email delivery. This sounds like a simple task, but it is hard to do at scale, both in terms of volume as well as in terms of the differences in the behaviour of receiving systems.

Now, the release of PowerMTA 4.5 of Port25 brings many improvements and new features. There are changes related to configuration, delivery, accounting, and web interface. This post highlights five new features which focus on the core work of PowerMTA: the delivery of emails. We will explain why and how these features improve delivery.

Bounce domains without MX

To avoid needless retries on typo domains that do exist but that do not accept email, PMTA was able to bounce messages to domains without the expected MX records. For example, while domain hotmial.com does exist and resolves to an IP, it does not publish an MX record. When trying to deliver to this domain, every attempt results in a timeout. However, it can be risky to bounce messages immediately. The SMTP standard says that without MX records, MTAs should assume the domain is the host, and sometimes it is.
PowerMTA 4.5 can do the required A lookups for a short period, for example one hour, and then bounce the mails if MX records are missing. This will avoid a queue full of typo domains while still delivering to the occasional host without MX.

Increasing retry intervals

Retrying of messages used to be done at fixed intervals. That means that with a retry interval of 10 minutes, 144 attempts are made in 24 hours. The interval can now be changed after each attempt. This allows the use of increasing intervals and avoiding useless attempts since the likelihood of delivery decreases over time. For example, the following sequence can be used for the first five attempts: 5m, 10m, 15m, 30m, 1h. The last specified interval will be used for subsequent attempts until the message expires.

Bounce on specific 4XX replies

Some providers return SMTP replies with a 4XX code when a mailbox is full, the account is inactive, or even when the address does not exist. For example, Google says:

452 4.2.2 The email account that you tried to reach is over quota. Please ...

The SMTP standard says that messages with a 4XX status code should be retried. But in practice, these mails will remain queued until the message expires. It is not very likely that a recipient with 15GB of mail is still ‘alive’. With 4.5 one can define reply patterns which should result in a bounce instead of a retry.

Limit connections on destination IP

PowerMTA has long been able to limit the number of concurrent connections at domain level and at MX host level. PowerMTA 4.5 can limit the number of concurrent connections at destination IP level. This is useful for a provider like Aruba, which hosts many domains, each with a unique MX host name, but all resolving to the same IPs. With connection limits per domain or per MX, this can result in the following error:

421 ... Too many connections, try later.

By limiting the number of connections to Aruba’s IPs, these errors can be avoided.

Rollup queues based on MX records

PowerMTA uses different queues for each recipient domain. This makes delivery highly concurrent and problems on one domain do not affect delivery on another. But delivery problems are often at provider level and affect all the recipient domains hosted by the provider. Take, for example, this common Hotmail error:

421 … We have limits for how many messages can be sent per hour and per day ...

To set limits at provider level, one could rollup domains into one queue. But this is a static list of domains and the MX lookup is only done on one of the domains in the list. When a domain moves to another provider, PMTA might send it to the wrong MX. In the past, Yahoo transferred domains to another provider. Also, for providers hosting many uncommon domains, the list would never be complete.

Version 4.5 has a better solution for this. PowerMTA is now able to rollup queues based on the MX records of each domain. If the MX records match a configured list of MX hosts at the time of submission, the domain will be put in the specified rollup queue.

Besides being able to apply limits at provider level, rollup can be more efficient for some providers. For business providers like Google Suite, small queues of different domains can be combined and sent through a single connection instead of through individual connections for each domain.

More information?
If you would like to know more about how we can help you, just send us a message via our contact page.

Share this

Comments are closed.

There are many more interesting blogs by category for you to read.