Marcel,

That is the first report of a similar problems in several months, and definetly a first for v4.0. If you can please zip and email us your SpamFilter's activity logfile for the day this happened, we'll take a look. If the zip is over 5MB in size, please let us know so we can provide you with the FTP information to upload the file to us.

Having experience a re-occurance of the same problem, it would seem that upgrading to 4.0.0.72 has nothing to do with the problem.

I uploaded a zip with yesterday's and today's log files.

Marcel

Marcel,

We can't be 100% sure, as the logs for the 13th you sent stop at around 4pm, while the "here it is" section is for a problem that occurred later that day (5:42PM) and ths wasn't logged.

However, from the data that we can see, the problem does not seem at first related to the large number of connection attempts from the IPs you mentioned (and a few others). The issue seems instead related to the filter that scans within PDF files for images.
Unfortunately we are aware of a bug in the PDF library we use to scan PDF files for spam. We have been in contact with the vendor that provides the PDF library to work on a solution, but we are currently still waiting for the fix. Due to this problem, we have been actually shipping SpamFilter with the PDF-scanning filter in the disabled state by default, as we are aware of it. PDF scanning is disabled by setting the following option in the SpamFilter.ini file to 0:
 
SpamPDFMaxPagesToScan=0


Can you please try disabling this filter by using the above setting? You can edit the SpamFilter.ini file while SpamFilter is running, and there is no need to restart SpamFilter after the change.

I'm having this exact same issue but the setting you mention for the SpamPDFMaxPagesToScan is already set to =0.  

We received the file and are examining it. The database processing time should not be an issue with SpamFilter v4.0. In the previous versions, the archival of the email to the quarantine database was performed while the email was being received. This could indeed cause delays and connection buildups in case of delays with the database (SpamFilter performed some checks to ensure the timeouts would not have too much impact, but this was not foolproof).
In SpamFilter v4, the archival process has been completely separated from the email processing, so they do not affect each other at all. This has never been an issue (so far), so while I do not think that the quarantining process is directly responsible for the connection build-up, we're looking at all aspects in the log.

halowasher,

Could you please check in the \SpamFilter\quarantine or \SpamFilter\temp or SpamFilter\queue (the quarantine is more likely the culprit) directories to see if any of them have large (10,000+) number of temp files in them? From your logs, we see that SpamFilter is not able to create temp files in the quarantine directory.The log reports entries like:

03/31/08 00:00:00:326 -- (5268) Exception occurred during RECEIVEMESSAGE: ( 1 2 2b 3 3a 4 5 6 7 8 9 11 12 13 15 16 17 18 18b 19 20b 20c 29 30 31 32 33 53 55 56 77 78 111)  Error creating tmp file name - The file exists. --  --

It's possible that there was a huge buildup of files in the quarantine directories, so large that SpamFlter was not able to allocate a unique file name in there. SpamFilter will queue files in the quarantine directory if there are problems with the database server, so it's possible that there were way too may. If the DB isues are resolved, SpamFilter automatically uploades the contents of the spam emails being queued in the quarantine directory back to the database, so the directory may have emptied itself by now.

We'll be looking over the way these temp files are created (we use Windows API functions, so we did not believe we'd ever run into this theoretical problem...)