[Spambayes] A most peculair problem with SB 1
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
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
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
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
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