Print Page | Close Window

EnableWebServer=1

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=5753
Printed Date: 22 January 2025 at 7:48am


Topic: EnableWebServer=1
Posted By: StevenJohns
Subject: EnableWebServer=1
Date Posted: 11 August 2006 at 9:44am

Hi All,

I have noticed that SF seems to have an internal web server.

What is it for?? When I connect to it, I am asked for a user/password, but I see no mention of it in either the interface or the documentation??

Any ideas ?




Replies:
Posted By: LogSat
Date Posted: 11 August 2006 at 4:02pm
With version 3 we introduced the possibility to control many of SpamFilter's functionality via a web browser. This was done by creating a custom webserver within SpamFilter. It is disabled by default, but can be turned on from the "Settings -Web Server" tab. To change the default password (default = "password"), you can do so from that tab.

Please note that we haven't received a lot of positive feedback for this new feature, so it may be dropped in the near future.


-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 11 August 2006 at 4:13pm

Ah yes...now I've got it.

Well, I can understand why you haven't had a great deal of positive feedback on this...however.

1. The fact that your interface can't be run within a terminal server session is stupid. Every other management application you can think of runs in a TS session. I understand that I could install VNC, but it's horribly slow and vunerable to attack. TS has to be the way to go, I would suggest you look at the way you do it, maybe split it into 2 applications that talk to each other via a TCP port. This way there wouldn't be any problem from within TS and we could run the front end from out management PC's and connect to the server across a VPN....then we wouldn't have any need to TS into the box at all.

2. The web interface is clumsy to use, however I think it's a good idea if you can manage to clean it up a bit.

 



Posted By: LogSat
Date Posted: 11 August 2006 at 10:24pm
>>Every other management application you can think of runs in a TS session

That is true, but please note that the number of applications that can be run in either service mode or as a standalone mode is proably inversely proportional

Back in 2002 when SpamFilter was released, we had tried very hard to find a workaround to Windows 2000 not being able to display the service icon in a TS session. We were not having any luck, when eventually Windows 2003 Server was released. Microsoft realized that there was something wrong with their 2000 TS server, and updated their TS server in 2003.

Please find below our "standarized response" in this matter:

=========================================

Please note that the service does display a GUI on the server's screen, but if you are accessing a Windows 2000 server remotely using Terminal Services will not be able to display the GUI. This is because Terminal Services in Win2K is not able to display the server's physical console.
Looking at the physical server's screen, or using a product like PCAnywhere, DameWare, VNC etc that displays the actual screen will instead reveal the console.

Microsoft fixed this in Windows 2003, and with this version of the operating system Terminal Services instead does allow RDP to connect to the Console.

Some Terminal Services clients have a checkbox in their settings to connect to the console. In the XP Remote Desktop, Microsoft (in)conveniently decided to not make it available. In this case, to view the server's physical console (and if running Server 2003), you'll need to invoke Remote Desktop from the command line as follows to enable this:

mstsc -console






-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 12 August 2006 at 7:29am

err,...

>>That is true, but please note that the number of applications that can be run in either service mode or as a standalone mode is proably inversely proportional

not actually true...

The service runs "spamfiltersvc.exe", which isn't need ed in standalone mode, as you then run "spamfilter.exe". This I have tried...delete the spamfiltersvc.exe and the standalone app works fine.

Therefore, you dont have an application thatcan be run in either service mode or standalone mode, what you actually have is two indipendant programs...a service and an application....

 


 



Posted By: LogSat
Date Posted: 12 August 2006 at 9:09am
...you mised the point. A single .exe cannot be used for both service and standalone mode. What I meant is that we have "an application" that can either be started in standalone mode or service mode. They are two separate executables, one for each mode, but it's always the same "application". The service exe, SpamFilterSvc.exe has a few extra lines of code to make it work as a service, but all of SpamFilter's source code is *exactly* the same for both executables.

