On Mon, 29 Nov 2004 10:40:47 +1300 Jason Haar wrote: > Sounds exactly correct to me. #1 is a normal, clean message. #2 and #3 > are viruses - so you shouldn't receive anything (based on the config you > showed - you won't get an alert), and #4 is SPAM - so you'll get it - > but it'd be tagged as SPAM by SpamAssassin if you had it.
OK. I was under the impression that the local admin would get some sort of notification message for the two emails with viruses. Maybe not? > Look good. You didn't run "maketcprules" afterwards to generate the CDB > version? I did run qmailctl cdb to rebuild the CDB file. When the QMAILQUEUE one is installed, I see the status 256. Otherwise, it's squeaky clean. > >There's nothing in any of the other logs (/var/log/qmail/current, > >/var/log/mail/*, /var/log/clamd/current or > >/var/spool/qmailscan/qmail-queue.log). Nada. After smtpd accepted the message and failed with status 256, I waited about 10 minutes... nothing was written to any of other logs. I then disabled Q-S, rebuilt the CDB and instructed my backup MX to resend anything it had. At that point, the test email shows up -- the one that qmail rejected -- and the headers are evidence that it came through my backup MX. > Hmm, so syslog shows no X-Qmail-Scanner error, qmail-queue.log shows no > error. Nope. syslog shows messages from the scans performed by test_installation.sh and the normal startup/shutdown stuff. qmail-queue.log also shows messages from the test scans. > This means either you aren't calling Q-S, or Q-S has such > terrible permissions set on it that it cannot even generate the > appropriate log entries. When you ran "test_installation.sh" - did they > show up in the qmail-queue.log file? Yup. > Are all the files/dirs under > /var/spool/qmailscan owned by qscand? Yup. I can even log in as a non-privileged user and run test_installation.sh. The logs are written to and the emails are properly quarantined. > I'd suspect a simple spelling > mistake of you QMAILQUEUE environment variable - but what you showed in > your tcp.smtp file looks correct to me (but it's what's in the CDB file > that actually counts). Check that string is really set correctly and do > "maketcprules" again. I will try again... I think I've done it 100 times so far :) > In this kind of case strace is your friend. Find the PID associated with > tcpserver, and trace if via "strace -f -o /tmp/strace.log -p PID". Then > send a message through and watch it fail. (tcpserver will call > qmail-smtpd which [via QMAILQUEUE] should call qmail-scanner-queue.pl). > Then Ctrl-C the strace and edit /tmp/strace.log and go to the bottom and > work your way up until you find what went wrong. This is a great idea. I wasn't aware of strace. Wish me luck. Brenda Bell Henniker (the only one on earth) New Hampshire (the state with 5 seasons: black fly, tourist, foliage, ski and mud) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Qmail-scanner-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
