WARNING: Ignoring deprecated option --unzip

Alex Broens ms-list at alexb.ch
Tue Jan 27 14:57:17 GMT 2009

On 1/27/2009 3:39 PM, Simon Jones wrote:
> 2009/1/27 Simon Jones <simonmjones at gmail.com>:
>> 2009/1/27 Steve Freegard <steve.freegard at fsl.com>:
>>> Simon Jones wrote:
>>>> Hi Steve,  thank you.
>>>> I seem to have resolved the hold queue problem and can see performance
>>>> is very good on the mailscanner front but smtp is very slow to
>>>> connect.  It's fine if I restart MS, I get a connection right away on
>>>> port 25 but it soon slows down and within a couple of mins it takes
>>>> ages to connect.
>>>> 20636 pts/0    S+     0:00          \_ grep -i mailscanner
>>>> 12582 ?        Ss     0:00 MailScanner: master waiting for children, sleeping
>>>> 12583 ?        S      0:10  \_ MailScanner: waiting for messages
>>> <SNIP>
>>> LOL - based on that output; MailScanner is completely quiet - it's not
>>> doing anything except waiting for messages....
>>> The reason why it slows down within a couple of minutes has nothing to
>>> do with MailScanner; it's due to the number of concurrent connections in
>>> Postfix building up.
>>> Based on this you can completely ignore MailScanner as the source of
>>> your woes; the problem is in Postfix or the database.
>>>> it does smell of DNS but I can do nslookup / dig no probs on the
>>>> system and I've tried changing the DNS resolvers to different name
>>>> servers both on and off my network which has made no difference.
>>> Hmmmm - I would have a good look at your Postfix configuration and look
>>> for any typos in RBL lists etc. as an unlucky typo there could cause all
>>> sorts of timeouts.
>>>> I also store relay_domains relay_recipients and transport_maps in a mysql db and
>>>> use _maps.mysql.conf to point postfix to the relevant table.
>>> I don't know much about Postfix interfaces to MySQL; I would check all
>>> the SQL and make sure there are no 'LIKE' directives within the
>>> statements and that any WHERE fields are indexed together correctly for
>>> maximum query speed.   I would also look at using the 'proxymap' service
>>> to prevent bazillions of concurrent MySQL connections from each of the
>>> Postfix child processes...
>>>> I tried the Log Speed thing but it didn't seem to show any output in the maillog?
>>> Maybe you haven't got any mail through since you switched it on; a
>>> simpler grep would be:
>>> grep Batch /path/to/mail/log | grep processed
>>> This still wouldn't hurt leave this on and see how fast your batches are
>>> completing; (total time / batch size) = average time per message; this
>>> should be between 1 and 8 seconds - any higher and you have a problem
>>> somewhere - but I really don't think MailScanner is the source of your
>>> issues; it's definitely a Postfix problem.
>>> Regards,
>>> Steve.
>>> --
>> I restarted postfix on its own as Jason suggested and this does indeed
>> allow connections to become available for a short time and then slow
>> up to as previously described.  This is definately something to do
>> with postfix and not MS, I've just copied over my main.cf from a
>> working system and restarted, same results.  I don't have any firewall
>> config active which would imit connections, the server can resolve its
>> host name both locally and using dns, ptr works and resolves, postfix
>> checks out ok with no errors, permissions in /var/spool/ look OK and
>> match with a working system.  getting stuck now, guess it could be a
>> denial of service but nothing obviously points to this at the moment.
> upped the max processes in /etc/postfix/master.cf and the server is
> now responsing normally so it would seem that the default of 100 is
> being maxed out, guess I need to do some tcpdump commands to see who's
> hammering the system...

Could be misbehaved bots are eating up all your available sessions.

if you have a zillion of inactive open connections try reducing your

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)

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



More information about the MailScanner mailing list