Hi Simon,
I could never get razor2 to compile and run properly in native Windows.
I did get pyzor to work, sort of, but it would periodically hang without
any error and cause the server to just sit there and wait forever. I
never did track that down, just ended up disabling pyzor.
If you'd like to run pyzor, or any other helper that requires launching
a program, there's a simple change you need to make to util.pm in the
sub helper_app_pipe_open_windows. There's a space between the < (pipe in
character) and the " (quote). Windows server doesn't allow space between
the pipe character and the filename that you're piping in, so the invoke
fails. Removing the space fixes that. (I should have opened yet another
bugzilla item for this, but since none of the popular plugins work on
windows anyway, I never went back to clean up this last helper app call
issue.) It's one of two changes I make before I install every version of
SA. The other is for using MS SQL for bayes.
Usual location information when running SA under ActivePerl for Windows:
c:\perl\site\bin = where the commands are installed to execute
spamassassin from the command line
c:\perl\site\lib\mail\spamassassin = where the perl modules get installed
c:\perl\html\site\lib\mail\spamassassin = where the documentation gets
installed
c:\perl\site\etc\mail\spamassassin = where your local configuration
files reside, these are the ones you change to configure it. Note that
SA loads every .pre and .cf file in this directory. If you need to make
backups, either put them in a subdirectory or change the extension--
otherwise they get loaded too. This is also the directory where you can
put any add-on rules that aren't being updated with sa-update.
Generally, files get loaded in alphabetical order, first all the .pre
files, then all the .cf files.
c:\perl\site\share\spamassassin = where the initial default rules are
installed, you should never modify these
c:\perl\site\var\spamassassin\version# = where sa-update installs rules,
these override the default rules, you should never modify these
There are other directories that matter, but those largely depend on how
you are calling SA, and should be documented in whatever application is
used.
If do decide to try pyzor or other plugins that rely on hashing
algorithms, you'll want to track stats on their effectiveness. Without
that you'll never know whether the algorithm accounts for the line
ending difference between linux and windows. At least some of the
algorithms do not and you'll never see a hit on any message because of
that. That is, the crlf vs lf means the hash number is different between
linux and windows and therefore messages never get seen as spam. I do
not know whether the razor or pyzor algorithms account for that difference.
Bret
On 10/19/2008 11:41 AM, simonmason wrote:
Thanks I fixed all of these. Now I am going to try and figure out razor2 and
python under windows. I haven't seen any good how-tos on this?
Gary V wrote:
Just a couple things that stuck out for me. This is not an extensive
evaluation.
[4028] warn: config: failed to parse line, skipping, in
"C:\Perl\site/etc/mail/spamassassin/local.cf": use_dcc 1
Remove use_dcc from local.cf. This in a plugin that is turned on or
off in V310.pre.
dbg: config: read file C:\Perl\site/etc/mail/spamassassin/Copy (2) of
local.cf
dbg: config: read file C:\Perl\site/etc/mail/spamassassin/Copy of
local.cf
SA will parse any file with a .cf file extension in the pertinent
directories. To avoid unexpected results, use a different file
extension for backup copies of .cf files (.old for example).
Gary V
