Amavis stopping

[Dominic Raferd]

On 28 June 2017 at 02:44, Paul R. Ganci <ganci at nurdog.com> wrote:

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


​I don't have a solution to the problem but the following is quick'n'dirty
fix by adding a line to /etc/crontab to warn you (if you monitor cron
output) - by monitoring CPU usage hourly - that amavis (or postfix) is very
active (>30% CPU), which might imply something wrong:

2 * * * *         root for PROCESS in amavis postfix; do [[ $(top -bn1|grep
$PROCESS|awk '{CPU=CPU+$10} END {printf "\%d", CPU}') -gt 30 ]] && echo
"$PROCESS CPU usage high!"; done

If you are running it outside of crontab omit the backslash before the %
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20170628/82dd2e81/attachment.html>