We're trying SpamFilter for a few days to see if users notice the difference before we approach the Chairman about the cost.  First impression is SpamFilter will clean up over 80% of our spam.  A few suggestions:

Be able to analyse an email not by the incoming ip but the previous one (or two) in the headers.  This would allow filtering to work when mail was queued upstream either because line was down or because your ISP receives your mail and relays its (eg: demon.co.uk).  This would require us to input a list of 'trusted' relays known to SpamFilter so it could search backwards through the headers until it finds the first 'outside world' address and look that up in the block lists.

I agree with earlier suggestion to show reason for quarantine in the quarantine list.

An option on the pie chart to analyse total mail and blocked mail.

When SpamFilter is running at a service it is a problem only being able to open the control dialog from the console as our servers are sited remotely.  I've found that I can tell a bit about what it's doing from the files on disk but it would be useful if the controls could be run separately and communicate with the service.

Otherwise it's looking good.  Thanks,

JJ

John,

Currently SpamFilter does not examine the IPs in the headers as they may be faked and are thus unreliable. In the future we will ad some heuristic checks on them to examine and verify that they are correct.

The GUI not working with Terminal Services has a long discussion in these forums. Due to the way it is implemented, it will not work with TS. Any other remote-control application (PCAnywhere, McAfee Remote Desktop, VNC, DameWare) that shows the actual remote console will work just fine.

We'll be adding more charts shortly...!

Roberto Franceschetti
LogSat Software

Obviously upstream headers could be faked, hence our suggestion that the user can register a list of trusted relays - though I should add that this makes the assumption that the trusted relays will put into the envelope the *actual* ip address from which they received the message (this holds true with MS Exchange Server and sendmail if configured correctly).  In this case heuristic checking is not required.

As to the control dialog, I see it's been discussed before but none of my clients would allow us to install a third party application in order to see what's on the console when terminal services appears to do all this, and I suspect the same applies to others.  PC Anywhere has been known to kill remote access until you can talk a security guard into finding your desk (by ringing the phone there from your mobile) and waggling the mouse until PC Anywhere wakes up.  VNC can leave areas of the screen unupdateable.  Bottom line is that in a corporate environment getting approval for anti-spam software may not be difficult but asking for third party solutions for what the powers-that-be don't see as a problem is a lot harder, particularly if there's a perception that they destabilise the server ("we're not putting that [PCAnywhere/ McAfee Remote Desktop/VNC/DameWare] on - it costs money and hangs all the time - if this spam software doesn't work from a terminal server session you'll have to find something else").  Sorry, but it's true.

As a developer myself I understand that it's not trivial to achieve but it can be done, even if as a bit of a kludge - such as the VPOP3 mail server ( http://www.vpop3.co.uk" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - http://www.vpop3.co.uk ), which can be run from a terminal server session but throws up a few (actually superfluous and could be coded around) warnings if it's not the first instance but still goes on to control the service.

But thanks in any case, it's doing a fine job otherwise.

JJ

I don't believe SpamFilter depends on the header info so much and the actual connection IP to verify the senders address, and yes spoofing can be done but spoofed IP's are very hard to get a reply from since they are not real to start with.

I have been using PCAnywhere on all of my servers/workstations for the last 8 years and have never had a problem with properly configured server/workstations locking up. Now I have seen systems (not mine but clients)lock up when they minimal amounts of memory and or screen savers that consume large amounts of system resources.

TC is not a good option for remote access since there are too many known hack/exploit that are easy to take advantage of. Given the choice, I would rather spend money on a product that allows a more secure environment.

I realise that SpamFilter is looking at the actual ip of the connection and agree that this is the best way to test the source but fact that is that people need secondary mail relays and that some ISPs provide SMTP feeds only via their own relays so the only way to check the source is to trust known relays to correctly insert the address of their incoming connection into the headers.

I don't really want to get into a discussion of remote access products but the fact is that telling our clients they have to buy and install a 100UKP application just to run a 140UKP application is not on.  (Funny how people will whinge and moan about spam until you tell them the cost of fixing it.)  :-)  SpamFilter is looking great on test but we may not be able to implement it.  As for security of TS, basic security such as firewalls and VPNs is essential whatever remote access you use.

JJ

JJ,

The technical resons behind programming the way we did are the following.

NT services are usually designed to have a non-visual application running as a service. Then there is a separate application that is run interactively by the user which communicates in some way (COM, messages or other) with the service.

We provide SpamFilter in 3 flavors. A standalone application, a service application and a Linux application. We have been able to do this using a single set of source code that compiles in all 3 modes. This allows us to have any change we make in the GUI or functionality to be present on all 3 applications.

In order to do this we had to design the NT service in a different way. The GUI for the service is the actual service itself. It is not a remote control application. Proceeding this way allowed us to have the same interface for the service as in the other two modes, without changing a single line of code. Proceeding like this allowed us also to be able to make practically any configuration change that takes efect without ever having to stop and restart the service.

The only downside is Terminal Services. The service GUI runs unders the SYSTEM account and interacts with the desktop. If you have access to the desktop you will see the GUI. But TS does not give you access to the desktop... only to a virtual view of it. There are some applications (even MS apps...) that require the real desktop to work, SpamFilter's service GUI is one of them.

The advantages surpass the disadvantages. The GUI is usually used during the first stages to configure the system. During that phase, users can stop the service, and run the standalone application from their TS session. Make all their changes, see how it works, close the application and then start the service. Or they can use DameWare which installs the remote-control app on-the-fly, and uninstalls it when they are done remoting in.

The new build that we'll release very soon will have a web-enabled quarantine that will allow end-users to examine their quarantined items and force their delivery without needing help from the adminitrators, making the need to access the GUI even lower...

Roberto Franceschetti
LogSat Software

The idea of having a "trusted" relay list is a fantastic idea.  It should be relatively easy to impliment and would once again allow you to use secondary email servers for spooling mail.

As John has explained, since email from a "trusted" relay server is one that you know to be valid, the second IP in the header would be the outside IP connecting to your enterprise. 

This would certainly be a huge boon to help fight againt the new strategy of sending spam to secondary MX's so that they pass as trusted email.

Please do so.  This and HTML parsing seem like the two most powerful tools you can add to fight the next generation of spam techiques

The TS business bit me at first also and I HATE PCAnywhere and VNC so I tried (at Roberto's urging) the "Mini Remote" by DameWare.  It is a very stable product and we have had ZERO problems with it and it is cheap (90 bucks for a single server with as many clients as you want).   We actually bought a multiserver licence so we could also manage our 2 remaining NT boxes on our network. 

Try it out ... full 30 day demo with no missing features.  I think you will find it does the job.

Dan Seligmann

Remote Admin is also worth considering.

It's like VNC on steroids.  Much faster, but with the lean simplicity of VNC.  Also adds security and sizing features.  I even use it on top of TS at times without any speed problems.

Just a follow-up to the Service Discussions.

The way the Windows Server 2003 handles TS sessions is different from 2000 and more like XP.  As such, the SpamFilter interface works just fine in 2003 under a Terminal Services session.

So far, I have only tested it when logged in remotely as the same user that is logged in locally.  I'll perform other tests later.