WARNING: Ignoring deprecated option --unzip

[Alex Broens]

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?


> 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.
>> Also
>> maps_rbl_reject_code = 421
>>
>> will trigger an immediate session closing after a RBL reject so
>> misbehaved bots won't eaat up all your sessions
> 
> That is plain *nasty*.

Its recommended by Victor.. :-)
I love being nasty to bots...

> Instead of getting an instant notice that their mail was rejected a
> valid sender would have to wait at least 4 hours for a 'message delayed'
> response from their own server.  The sender will then continually retry
> the message too.  This will continue until the message is deleted from
> the queue of the host or the host is delisted.

bots/infected hosts don't retry. Valid senders shouldn't be listed in zen.
IF they are, I have little compassion.

> Or alternatively get an anti-spam daemon that doesn't suffer from any of
> these problems (we can sell you one of those...).

I can sell you a service which can't afford your product.
(but that is totally offtopic)

Alex