Patch made by Sten Donslund <sten@stjernedrys.dk>
I have done a lot of 370 and 390 (IBM mainframe) assembler programming,
but I'm no C-shark, so forgive me if I've messed something up.
Anyway, thank's to Staffan's work, I've now got a mail-filter that
perfectly fits my needs.

BEFORE dealing with this patch and the changes in it:

READ THE DOC THAT STAFFAN HAS WRITTEN, otherwise this will probably
look like "Bad drugs at Poughkeepsie" to you.


!!!! The changes can be applied as a patch to the 2.02 code, ONLY. !!!!


Place the spamfilter.c and the spamfilter.diff, in the same directory
and use the command:
patch -ie -o spamfilter.patched spamfilter.c spamfilter.diff

and you will have the changes applied, in the spamfilter.patched file.

MAKE SURE to change the basedir variable to your needs, before running
make. Read the documentation below! Assuming you have read Staffans doc, else:
START THERE.

Either copy the .patched file to .c file and run make, or change the
Makefile and run make.


The changes I have made:

Definition of the homedir:
					Substitute /home/antispam/ if needed
					Dont forget the terminating "/"
					Make sure the maildaemon can write
					to the directory and read the files.
	The variable:
	char *basedir="/home/antispam/"

	appended with the contents of the variable:
	ext

	points to the directory, where the config files resides,
	and where the maillog, killedmail and tempfiles will be written.


You still have to put, the .qmail where it belongs, somewhere
in the qmail directory, as described in Staffans doc.

Because I've moved the configfiles out of the QMAIL-dir, I've renamed
them to:
.allow		==>	allow
.deny		==>	deny
.isdirect	==>	receive
.subject	==>	subject
.spam-config	==>	spam-config
.spam-message	==>	spam-message
and I have removed the preceding "." on the log, kill and tempfiles.

I have changed the code, in the following ways:

Added a REPORT parameter, which, if set to yes, will print to the maillog
what has happened, independently of the debug parameter.

I needed to see the various flags, when I was working on the code, so I
added a trace() routine, that can be called, if some debugging is needed.
Just add "trace()" to the code, where you want the flags displayed.
The routine will print to /$home/trace

Changed what is performed in the different filechecks, as follows:
	allow and deny files contents is checked only against the
	the sender of the message.

	receive file contents is checked only against the contents
	of the To: and the Cc: fields.
	Like .isdirect, before.    I think, I'm no C-shark!

The subject file contents is still checked against the Subject: field
contents.

The logic in the decision part has changed.

The decision on what to do with the message is performed in the following
way:
	First, the action to take, if no match is found in the filechecking
	routines, is set up with the "DEFAULT_xxxxx" parameters. The value
	can be DROP or PASS. The message will be bounced or passed to the
	receiver.
Motivation:
This makes it possible, to turn the contents of the config files into
positive or negative lists, individually for each file.


	The order of decisions is given by the order of which, the files are
	written in the config file. (ALLOW, DENY, RECEIVE and SUBJECT)
Motivation:
Combined with the different parameters, this gives a tremendous flexibillity.


	When A MATCH IS FOUND, the "DROP" and "PASS" values, tells the filter
	what to do with the message. And the the "STOP" and "CONTINUE"
	values, tells the decision routine, to stop further checking and
	keep with the current decision or to continue checking the rest
	of the comparising results.


CONDENSED:
The DEFAULT values, tells the decision-routine what to do, if NO match is
found in the files.
The value of ALLOW, DENY, RECEIVE and SUBJECT parameters, tells what to do
if a match IS found, in the given file, and the STOP/CONTINUE values instructs
the routine to stop or continue scanning the flags, still, if there's a match.


