WARNING: Ignoring deprecated option --unzip
Jethro R Binks
jethro.binks at strath.ac.uk
Tue Jan 27 21:14:13 GMT 2009
On Tue, 27 Jan 2009, Alex Broens wrote:
> On 1/27/2009 4:46 PM, Steve Freegard wrote:
> > Alex Broens wrote:
> > > Could be misbehaved bots are eating up all your available sessions.
> > >
> > > if you have a zillion of inactive open connections try reducing your
> > > smtpd_timeout
> > >
> > > start off with and tune according to timeout requirements
> > >
> > > smtpd_timeout = 90s
> > > (read the postfix docs and understand what this setting can do for you,
> > > good & bad)
> > RFC default is 300 seconds you might get away with less; but diagnosing
> > failures here won't be fun. Change this with caution...
> ....RFCs written before the day of the bot... :-) did I mention that he
> should read the docs about the caveats?
It works both ways. The RFCs, originally written at a time when networks
were slower and less reliable and hardware less capable, have generous
timeouts for the SMTP conversation. So yes, in default configurations,
MTAs have to be very very patient, and bots can potentially hang on to MTA
But if the MTAs play by these rules, then so should the clients.
However, many bot client SMTP implementations do not play by the rules
very well (possibly intentionally). If your server is slow to respond at
each stage, and the client poorly written, the client can sometimes fall
over itself stuffing SMTP commands down a link to a server that is too
chilled to answer so quickly, and hence they get out of sequence, or
simply lose patience and disconnect. The writers of some bot SMTP clients
also realise that there's probably little point hanging around on and on
waiting for a slow MTA to respond to each command. Much more efficient
for them to dump that MTA and move on to another more responsive one
elsewhere into which more junk can be pumped.
So, ideally, introduce delays into your SMTP conversations to shed off the
crap clients. Size your OS TCP stack to accomodate the max number of
concurrent connections you want to see or can handle. If you reach that
limit, the legitimate senders will try again later or move on to another
MX for your domain. If you are perpetually at that limit, there isn't
much else you can do other than resize your OS TCP stack (and possibly
hardware), add more MXs, or implement other DDoS attack prevention
machanisms possibly with the assistance of your ISP (e.g., identifying the
most prolific culprits and blocking their ability to create TCP sessions
at the firewall level - enough to ride the wave). If you're playing this
game, you have to accept that there may come a time when there is pretty
much _nothing_ you can do - as many large sites and their providers have
All this does produce collateral damage from people who have unwisely
tinkerered with their MTA's timers (for being an SMTP client), or whose
vendors didn't write a very good MTA in the first place. I accept that,
having introduced delays, some of my time is taken up talking to operators
of MTAs that haven't played by the rules, and suggesting how they might
fix them to operate properly. That's the trade-off for the successful
shedding of crap SMTP clients (mostly junk senders).
On 1/27/2009 4:46 PM, Steve Freegard wrote:
> Our products have a better way of handling this; if a host is
> blacklisted or acts peculiarly then we have a separate timeout for it
> (60s) which is way safer than reducing this globally.
Indeed, if your MTA permits it, you can increase (or decrease) delays
based on other criteria. So you may "whitelist" the MTAs of sites you
trust (or ones you are told to accept mail from even if their MTA is
broken), reducing the delays, or add more delay at certain points if you
have reason to suspect the legitimacy of the connecting host.
Additionally, if you have reasons to believe that you really do not wish
to accept mail from a connecting client (maybe the client is on a
blocklist that you particularly trust), under some circumstances rather
than just issuing an appropriate 5xx rejection response, you can consider
forcibly dropping the SMTP session (rather than letting the client decide
it wants to continue, perhaps with more RCPTs that you will likewise keep
rejection). That will reduce the number of bots etc hanging around
chewing up your connection slots.
All these techniques need to be weighed up for your own environment; in
mine, it greatly decreases the load on the heavyweight stuff that follows:
SpamAssassin, MailScanner, virus scanners, and such like, at a cost of
some support load increase.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK
More information about the MailScanner