<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 June 2017 at 02:44, Paul R. Ganci <span dir="ltr"><<a href="mailto:ganci@nurdog.com" target="_blank">ganci@nurdog.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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<br>
<br>
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.<br>
<br>
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.</blockquote><div><br></div><div class="gmail_default" style="font-size:small">​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:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If you are running it outside of crontab omit the backslash before the %</div><div class="gmail_default" style="font-size:small">​</div></div></div></div>