R,

When the SF logs states that spamfilter.ini reloaded.  Is that reloading all the settings in the ini or just the external files for the white & black lists?

 

Thanks,
Dan B

R,

Is there way that you can add to the future wish release to have SF the ability to reload the full ini.  During the 60 sec reload of the external files, maybe have a line in the ini like this.

reloadsfsettings=0    ;at normal running state
reloadsfsettings =1    ;when it needs reloaded and after it reloads it would change it back to 0  Something similar to ServU FTP  You can modify the ini using a 3rd party and you just change the relaodsettings=0 to 1 to trigger the reload.

Thanks,
Dan B

 

 

re: automatically reloading .ini every so often.

Can I ask why you would want to?
What are you looking to do with the .ini file?

I thought you maybe able to programmatically restart the service after a change.

If you are running on a server (win2003 or Win2k with the resource pack) there is a command line for managing services (sc) which you could send.

sc <server> stop <service>
sc <server> start <service>

Dan B and Dan S,

We actually had an internal build that was testing that feature... I'll send you the link via private forum msg if you'd like to test it.

Dan S - the change was not "turned on" in the 442 build I provided you earlier. The release notes for this internal build are:

// New to VersionNumber = '2.5.1.443';
{TODO -cFix : virus emails were not being blocked if any of the "Tag and deliver" options were checked}
{TODO -cNew : SpamFilter.ini is automatically reloaded if modified by external application}
{TODO -cNew : When automatic reload of blacklist/whitelist and SpamFilter.ini files, the event is now logged}

lead,

SpamFilter does perform some validatation in the ini, but as the ini file was created and maintained by SpamFilter, it's not extensive, super fool proof validation. We have added a feature to have it reloaded automatically, but we did not "improve" the validation process. We have implemented the request, but now we in turn ask the administrators to ensure they add "clean" data in the file, as problems may arise if that is not the case.

Should errors occurr in parsing the file, they will be logged. But since there are many possible errors, there are many possible events that can be created in the log, depending on where they occurr. We will not be able to always mention a problem with the ini file, as the errors routines will not know if the problem was introduced by an external app modifying the file or not.

SpamFilter currently checks the files every 3 minutes to see if they were changed. When a reload occurs, the event is immediately logged in the logfile. At the moment we do not plan to have an external trigger start the reload process.

PS - the only commandline option other that the /reinstall is the "-d" option for the standalone, non-service version which causes a debugging window to appear when SpamFilter shuts down to report any mem leaks that may occurr. It is not to be used routinely as the application will be slower as it needs to keep track of all memory allocations as they occur.