WARNING: Ignoring deprecated option --unzip

[Jethro R Binks]

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 
connections.

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 
found.

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.

-- 
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks
Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK