I would also prefer a option or someway of storing the messages - until the database is back up - we get blamed for loosing anything so always good to have proof of some sort.

We're watching the thread...

Weve always been hesitant in queing emails  if the DB  was offline, to then resume the archival when it came back online. This is  because there could be a HUGE amount of queued emails that has to e uploaded to the database, and we are afraid that this traffic cold overwhelm the DB server. Throttling the amount of upload to the DB is not simple, as what will fit one customer will not work for others.

This said, is a compromise reachable? What if SpamFilter simply spooled the emails to be archived to a temporary folder if the database is offline? That wold allow admis the ability to manually retrieve an email if needed. It wold also be up to the admins to maintain the temp directory by deleting old emails from it...

LogSat wrote: We're watching the thread...  Throttling the amount of upload to the DB is not simple, as what will fit one customer will not work for others.

Any option besides just dumping the message is better than nothing!

I tried to get the concept of not just deleting messages into the product while SFE was being developed...  I think it made it onto some wish list, but never got into the final product.

The logic I find most interesting is how SFE was designed to work from the ground up with the thought that the DB would be down at times.  By keeping the config / settings locally and always getting updates from the DB.

Totally written to handle the failure of a DB.

Then to turn around and just delete messages when the DB is down...  does not seem right. 

I vote for placing them in a que, with a configuration setting to throttle how fast they are placed in the DB when the DB comes back online.  X number per minute etc.  If the DB server is just rebooted, or hangs for a short time there should not be so much mail to process and probably no one would even notice.

If someone ends up with 50,000 messages in the queue because the server was off over a weekend they can adjust the insert speed, review & delete confirmed spam etc. to help clear the que.

We are testing a beta version with this feature internally with pretty good results. Would you be interested in testing it as well? 

I'll be sending you a PM shortly with the download URL.

As far as configurations, there's none needed. SpamFilter will spool emails to be archived in the \SpamFilter\quarantine directory. On successful archival, the files will be deleted. If the database operation fails, the files will be  renamed and SpamFilter will re-attempt delivery every 5 minutes.

Each email will consist of two files in plain text so they can be examined if needed. One will be the email body itself, the other will contain a few database-specific entries.

If the DB is offline for several hours, there will be quite a bit of emails to be inserted into the database. SpamFilter will "throttle" the archival process so that the number of concurrent connections into the database is one half the maximum number of connections allowed nto SpamFilter.

Just sent you a PM as well with the download URL...

10.08.07 14:13:12:252 -- (3976) Starting to process quarantine directory...

was the only line in the log I could find...

Hi Roberto

Build 725 is running smoothly!

As far as I can tell, the queuing and delayed inserting is working as intended.

Thanks for a great feature! Now, about that greylisting feature... :-)

Atif,

We've just upgraded the status from beta to pre-release for this latest 3.5.4.725 build, and have made it available in the registered user area. There are currently no known issues with it (and hope it will remain like this ).