I have had the same problem which has recently begun maybe 10 days or so
ago. I have managed to track it down to two particular emails that are
definitely spam and have created a Amavis DoS attack situation.
Basically the symptom appears to be that all 6 of the Amavis processes
on the server end up taking up 100% of the 6 processors assigned for
spam detection. The Amavis processes attempt to scan these messages and
never complete. As a result any other email gets "stuck" in the mailq
and hence the postifx error message that you mention appears in the
maillog file.
The only way I have managed to fix this problem is to move all the email
out of the Postfix mail queue, restart Amavis and then start
re-submitting the mail back into the queue. That is how I found which
spam emails were causing the DoS attack on the Amavis daemon. These
emails originated mostly from Amsterdam, France and Enihosting.com here
in the US. I have blocked the hosts from which these emails have
originated and have been okay since. I also have created a hourly cron
job to restart Amavis and then flush the Postifix mailq which seemed to
help a bit but did not completely stop the problem
What I would really like to know is what in these messages is causing
the 100% CPU usage and the subsequent DoS situation. I have the emails
handy if that would help but are there any suggestions as to how to
configure Amavis to avoid situations like a combinatorial explosion (no
I am not using my own spamassassin rules) mentioned in the other thread
(Amavis 100%)? I would even consider a timer... Give a Amavis process a
5 minute CPU limit and then just deliver the message is a better
situation than having thousands of messages queued up because all the
Amavis processes are running at 100% CPU for hours on end in my case.
I realize this is kind of general but people might have suggestions as
to Amavis configuration which can at least avoid the problem which
pretty much has shutdown my two email servers twice over the last couple
of weeks. I am also willing to provide the two culprit emails to anyone
who might like to look them over. In the meantime I might try raising
the debug level and running strace as suggested in the previously
mentioned thread... in principle I just need to re-submit one of the
offending messages. Any other ideas are welcome. Thanks.
--
Paul (ga...@nurdog.com)
cell: (303)257-5208
