[Spambayes] A most peculair problem with SB 1

Robert Neuschul robert at imagine.co.uk
Wed Nov 10 01:14:30 CET 2004


One of us is now very confused, and I suspect it has to be me.

> If you've not done any configuration, then there won't be one.  If you have,
> it ought to be there somewhere.


> If you haven't done any classifying/filtering, there won't be any.  If you
> have, they ought to be there somewhere.

As I said, I couldn't start Spambayes in order to do any classifying, or 
anything else. Which means the error messages I posted are somewhat puzzling.

> The SpamBayes files will be located (unless you specify full paths) 

I wasn't aware of any option to specify paths: none of the documentation I've 
read on installing SB makes a reference to such an option for the full source 
version: and certainly none of the scripts seem to give any indication of a 
path-setting capability. 
The only time I've ever seen such a path selection option is when deploying 
the compiled Windows executable version on other machines. Can you please 
clarify where and how such a path option is available and how it should be 
used, or point to documentation that explains how this option is to be used.

> same directory as the last configuration file loaded.  If a configuration
> file isn't found, then the default place is in the current working directory
> unless you're on Windows (with pywin32 installed or using the binary), in
> which case it's a "Spambayes\Proxy" directory in the Windows Application
> Data directory.

This is very ambiguous phrasing: according to instructions on Windows one

a] installs Python and simply accepts the default install location - which for 
Python.org distributions is usually %SYSTEMBOOTDISK%\PythonNN where NN is the 
major version number.

b] expands the full source version of SB to a temporary directory on the boot 
disk, and then from a DOS/CMD sesssion in that temporary directory one runs 
"python setup.py install" which then compiles and locates files into the 
python tree. Once this is completed one may then delete the entire temporary 
SB directory. 
One should then run either the relevant server startup script such as 
sb_server or the server service install such as script pop3proxy_service.py, 
which are now located within the Python script tree.

In this context 

1] is "working directory" intended to refer to the temporary directory from 
which one has just installed, or to the relevant Python\LIB\ sub directory or 
the Python\Script directory. And if not these directories, then where might SB 
- as you put it - *expect* to find such a configuration file /apart/ from the 
user data area?

2] Having just done a parallel install onto a known-good and known-clean XP 
system, exercising some care I can now detect what should be happening: the 
process appears to be installing the proxy and DBs to 

%SYSTEMDRIVE%\Documents and Settings\CurrentUser\Application Data\Spambayes

Which is, in my view, a terribly bad place to be putting anything on a Windows 
2000/2003 server, and is even worse when SB is or will be running as a 

Any data subsequently entered into the DBs will not get backed up correctly 
and may also not be handled correctly by Shadow Volume services or by any user 
profile management which affects the user's data tree as implemented under 
2000/2003 GP in Active Directory. 

No Windows service should *ever* be installing or relying upon configuration 
or other data located in the *user* Data area and most especially not in the 
Administrator's data area or the data area of any user with administrator 
privileges. It's a fundamental breach of permissions and security and it's bad 
Windows programming practice.

And finally: the reason that the "service.py install" failed on my subsequent 
attempts is quite simple: there appears to have already been a Spambayes 
folder in that location from my first attempt at an installation, and 
subsequent attempts to install failed to write a new copy. I didn't even 
consider looking in that area since nothing in the documentation even 
suggested that this was where such data was located. 
Previous versions of SB appear correctly and much more logically to have held 
such data within the SB directory tree.

> I presume that in the past you didn't run "setup.py install".  

On the contrary: I did exactly that and had previous version of Spambayes 
running perfectly well - but on other hardware and with Windows 2000 Server.

However this is the first time that I've noticed Spambayes compile and copy 
itself into the Python tree. 
In the past with older versions, once Python was installed in c:\python, I 
merely ran SB from an entirely different directory - e.g. c:\spambayes. One 
then ran the pop3 service from there. This no longer works once one has run 
the setup script.

Having now realised what was going on with the Spambayes directory in the 
Application Data Area and sorted out the issue of being unable to write the 
proxy and DB correctly I have managed to get the pop3proxy_service installed 
and W2003 claims the service is running: however that service bluntly refuses 
to proxy workstation mail clients [and there are no server logs to indicate 
what is going on] - the mail client however returns an error 

"ERR Connect failed.WS_ERR(11004), Name lookup - Valid name, no data record 
(mailclnt #356)" 

Which is a complete fabrication: the data record does exist on my own Linux 
server - I can see the record as I type this, and there's also no problem with 
the mail client - it too is a Sourceforge project that's been working fine for 
nearly 15 years and it worked fine with the previous local install of 
Spambayes under W2000S.

Things get worse: the only way to get at the configuration or training pages 
is to run sb_server.py in a local cmd session on the server: this was not 
previously the case, and to run such a cmd session requires that one is logged 
in as a administrator on the server - a less than optimum solution, which once 
again weakens the security of the server.

> Let me know if there definitely are no database files and no configuration
> file.  That would mean that something's going wrong when running with
> defaults and fresh (non-existing) databases, and that means a SpamBayes bug.

As I already said: there were no db and ini files previously - just the proxy 
directory. Those files are now present since I managed to remove the previous 
copy of the application data area. 

Given that I can correctly install this same combination of components to both 
a Windows 2000 Server and an XP workstation, and have it up and working in a 
matter of minutes, and that I'm not altogether inexpert with Windows systems, 
I can only conclude that the problem lies in the interaction of Windows 2003 
and SpamBayes.

I'm begining to wish I'd never even tried this new version. Do please let me 
know what more I can do to help debug this setup.

Sorry if this is a bit lengthy.


More information about the Spambayes mailing list