I wonder if we ever put the troubleshooting methodology up from the book here.

Debugging procedure for services/users/daemons writing to files, cant write to something... you make the directory its trying to write to world writable and then wait until mystery-service writes something to the directory. Whatever user it creates the file as will tell you what the file needs to be owned by. Then chown -R mysteryuser <path/fill/in/the/blank>. PS- dont forget to set your permissions back.

Have you ever made a survey of how many of your customers really use Plesk spamassassin configuration and training methods via the GUI?
I would consider it. The survey I did answered my question pretty good.

0% (zero!) used the features.
90% did not even know about it altough they got a good introduction and a step-by-step-for-the-dumbest-assumable-user-tutorial-pdf
100% don't wanted to take the time using it.

So you see. It's not all about features. Similar to a Porsche GTS in a blind mans garage

I just wanted to thank everyone for their input, i went the route of removing psa-spamassassin, spamassassin and qmail scanner then did a re-install of just art spamassasin and qmail-scanner only. Now for tweaking the setup is it just adjusting the /etc/qmail-scanner.ini and /etc/mail/spamassassin/local.cf files only or is there more to it than that. And if anyone has some tips or setting examples i would love to see what others use.

Thanks to all in advance.

I can relate to the OP's frustration. qmail-scanner + clamd + spamassassin is simply to heavy to run in a shared hosting environment. If I understand correctly, ASL recommends running email on a separate server from web services for this reason. The biggest frustration for me is that clamd + spamassassin are called for every *outgoing* email, from email lists and whatnot, and this is simply a huge resource hog. From what I understand, you can't turn off AV/SA checking for outgoing without turning it off for incoming, so the solution is to remove qmail-scanner. Following the docs on simply removing clamd_scanner and spamassassin from the qmail-scanner-queue.pl and reconfiguring simply don't get the job done. QS still insists on hogging resources.

Anyway, I was luckier than the OP, when I did the plesk "switch to postfix then switch back to qmail" it finally all started working again. Reinstalling the psa-qmail RPM did *not* fix it after uninstalling qmail-scanner, as QS's hooks were still in there somehow.

When I've rolled qmail installs manually, there was always some form of tcprules or invocation file that specified which queue you were running through. I looked for this with the psa-qmail rpm and couldn't find it, so I couldn't manually disable QS.

Lots of frustration with QS, I'd say you should know that you *need* it before you go down that path, and plan on having dedicated resources to your mail stack.

A few months ago I did a reinstall. Neved installed qmail scanner again... The fact that you actually can't remove it is really bad...

Definitely. All of the antivirus and antispam products out there are pretty CPU heavy. But theres an even better reason to do this: email can be slow it doesnt need to be "real time". What I mean by this is that email, unlike any other service on the system (web, ssh, FTP, etc.) can be slow. Users will tolerate an email taking a few seconds to be delivered, but they won't in my experience tolerate a web site taking several seconds to load. Nor will they tolerate SSH taking several seconds to reply to a key stroke, mysql taking several seconds to respond, and so on.

But they will tolerate email taking a few seconds. So, the best bang for your buck is to set up a dedicated box (doesnt even have to be big or fast) to offload and handle all incoming email and scan it for spam and viruses. That way, the only system that ever gets slow is one the users never "see". Its not hosting anything, so to them everything stays nice and fast. Plus, if you get a big surge of email, your websites (and your customers) won't be upset that their sites are now suddenly slow. Email might take a few more seconds to get to them, but since most users are tolerant of (and even expect) email to take a few seconds to get to them they never notice. A cheap server is all your need to do this, and the project gamera packages are purpose built to do this.

We even have big commercial customers, and government agencies that use Project Gamera for all their spam and virus scanning needs.

I thought this was still beta ! Is there anywhere documentation where we can read and understand how PG works ?

http://www.atomicorp.com/wiki/index.php/Project_Gamera has some information. There used to be more on the old atomicrocketturtle.com Joomla site (e.g. http://www.atomicrocketturtle.com/Jooml ... iew/77/29/ ), but the content seems to have disappeared from those pages.

I saw the first link but information are not adequate...

This server that I've been having on-and-off crashing battles with for months... now that qmail-scanner is off of it, life has gotten much better. I offloaded most email services elsewhere, and just use this for outgoing email lists that are tied in directly to the website software.