This is draft 4 of the HOWTO-WIN32-SpamAssassin

The main changes

- lotsa syntax corrections
- AutoWhiteList FIXED!
- EventLog options for Spamd included

The remaining issues (but not so big as before)

- Whether the maintainers of SpamAssasin want to integrate this (with
appropriate checks for OS) stuff or whether this should all be
maintained separately. HINT HINT!<g>.
- Spamc, getting a compatible client for Win32
- Razor, workaround for ALARM
- SpamProxy hasn't been tested and probably will never work. A lot of
the modules req'd don't operate on Win32. However, one could write a
VB or C SMTP proxy and just use the spamc code (if this ever comes to
fruition).
- nmake TEST doesn't work. How much anyone cares is a good question.
Looks like it would be a pain to fix, but maybe not.


I will finally post this on the web shortly after any comments, and
post the URL here.

mike

USING SPAMASSASSIN WITH WIN32

Draft 4, [EMAIL PROTECTED]

THE BUILDS WE USED

ActivePerl Build 631 (1/2/02) 
SpamAssassin 2.11
SpamAssassin 2.20 (reported by others to work)
Razor Agents 1.19

These were tested on Win98SE, Win2000, WinNT.


LIMITATIONS:

1. SPAMC is not currently compiled for Win32, so
spamassassin must be run in "serial mode".

2. Razor is unreliable, and needs a workaround for ALARM.

3. spamproxy untested. It looks like it isn't gonna work with Win32
though.

4. nmake TEST always fails.

5. A few installation quirks, which are covered below

But it does work very well within these parameters!



WARNING: DON'T USE WINDOW 9x/ME FOR SPAMASSASSIN!

Use WinNT/2K/XP ONLY. Preferably with NTFS volumes.

It IS possible to get it running on Win9x, but Perl acts unreliably
on such platforms. During install you will find all kinda weirdisms.
The primary one being every time PL2BAT calls, it will fail. You'd
have to run these all manually (not a big deal) and hit CTRL-Z
everytime the install "hangs" with NMAKE. Many more weirdisms (fork
doesn't work well, or flock or link/unlink) make Win9x not the way to
go.

PART I: Installing Perl

1. This is very easy. Go to http://www.activestate.com, and select
the ActivePerl
download. Choose the MSI installer version.

NOTE: If you have to use the NON-MSI version, that's fine. Download
it, unzip it
and run INSTALLER.BAT. It mostly works the same.


2. Double click the MSI file and run it. All of the default options
are fine.
Don't worry if the Perl installer seems to take a really long time.
Wait
at least 10 minutes before worrying.

3. Open a DOS box and type PERL -V to verify all is well.

4. In subsequent sections, it will be assumed that Perl was installed
in C:\perl. Make appropriate changes if necessary.

PART II: Installing NMAKE

1. We need NMAKE to build Perl modules
2. Obtain from ftp://ftp.microsoft.com/Softlib/MSLFILES/nmake15.exe
3. Extract the files, and place them in C:\perl\bin

PART III: Installing the needed Modules, part I.

We do this using the Perl Package Manager, rather than CPAN when
possible, as it downloads the best versions for Win32.

Basic method of operation:

1. open dos box.
2. Type PPM
3. At the PPM> prompt, type install <modulename>
4. To exit PPM, type QUIT, when you are done
For SpamAssassin itself, we need only one module, Net::DNS,
so we'd type install Net::DNS 

In the RAZOR section, we'll discuss installing a few more
modules.

Part IV: Obtaining Spam Assassin

Go to http://www.spamassassin.org, choose download, and get
the ZIP file distribution.

Use WinZIP or other ZIP extractor, and extract the ZipFile 
off the root. For SpamAssassin 2.11, for example, this will
create Mail-SpamAssassin-2.11 off C:\

We'll refer to this directory as the SPAMSOURCE directory
below.

PART V: Pre-install

Open a DOS box, go to the SPAMSOURCE directory and type

PERL windows_install.pl (This probably isn't at all useful actually.
I think it is for
the Cygwin folks)
PERL makefile.pl

PART VI: Getting the NMAKE to work, Part I

Here's where we start to see quirks, most of them easy to fix.
We will go through each error message one by one until the NMAKE
compiles.
(The main reason to do this is to achieve better understanding what
works and what doesn't, so if a new branch of SpamAssassin changes
things...)

1. Open a dos box and go to the SPAMSOURCE directory.
2. Type NMAKE
3. It will fail, complaining that TOUCH cannot be found. It may also
complain about
spamd/spamc.

REASON: TOUCH isn't a Windows command. Also genning the HTML docs
from
the POD file confuses the Windows command interpreter

WORKAROUND THIS: Open MAKEFILE (SPAMSOURCE directory) in NotePad, and
find

pm_to_blib: spamassassin doc/.made

Change it to

pm_to_blib: spamassassin

which will skip this section. (See CLEANING UP THE QUIRKS). Save the
file.

4. Try NMAKE again!
5. It will (most likely) fail again, complaining that CL is not
recognized.

REASON: One component of Spamassassin is spamc, the client piece of a
neato way to really
speed up SpamAssassin. But most of us don't own Visual C++, and so we
don't have a C compiler handy.
Unix people have life easy :)

