Atomicorp

the search function of the forums aren't produced results, looks like something has changed?

anyway - got a strange problem, for some reason mail on our server has backed up as of this morning. i went through and changed a few things and suddenly it started processing, except the clamd process overwhelmed the server and it become non-responsive.

is there some way to stop the clam part of the scan, so I can just push the mail through and get it back down to a nice low level? or alternatively a way to keep clamd within a nice zone - i did try setting max threads at 5, but even this didn't seem to work.

i ended up removing qmail-scanner and clamd, then re-installing qmail-scanner, re-running qmail-scanner-reconfigure and it's not going crazy about errors for clamd, but it's still calling clamscan.. which has me perplexed.. (since it shouldn't exist)

righto.

finally after shutting everything down and using qmhandle we were able to purge 165,000 emails from the queue. looks like one of our clients pop3 accounts were compromised by a spammer/botnet and used to email out.

biggest problem now is that with qmail-scanner, spamassassin and clamav running, the system launches (and continues to launch) qmail-scanner-queue.pl processes and if we don't stop everything this takes out the system

i've since commented out the parts in qmail-scanner-queue.pl that tell it to use clamav, and now mail is finally flowing through.. but i have no idea why clamd is causing this problem or how to resolve it...

i decided to use google to search the forums, and found a few posts on permissions for qmail-queue.orig and what not, but nothing seems to have resolved the problem.. the moment i enable clamd the system overloads..

i take that back - even setting the variable to null qmail-scanner-queue.pl runs out of control.

i downloaded psa-qmail from the art repository and re-installed it after removing qmail-scanner and finally emails are going through. I'll re-install qmail-scanner once the queue is flushed.

damn spammers </grumbles>

I don't have anything to contribute or any suggestions to help you, but I wanted to post anyway to say that you have my sympathy. Double-damn spammers.

Faris.

faris wrote:I don't have anything to contribute or any suggestions to help you, but I wanted to post anyway to say that you have my sympathy. Double-damn spammers.

Faris.

thanx mate.. pretty sure i went grey that day..

what we found out was a user had a basic email password, a botnet had compromised this password, used smtpd_auth and then took advantage of the relaylock feature and launched god knows how many emails through our system..

this in itself didn't cause the problem - the problem was caused when some of the mail bounced back and the queue went into overdrive (totally 184,000 when we found it)...

mail basically stopped.. something i did in the process resulted in mail being processed again, but the sheer volume of mail in the system overloaded it and the load average reached 170 before we had to physically restart it to get back in..

the solution was to shutdown qmail, xinetd, clamd and spamassassin, use qmHandle to purge all emails which had the source domain (of the compromised account) and 'yahoo' in the headers (sorry to yahoo people but the bulk of the mailq was from/to yahoo accounts)..

once we'd culled that down to a more reasonable 11,000 emails in the queue we then found removing qmail-scanner and re-installing psa-qmail (rpm -ivh --force psa-qmail-xxxx.rpm) fixed whatever was wrong with qmail..

we probably could have left qmail-scanner in there, but were fearful of another overload..

once the queue got down to about 100 emails we put qmail-scanner back in and reconfigured it and all is happy again..

but as a result of this we've turned relaying off completely.. 90% of our clients use their ISP for relaying anyway, but there are a few people on the move that tend to use our system.. a shame, but we can't risk this sort of compromise..

between fighting the occassionally compromised web application and this, it takes up too much of our valuable time and is certainly not cost efficient..

we need to come up with some kind of email send rate detection in ASL for this. We've got that in there now for apache stuff (bruteforce detection) but by far this has been a much much bigger issue. I'll add this to the feature list as a high priority