A couple years ago there was a discussion about having Postfix SMTP
servers pause for several seconds at the start of each SMTP session,
and reject the session if the client speaks first. The idea was
that this is a sure sign that the client is a piece of crapware.
Although the idea of proactive botnet detection has merit, building
delays into the SMTPD process is very problematic. It causes Postfix
to waste more time on bogus SMTP clients, so that it reaches the
"all SMTP servers busy" condition sooner.
Postfix 2.5 stress-adaptive behavior is sufficient for short overload
peaks, but it is not a solution for the time when servers become
permanently flooded with botnet traffic.
To deal with botnet overload in the long run, Postfix needs a
traffic police agent in front of the SMTP servers.
Sites without $$$ would use a process like OpenBSD spamd that judges
SMTP clients the first time they connect, and that blacklists any
miscreants. Only clients that survive greylisting are allowed to
speak to the real MTA.
Sites with $$$ can afford to pay for a network-level traffic shaper
that does its own reputation management.
Preparations for Postfix traffic police agent support have begun
with Postfix 2.5 (the file descriptor passing feature). If I can
find time in the Postfix 2.7 development cycle, then there will be
a solution that also works for Postfix 2.5.
I ran a few simple experiments in the past few days, using as guinea
pigs the SMTP clients that resolve as "unknown". Due to time
constraints this testing was done by adding some ad-hoc code to a
live non-production SMTP server.
1) Pause up to 10s before sending the "220 myhostname.." greeting.
If the client replies before the greeting, hang up with a "521"
reply code. (This is like Sendmail's pre-greeting test except
that Sendmail replies with 554).
This caught a small number of QUIT commands after 5s. Other
clients simply hung up after a few seconds.
2) Send "220", pause up to 2s. Do likewise with each subsequent
word in the SMTP server greeting. Then send CRLF. If the client
replies before CRLF, hang up with a "521" reply code. (This is
a simplified version of OpenBSD spamd's "stuttering" feature).
This caught quite a few clients that send HELO (not EHLO)
immediately after receiving "220" but before Postfix sent the
rest of the server greeting plus the CRLF.
Most (but not all!) clients caught with the above tricks were listed
at zen.spamhaus.org.
Conclusion: as long as Postfix has enough resources to handle the
number of connections, "reject_rbl_client zen.spamhaus.org" will
mitigate botnet clients, and Postfix 2.6 automatic reduction of
timeouts under overload will handle occasional peaks. A front-end
police agent will be needed by the time that sites become permanently
flooded by botnet mail clients.
Wietse