WORKAROUND: Well, if you really need spamc, you gotta get a C
compiler. Otherwise, 
open MAKEFILE in Notepad again, and find

        $(CFCC) $(CFCCFLAGS) $(CFOPTIMIZE) spamd/spamc.c \
                        -o $@ $(CFLDFLAGS) $(CFLIBS)

Comment these lines out by placing a # character at the BEGINNING of
each line. Please re-read
the last sentence - if # isn't the very first character the line will
NOT be commented out
properly.

6. Run NMAKE again. It should complete (the error about
blib\script\spamc is fine, and occurs
because we never compiled spamc)

PART VII: Getting NMAKE to work, Part II

Here we get NMAKE INSTALL to work properly. NMAKE TEST will never
work, 
as there are too many whacked modules at this point. Oh well.

1. Open a DOS box and go to SPAMSOURCE directory.
2. Type NMAKE INSTALL
3. You will see a failure right after the mkdir -P command

REASON: 3 issues come up now. The first is that mkdir -P has no
analogue. We'll
use MKDIR instead. Second some of the paths for the rule directories
won't work
as is. Finally, some of the installation routines will not work to
copy configuration files, so we need to work around that too!

WORKAROUND 1: Open MAKEFILE, and change all mkdir -P command to
simply mkdir
(eg     mkdir -p $(DEF_RULES_DIR) to mkdir $(DEF_RULES_DIR)

WORKAROUND 2: Also, find

DEF_RULES_DIR   = $(PREFIX)/share/spamassassin
LOCAL_RULES_DIR = /etc/mail/spamassassin

and change them to

DEF_RULES_DIR   = $(PREFIX)\share\spamassassin
LOCAL_RULES_DIR = \etc\mail\spamassassin

WORKAROUND 3: Finally, change these lines

inst_cfs: $(LOCAL_RULES_DIR) $(DEF_RULES_DIR)
$(DEF_RULES_DIR)/user_prefs.template 
$(LOCAL_RULES_DIR)/local.cf migrate_cfs
        for file in $(RULES) ; do \
          $(CP) rules/$$file $(DEF_RULES_DIR)/$$file; \
        done

$(DEF_RULES_DIR)/user_prefs.template: rules/user_prefs.template
        $(CP) rules/user_prefs.template $(DEF_RULES_DIR)/user_prefs.template

$(LOCAL_RULES_DIR)/local.cf: rules/local.cf
        [ -f $(LOCAL_RULES_DIR)/local.cf ] || $(CP) rules/local.cf
$(LOCAL_RULES_DIR)/local.cf

migrate_cfs:
        [ ! -f /etc/spamassassin.cf ] || $(MV) /etc/spamassassin.cf
/etc/mail/spamassassin/migrated.cf
        [ ! -f /etc/mail/spamassassin.cf ] || $(MV)
/etc/mail/spamassassin.cf /etc/mail/spamassassin/migrated.cf

to

inst_cfs: $(LOCAL_RULES_DIR) $(DEF_RULES_DIR)
$(DEF_RULES_DIR)/user_prefs.template 
#$(LOCAL_RULES_DIR)/local.cf migrate_cfs
#       for file in $(RULES) ; do \
#         $(CP) rules/$$file $(DEF_RULES_DIR)/$$file; \
#       done

$(DEF_RULES_DIR)/user_prefs.template: rules/user_prefs.template
        $(CP) rules/user_prefs.template $(DEF_RULES_DIR)/user_prefs.template

$(LOCAL_RULES_DIR)/local.cf: rules/local.cf
        [ -f $(LOCAL_RULES_DIR)/local.cf ] || $(CP) rules/local.cf
$(LOCAL_RULES_DIR)/local.cf

migrate_cfs:
#       [ ! -f /etc/spamassassin.cf ] || $(MV) /etc/spamassassin.cf
/etc/mail/spamassassin/migrated.cf
#       [ ! -f /etc/mail/spamassassin.cf ] || $(MV)
/etc/mail/spamassassin.cf /etc/mail/spamassassin/migrated.cf

(We are basically commenting out sections that would fail to copy
files correctly. Don't worry - it's groovy)


4. Run NMAKE INSTALL - all should be well now.

PART VIII: CLEANING UP THE QUIRKS

1. First, manually copy the files in rules directory to
\etc\mail\spamassassin, which should
now exist. This copies the default rules nicely. This is NEEDED for
SpamAssassin
to work.

2. Next, find \perl\bin\spamasasssin.bat, and add at the beginning
SET RES_NAMESERVERS=ipaddress , where ipaddress is the ipaddress of
your DNS server. If you
have more than one, add additional ones, separating with a space
character.
This is needed for all RBL lookups - the Net::DNS module is not
currently capable of checking
the Windows registry, so we have to "help it"

3a. Open up NotePad, and type this in:

REM Run from the top of the Spam Assassin install directory
mkdir \spamdocs
call pod2html spamassassin. --outfile \spamdocs\spamassassin.html
call pod2html spamd\spamc.pod  --outfile \spamdocs\spamc.html
call pod2html spamd\spamd. --outfile \spamdocs\spamd.html
call pod2html spamproxy\spamproxyd. --outfile
\spamdocs\spamproxyd.html
call pod2html lib\mail\spamassassin\conf.pm --outfile
\spamdocs\conf.html
call pod2html lib\mail\spamassassin\permsgstatus.pm --outfile
\spamdocs\permsgstatus.html
call pod2html lib\mail\spamassassin\persistentaddrlist.pm --outfile
\spamdocs\persistentaddrlist.html
call pod2html lib\mail\spamassassin\smtp\smarthost.pm --outfile
\spamdocs\smarthost.html
call pod2html lib\mail\spamassassin.pm --outfile
\spamdocs\spamassassinclass.html

3b. Save this file as POD.BAT in the SPAMSOURCE directory.
3c. Open a DOS box, go to SPAMSOURCE and type POD. This will generate
the HTML docs for SpamAssassin, and
place them in \spamdocs. This works around the faulty TOUCH/POD2HTML
script issues we originally
disabled.

4a. Ok, we will try a test. It will fail, proving life is weird <g>.
>From the SPAMSOURCE
directory, type 

PERL -S "spamassassin" -P < sample-spam.txt

I'll bet you you will get a "getpwuid is unimplemented" error.

4b. Fixing this isn't too bad. Go to \perl\site\lib\mail. You'll find
spamassassin.pm. It will be
read-only (change this). Open it in Notepad and find

   return (getpwuid($>))[7];

change this to

#  return (getpwuid($>))[7];

PART IX: TESTING

Create a temporary directory called TEST off the root. Copy the
sample-spam.txt and sample-nonspam.txt
files from the SPAMSOURCE directory.

Open a DOS box.

1. Type

spamassassin -P -D -t < sample-nonspam.txt > nospam.txt

This should run fine, and when you look at nospam.txt the report
should be hunky dory.

2. Type

spamassassin -P -D -t < sample-spam.txt > spam.txt

This should run fine and the report should label this as spam.
Note the RBL check should register as spam as well.


PART X: USAGE

- You can process any MIME message by typing

spamassassin -P < inputfile > outputfile

- Adding a -e switch will set the ERRORLEVEL to non-zero for spam!
Can you say "batch file"?
- The -D switch adds very helpful debug comments.
- The -t switch is TEST mode. All mail will have a report appended.
It is
good, to see what the report comes up with on non-spam stuff.

- only free RBL lists are on by default. See the SPAMSOURCE README
for more
details on this, and the \spamdocs\conf.html file.

- You can set your own preferences by editing the USER_PREFS file
in .spamassassin. Use the settings documented in \spamdocs\conf.html
(this is how you can manually add/remove whitelist/blacklist
settings,
turn off RBL, change the score value of something etc). 
In general, if at all possible use THIS file, instead
of editing the global config files in \etc\mail\spamassassin. That
way,
the next time you update SpamAssassin, you won't have to merge
your changes with the new global config files. Of course, you'll
need to look at the global config files to know what parameters to
change!

Here's some examples (none of them recommended by default - this is
for
illustration purposes)

