After setting up ClamWall I just fount three files left, and they look to be left while the server was starting, and therefore ClamWall still was loading. It looks like to be some kind of time-out, then.

ClamWall can quarantine infected messages to a file system folder, what it can do is to quarantine them to a mailbox, and to check a file folder remotely is more cumbersome than checking a mailbox - and requires to have the right TCP ports open on both ends.

Thank you for your help.

I often find some files in the scratch folders. Some are locked and cannot be deleted until Mercury is restarted. I have two policies, one to check messages with ClamWin (but I am not using ClamWall), and one to check with SpamAssassin. Because the machine is a bit old and runs a web server and some other services too, I may think some checks may took too much time and Mercury somehow timeouts. It looks I am not losing messages, just some files left in the folder. What could I do to avoid this, besides deleting them?

For now, please wait until Mercury/32 v4.5 comes out: when it does, let me know if you still see this happening.

V4.5 is so heavily reworked, and has been so vastly tested that we've eliminated an enormous number of problems - it's quite possible that this is one of them.

Cheers!

-- David --

Hello,

I've updated to the latest release, and the problem got worse, the number of files left behind has increased. Now I have a lot of files as this:

-------------------------------------------------------------------------------

WARNING: Can't access file C:\Programmi\Mercury\Scratch\60722BB2.TMP

----------- SCAN SUMMARY -----------
Known viruses: 128897
Engine version: 0.90.2
Scanned directories: 0
Scanned files: 0
Skipped non-executable files: 0
Infected files: 0
Data scanned: 0.00 MB
Time: 77.551 sec (1 m 17 s)

The given file never exists. Then I have a lot of empty files. I have this policies:

c:\programmi\perl\bin\spamassassin.bat -e < ~A > ~R (enabled)

C:\Progra~1\ClamWin\Bin\clamscan.exe --tempdir="D:\TEMP" -l ~R --database="C:\docume~1\alluse~1\clamwi~1\db" ~A (prefilter, enabled) 

[quote user="ldsandon"] WARNING: Can't access file C:\Programmi\Mercury\Scratch\60722BB2.TMP

The given file never exists. Then I have a lot of empty files. I have this policies:

c:\programmi\perl\bin\spamassassin.bat -e < ~A > ~R (enabled)[/quote]

This is my guessing: 

The "> ~R" is creating the result file even though there is nothing to work - do you have AV-file scan enabled on the scratch directory while at the same time having spamassasin search the file?

No, I have no "real-time" file scan enabled on the mail server.

This is a bit confusing. The error message you quoted is from a virus scanning program, isn't it?

Right, but that's the Mercury policy scanning inbound messages.

OK. So let's narrow it down a bit:

 - Did the setup with the two policies work correctly at any time on this machine?

 - Have you been able to verify that the disks are error free? Could there be temporary problems with insufficient free space on the C: drive?

 - Would it be possible to test using Clamwall with Mercury 4.51 instead of the policy, or would it be asking to much of the hardware in this case? That would make sure that the policies don't clash, and as Clamwall uses a permanent ClamAV process instead of loading the program (and virus definitions) for every message it would save processor time and cut down on disk accesses. The error message you quoted indicated that it took ClamWin over a minute to get to the point where it noticed that the file it was supposed to check didn't exist.

Policies worked correctly in version 4.01, when files were left behind only occasionally. C: has 4.5 GB free, if possibile I'll move the scratch folder to a different physical disk.

In the event log there is no disk error event, and the disk were checked and defragmented three weeks ago. I saw the ClamWin is taking a lot of time to process a file, I'll try ClamWall and see what happens. I've used it but returned to ClamWin because it is unable to forward infected messages to a mailbox of my choice.

Mmmmmh, it looks like ClamWin has become very slow to start..., maybe one of the last updates made it so. ClamD is very slow too - and I am using this version http://w32.clamav.net/ that does not require CygWin (but it requires .NET 2.0 just for the setup!!!!!  - got the files manually <g>) , but at least once started it stays active. Once active the mail is checked in a couple of seconds, when it starts it requires almost one minute - yes, my system is a bit old, that's my home mail server I use to filter out spam and viruses for the whole family :)

It will be interesting to hear if that solves at least the problem with the non-existing temp files. I agree that it would be good if Clamwall had the option to save messages that are found to be infected to a quarantine folder rather than just deleting them, though.