Subject: postscreen deep protocol tests without mail delays
The problem
===========
The Postfix postscreen daemon is a light-weight front end that
eliminates spambots before they can suck up limited Postfix SMTP
server resources. This feature is available with the Postfix 2.8
stable release, and it is primarily a solution for small sites. See
http://www.postfix.org/POSTSCREEN_README.html for an introduction.
postscreen can be configured to enforce deep protocol tests to
ensure that a client implements SMTP without cheating (for example,
sending multiple SMTP commands without waiting for the server reply).
One of the limitations of the "deep protocol test" implementation
is that postscreen can't hand off an SMTP session to Postfix SMTP
servers in the middle of an SMTP session. After a client completes
the deep protocol tests, postscreen responds with 4XX to RCPT TO
commands. The client is expected to hang up, and the next time the
client connects it can deliver mail immediately.
I have always been concerned that this is just another greylisting
test in disguise, with all the negative results of mail delays etc.
But I have found a solution that can eliminate those delays.
Listening on primary and backup MX addresses
============================================
This week I was doing some expiriments: I configured Postfix to
make postscreen listen on both primary AND backup MX addresses.
This was a matter of adding a second IP address to the ethernet
interface of my mail server, then adding a backup DNS MX record
that resolves to that second IP address.
Sure enough, the first SMTP client to connect to the backup MX
address was a spambot that never even tried to connect to the primary
MX address. That's one for postscreen, zero for the spambot.
Listening on both primary AND backup MX addresses opens a number
of opportunities for MX policy enforcement, for example:
- Whitelist clients only when they pass all tests on the primary
MX address. In other words, clients can't get whitelisted when
they connect only to the backup MX address, and can never send
mail. On the other hand, clients that are already whitelisted
can deliver mail to any MX address, primary or secondary.
While looking at the logs, I noticed that I had found a solution
for the mail delivery delay after a deep protocol test. The solution
is so simple that it should have been obvious long ago:
- Client connects to primary MX address, goes through the deep
protocol tests, passes the tests, gets a 4XX response from
postscreen, and hangs up.
- Client immediately connects to the backup MX address, and delivers
mail immediately, because it is already whitelisted. Thus the
delay after "deep protocol test" is eliminated.
Conclusion
==========
Making postscreen listen on both primary and backup MX addresses
opens opportunities for policy enforcement.
Even if I don't enforce any policy on what happens when client
connects to the primary or backup MX, I already get the benefit
that the delays after deep protocol tests are eliminated.
Only sites with unpatched qmail (it connects to the backup MX only
when the primary is down) or equivalent will suffer from delivery
delay after a deep protocol test.
Best of all, this Postfix solution requires zero lines of code :-)
Wietse