While it is true that in theory we could have had a separate application to monitor/configure the service, this would have had bad side-effects. Please note how SpamFilter works by having a single executable of only 3MB in size that is the whole application. There's just 3 DLLs in SpamFilter's directory for SSL and a few minor things. SpamFilter can handle 50,000 emails/day on a small 400MHz CPU server, and will use less than 100MB of RAM under those conditions. 99.9% of SpamFilter's upgrades require simply stopping SpamFilter, copying the two updated .exe files, and restarting SpamFilter.

Yes, we could have separated the service from the monitoring/configuration application, but this would have affected performance. We've always tried to maximize performance, so we opted to design SpamFilter as it currently works.


-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 13 August 2006 at 5:48am

No problen, you have to design it as you see fit, it just means that we have to then wriote our oun code to overcome your "features" and get it to work the way we need it.

I do agree that SF is quite good. I cannot comment on the performance with 50,000 emails a day,but I can comment on the 99% bit.

We are not seeing 99% capture at all....I will do the maths and get some real life results to you.

 



Posted By: LogSat
Date Posted: 13 August 2006 at 9:10am
... I didn't say 99% capture rate, I said:

99.9% of SpamFilter's upgrades require simply stopping SpamFilter, copying the two updated .exe files, and restarting SpamFilter.


-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 13 August 2006 at 5:09pm

Absolutely true, I skip read the previous post.

Sorry, my mistake.



Posted By: LogSat
Date Posted: 13 August 2006 at 5:19pm
no problem 

-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 13 August 2006 at 5:27pm

Roberto,

A quick question.

Am I right in thinking that if I delete the quarantine database connection string, and then thee SF to "Tag Spam & Deliver", that it will tag all spam with a header (and not in the subject), and will deliver all email to the configured SMTP server.?

If this is the case, how do I find out what the "MAIL FROM:" and "RCPT TO:" smtp commands were, as these often bear no relationto the "From:" and "To:" headers within the mail.

cheers



Posted By: LogSat
Date Posted: 13 August 2006 at 5:53pm
Yes, correct in everything.

As indeed the headers are different, SpamFilter indicates in a custom "X-SF-RX-Return-Path:" the address used in the MAIL FROM.

There isn't however any indication on the RCPT TO. We can't add anything to identify these in custom headers, as if we did, emails with multiple recipients would be delivered with all the recipients visible in the headers. This would be quite a privacy problem, especially with emails from listservers, distribution lists, and blind copy recipients.



-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 13 August 2006 at 5:58pm

Ah, I have a situation where I need to apply an accept ro reject filter on an email which is delivered to multiple recipients. However, only some of the recipients want to recieve the email, while others want to decline it.

One man's ham is another man's spam !!!

Have you any idea how I could get the RCPT recipients, other than trawling through the log for each email recieved ?

Cheers



Posted By: LogSat
Date Posted: 13 August 2006 at 6:43pm
Unfortunately the log is the only way... at least with SpamFilter and the headers it (doesn't) add .




-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP


Posted By: StevenJohns
Date Posted: 14 August 2006 at 4:02am

Database logging would make this so much easier...a simple sql query, rather than trawling through text files....

However, I presume that SF must keep track of the recipients that are valid for any given email, as it must need this info to issue to the smtp server that it forwards the email to. Therefore I couls get the valid recipients from my smtp server after SF has forwarded it??

 

 



Posted By: sgeorge
Date Posted: 16 August 2006 at 11:30am
Roberto, just some feedback on the internal web server...

I recently purchased the registered version of SpamFilter, and found the  SpamFilter Config Settings web server to be helpful.  I still use the "mstsc -console" command most of the time in order to Remote Desktop to SpamFilter; but the config web site allows me to securely (via https :]) change settings at times when other administrators are trying to make use of the server at the same time.

Thanks, it's handy.  I imagine it probably takes quite a bit of upkeep work to update the SpamFilter application GUI and the web interface for every single build of SpamFilter.  I understand if it become overwhelming to maintain... but I do want to let you know that it is appreciated.

Stephen



Print Page | Close Window