Thanks for a great product.

It would be nice to have the following:

* A button to manually flush the Queue without having to restart the service

* The ability to access the console via Terminal Services (doesn't work with 1.1.0.80, which is what I've tested it with)

* Ability to keep stats even after restarts (and mail summaries to the admin)

* Integration with a Syslog server

* Option to quarantine mail if reverse DNS fails.

Thanks!

Please find the answers below:

* A button to manually flush the Queue without having to restart the service

Good idea. We'll add that in the next build.

* The ability to access the console via Terminal Services (doesn't work with 1.1.0.80, which is what I've tested it with)

This is much harder than one might think because of the way Terminal Service works... We're still trying to determine if it's possible for a Terminal Session to interact with a Service application.

* Ability to keep stats even after restarts (and mail summaries to the admin)

We'll be adding "memory" to the stats in the next build, as far as mailing them, this will be added to the wish list!

* Integration with a Syslog server

Currently not planned for

* Option to quarantine mail if reverse DNS fails.

This is already available with build 1.1.2.114

Roberto Franceschetti
LogSat Software

>>This is much harder than one might think because of the
>>way Terminal Service works... We're still trying to determine
>>if it's possible for a Terminal Session to interact with a Service application.

It's definitely possible because I have a couple of other services running on the same box with the SpamFilter, and they allow access to their UI via Terminal Services (Remote Administration mode)

I'm not suggesting that it's easy, btw.  :)

Thanks for the follow-up

Yes, it sure is possible with other services. But I bet none (or very few) of the services you mention can be run as non-service, but rather as a standalone application. Most services provide a separate GUI that is run to remotely control/monitor the service. SpamFilter's service is unusual in that there is no control program. The GUI you see is the service.

Our service application was designed in a rather unorthodox way.

We wanted to provide SpamFilter in three different flavors. A Windows standalone application, a Windows NT service, and a Unix GUI application (a Unix console application is on the way). We succeeded, and furthermore we managed to do so by using the exact same source code files that can be compiled in three different ways.

So far the only downside this implementation is that we have not been able to have the service GUI appear in a terminal session, it only shows on the main console. With other remote control apps that show the server's desktop, like RemoteDesktop, PCAnywhere, VNC, DameWare etc., there are usually no problems. The only issue is how TS manages resources to provide the multi-user functionality os offers.

But we haven't given up on this. Being able to use TS with SpamFilter is something that many users (including us!) need, and a day does not go by we don't try something  new to make it work. So far we've been hitting a wall every time...

Roberto Franceschetti
LogSat Software

Hehehe    Conflicting design goals.  :)

I can appreciate that.