# Sample USER_PREFS
#
#
# This one says if it's FROM bill, it CAN't be spam!
whitelist_from  [EMAIL PROTECTED]
# This one changes the default of MAPS (off, because you can't use it
for free, to on)
score RCVD_IN_RBL                    1.0
# Mail that is pure HTML is normally given a score of 4.5 (and since
the default
# threshold to mark as spam as 5 this could be a problem. We change
that below
score CTYPE_JUST_HTML                2.0
# And that spam threshold of 5 is too harsh and flags stuff as spam
incorrectly
# too often! Let's make it 7.5!
required_hits 7.5
# Finally, we like Russians. They use BASE64 text all the time,
because of their
# whacky character set, and SpamAssasin marks this as likely spam
(score=3.2).
# Let's change that
score BASE64_ENC_TEXT                0.00



HERE ENDS WHAT I CONSIDER THE "MAJOR FUNCTIONALITY" ISSUES. 

Below, I discuss some of the remaining lingering issues, and how to
at least partially resolve them.

Proceed with caution! Don't bother continuing if you don't feel
comfortable with hacking.


PART XI: AUTOWHITELIST DOESN'T WORK

The Auto-WhiteList is a neat optional piece of SpamAssassin. With the
feature enabled, people who send non-spam are added to the
"whitelist" - meaning they become increasingly less likely to have
their mail falsely flagged as spam.  Each time the address is
referenced, it gets weighted a bit more in one direction or the
other.
It's kinda cool that SpamAssassin can "learn" as it goes along. It's
activated with the -a switch, and the database file is stored in
\.spamassassin . 

