Hi there. First, I have an assumption that I'd like to state - then you can tell me whether this is actually a "bug" or not....

Assumption: When the quarantine database is not available, SpamFilter retains messages that are destined for the db, and attemps to insert them when the database is later available - is this correct?

If that's not correct, then the rest of this post is irrelevant.  Nonetheless, here it goes:

Situation: I'm one of the yahoos who uses an MS Access quarantine db (even though my db gets large w/o maintenance and I could easily switch to SQL ).   Today I went to clean up my access db the way I typically do:
1. Make a copy of the db.
2. Clean the copy up
3. replace the live db with the cleaned up.

During step #1 - the copy operation - the database became unavailable to write (this is normal).  However, 4 emails destined for the database were not stored, and have not been stored afterwards (it's been 30 minutes since they were rejected as I write this post).  These four emails generated error messages such as this in the log file:

10/16/06 12:44:56:537 -- (123936) Created thread (122416) to add email to quarantine 10/16/06 12:44:57:209 -- (122416) Error occurred during TAddToQuarantineThread when accessing the quarantine database: Operation must use an updateable query ( 83 84 85 86 86a 86b 86c 87)

It appears (to me) that SpamFilter does not believe that the attempt to update database is a temporary issue, and that storing these emails is permanently aborted.  I would have expected it to retry when the database is available again.

All quarantinable emails that were rejected after the database copy was completed were stored into the database without a hitch.

In any case, I set myself up for it... I was copying a 408 MB quarantine db file - which is WAY too large for the MS Access format.  I shall tissk tissk myself.

Stephen

Aside: As usual, I've M.I.A. for several weeks. If anyone's been pm'ing/posting to me in the past month, I'll try to eventually get to your post this week.  Sorry, I haven't been ignoring you all!

Stephen,

Starting from version 3.0.1.571, we changed the way emails are quarantined. From that build on, that statement is not correct anymore. Please see the release note below. From 571 and later, if the archival fails, there will not be any more archivals until the database is back online and/or responding.:


// New to VersionNumber = '3.0.1.571';
{TODO -cFix : Redesigned how emails are added to quarantine DB - now this is handled by a separate thread, eliminating issues where MySQL database locks caused connections to queue up}
{TODO -cNew : logging for quarantined events has changed as follows:}
{           ;   the entry "EMail from a@a.com to b@b.com was received and quarantined" has a different threadID than the thread that processes the connection }
{           ;   added log entry "Created thread (nnnnn) to add email to quarantine" to track which quarantine thread was created in the connection thread}
{TODO -cFix : To attempt avoiding "Read Timeout" server errors when forwarding emails, we attempt to transfer emails in memory to the delivery thread, in addition to using queue spool files as a backup method}
{           ;   -NOTE- this will prevent antiviruses that scan the FileSystem to detect and stop emails}
{TODO -cNew : Added SpoolQueueFilesToMemory SpamFilter.ini option to force emails to be spooled to disk}
{TODO -cNew : Added SpamFilter.ini option to scan multiple images for spam}
{TODO -cNew : The whitelist keyword filter now scans thru all the email's headers}