[EMAIL PROTECTED] wrote: > > This seems like a rather destructive behavior on the part of > Qmail-Scanner. > > (I haven't seen a comment about this in the archives - I'll admit I didn't > go through every month) > > I've seen this happen several times, and the last time was EXTREMELY bad - > happened for a full day. > > Here's an example > > @40000000405d336b1c406624 tcpserver: ok 19256 > mail.bkwm.com:216.201.150.40:25 c-24-1-180-209.client.co > mcast.net:24.1.180.209::1992 > @40000000405d33703302307c X-Qmail-Scanner-1.20st:[mail107984982856819257] > clamuko: corrupt or unknown > clamd scanner error or memory/resource/perms problem - exit status 2
You could run swatch (perl program that monitors log files) and tell it to send you an email if it ever sees something like that in your log files again. > What had happened is that the server's video card had gone out, thus > taking the machine down. After replacing the server, and powering back up > - I didn't get an error message from clamd - it turns out that the /tmp > file wasn't removed by the script (which it is supposed to do), so clamd > refused to start up. Okay - that's acceptable. > > However, what the mail server did is continue to receive messages, and > instead of leaving the messages in the queue until the error went away - > it would hit the "can't find clamd" and proceed to throw the message away. I think you don't understand where qmail-scanner fits in the qmail-smtpd->qmail-queue pipeline. Qmail-scanner is called BEFORE the message is queued. The only thing qmail-scanner can do is CAUSE qmail-smtpd to return a 451 (temporary error code) instead of a 5xx permanent error code. Unfortunately I haven't looked deeply enough at qmail-scanner's error codes to comment on them. I run ClamAV under the daemontools package (supervise) which ensures that my clamd is running 24/7. However, even daemontools can't protect against an improper install. That's why I run a testing mail server and a production mail server. The testing server sees any changes before the production server so I can iron out any problems before they hit the production server. > It seems like it would be more reasonable for the scan process to go > 'Process can't work!' and then either feed the mails through (maybe with a > message to the admin that the program is buggering up), or store them in > queue, again, with a message to the admin. I'd rather not send my users viruses, personally. I think it would be sufficient for qmail-scanner to cause qmail-smtpd to return a 451 code. This way the remote sending mail server would queue the message and try again later. My question would be: Does qmail-scanner cause qmail-smtpd to return a 451 if it detects problems with one of it's scanners? Does it email the admin in this case? -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Qmail-scanner-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