Unfortunately, as written, it DOES NOT work on Win32. The
STATS/LINK/UNLINK functions of the NFS-Safe Locking in
DBBasedAddrList.PM go down in flames on Win32 (always tries 30 times
to get the lock, finds it stale and then fails). While one could
simply disable that portion of the code, it would of course only be
reliable if only one instance of SpamAssassin were accessing the
database at one time. A most unsafe assumption, and not one that I'd
make.

If this is not addressed, you'll have to manually add whitelisted
addresses to the configuration files.
This is a little more tedious unfortunately, and there's no weighted
learning (the
score for the manual whitelist is -100 or so, so chances are
everything will be
accepted from that source). See the usage notes in Part X for hints
on how to do this.

Fortunately, there is a solution. However, no guarantees are made as
to the stability/functionality
of this fix. Use ONLY if you feel very comfortable hacking around. Do
note that this would not
be a good solution for Unix based platforms (which should run fine
with the default code), as it is
NOT NFS-Filelock safe. Don't worry about what that means.

1. We need to edit
\perl\site\lib\Mail\Spamassassin\DBBasedAddrList.PM, which is
normally read-only. Make it
read-write, and open it in Notepad

2. Make these changes to the new_checker subroutine:

2a. Change 
        open(LTMP, ">$lock_tmp") || die "Cannot create tmp lockfile
$lock_file : $!\n"; 
    to 
        open(LTMP, ">$lock_file") || die "Cannot create tmp lockfile
$lock_file : $!\n";

2b. IMMEDIATELY after this line, insert these 3 lines:

      dbg("$$ Trying to get lock");
      flock(LTMP, LOCK_EX) or die "flock failed for $lock_file";
      dbg("$$ got lock");
      $self->{is_locked} = 1;

2c.  Comment out ALL of the next 20 or so lines, until just before
the line
beginning with:
        
        if ($self->{is_locked})

(in other words all the way through the close and unlink statements).

3. Make these changes to the finish subroutine:

3a. Change

       unlink($self->{lock_file}) ||
          dbg ("Couldn't unlink " . $self->{lock_file} . ": $!\n"); 
    to
       close LTMP ||
          dbg ("Couldn't unlink " . $self->{lock_file} . ": $!\n");

(The implementation above will freeze the currently running thread of
SpamAssassin until it get the lock.
A better implementation of all this would use the flock with the
LOCK_NB combination
and try over and over for 30 seconds at 1 second intervals, before
failing over to the read-only code. This would be pretty easy to
change)

PART XII: SPAMC (and thus SPAMD) DOESN'T WORK

You need a C compiler  to compile spamc.c. I've tried a few, and they
didn't
work because many of the libraries are unix-centric. I'm planning to
try
to write a simple open source VB solution. C would be better if
someone
would contribute this - the protocol is simple and defined in the
README
for SPAMD, and should be trivial for any one with some TCPIP
experience.

SpamC would be nice to get working. With it, you load the PERL
libraries only once
instead of EACH time a file is processed. Then SpamC calls Spamd via
TCPIP (so they assumedly don't have to be on the same machine). Much
more efficient for heavy mail processing. Considerably less memory
intensive.

Spamd itself I've got working, sort of.  I think though it needs
SERIOUS testing though. It certainly has a nasty habit of GPFing or
closing weirdly on me occasionally.

1. Go to \perl\bin\spamd. and comment out these lines (we need to do
this because ActivePerl
can't handle SYSLOG at all well):

use Sys::Syslog qw(:DEFAULT setlogsock); (near beginning of file)
setlogsock('unix'); (middle of code)

2. Change  my $uid = gwpnam('nobody'); to  my $uid = 'nobody'; 
(this occurs twice, and we do this because gwpnam is not available on
Win32)

3. Comment out all the lines inside the logmsg subroutine (which
reference the nonexistent SYSLOG daemon) and replace them with

print "\r\n";
print "@_";

A much better thing to do would be to send this to Win32::EventLog.

I believe that this can be done with (untested, and just hacked out
mentally):

# insert at beginning of code
use Win32::EventLog;

# replace current logmsg routine with these lines
my $EventLog;
my %event=(
        'EventID',9999,
        'EventType',EVENTLOG_INFORMATION_TYPE,
        'Category',NULL,
        'Strings','@_',
        'Data','SpamAssassin',
);

$EventLog = new Win32::EventLog( 'SpamD' ) || die $!;
$EventLog->Report(\%event) || die $!;
$EventLog->Close;

4.  Comment out these lines:

                logmsg "Still running as root: user not specified, ".
                    "not found, or set to root.  Fall back to
nobody.";

Otherwise "odd" things will occur. You won't like them.

PART XII: RAZOR

Well, this is a bit of a pain, and I doubt it will work reliably. 

Fortunately it is optional.

Here are the considerations

1. To install, begin by installing all of SpamAssassin and getting
everything working nicely. Don't proceed with this section until
everything else works well!

2. Go back to PPM, and install these additional modules

Net::Ping
Time::HiRes
Digest::SHA1

2. You will also need to install Mail::Internet, which is not
currently available via PPM right now. Time to use CPAN, a much less
friendly (to Windows users) utility. Open a DOS box, type

perl -MCPAN -e shell

You will be asked some fairly frightening and confusing questions.
Ignore them, and mindlessly hit RETURN, until you are asked for some
URLS to download stuff from. Choose some random sites. (Do make sure
that NMAKE is recognized as being in \PERL\BIN when you are asked for
your MAKE program though).

Eventually you'll be at the CPAN> prompt again, from which you type
install Mail::Internet, and all is hopefully well. You can then QUIT
from CPAN.

3. Download the RAZOR package from razor.sourceforge.net, and ungzip
and untar it (WinZip works
well for this). Place the main package off the root.

4. Build it. Go to the Razor-subdirectory and type these commands in
order:

perl makefile.pl
nmake
nmake test
nmake install

It should all go pretty well.

5. Type razor-check at the DOS prompt. If you are unlucky like me,
you'll get an "alarm
function unimplemented in ping.pm". This isn't such a big deal - we
installed a working
Net::Ping library back in Part III (it's installed at
\perl\site\net\ping.pm). But the
ActivePerl distribution comes with the BAD version of PING as the
default. Let's fix that.
Go to \perl\lib\Net and rename ping.pm to badping.pm 
and all should be well (hopefully this working ping will be
integrated into the core
shortly).

6. Now we come to a bigger problem. The ALARM function is also used
in SpamAssassin's razor
lookup function. While we can disable it (and will), this might be a
bad idea, as it could
lead to "odd" timeouts and hangs if the razor server isn't up. So do
at your own risk!

The problem ALARM functions are located in
\perl\site\lib\mail\spamassassin\dns.pm . There are two of them and
they need to be commented out with a # at the beginning of the line.
If they are not, SpamAssassin will run fine, but ALWAYS time-out on
the RAZOR check. (Which would defeat the purpose of bothering to
install Razor!)

The ALARM function is also used in
\perl\site\lib\mail\spamassassin\reporter.pm, when the RAZOR agents
are contacted to report the Spam (optional -R switch). Similar
workaround/problems there.



__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to