EADME.wildmat.orig	Wed Dec  3 11:46:31 1997
--- README.wildmat	Wed Dec  3 11:53:33 1997
***************
*** 0 ****
--- 1,50 ----
+ wilmat patch version 0.2 for qmail 1.01
+ Mark Delany <markd@mira.net.au>
+ 19971203
+ 
+ Changes:
+ --------
+ 0.1	Initial code
+ 0.2	Fixed buglet relating to systems that had no badmailfrom file
+ 	but do have a badmailpattern file
+ 
+ While the 'badmailfrom' provides some ability to block spam it is
+ fairly restricted as the match must be exact on either the full string
+ or the domain. This means that it's very difficult to block the
+ 1234567@aol.com type addresses that some spammers are employing as you
+ potentially require a large number of entries in 'badmailfrom'.
+ 
+ This patch provides the ability to use simple patterns to reject mail
+ from unwanted envelope sender addresses. Naturally all such methods
+ are of limited use against spam as a determined spammer cannot be
+ stopped on the current Internet, but it does help until the time comes
+ that we can really stop spammers.
+ 
+ The wildmat patch introduces a new control file called
+ 'badmailpatterns' and is used by qmail-smtpd in conjunction with
+ 'badmailfrom'. You should continue to use 'badmailfrom' when you can
+ as this is much more CPU-efficient than 'badmailpatterns'.
+ 
+ For those familiar with INN, the wildmat patch uses the wildmat()
+ routine out of INN and evaluates in the same way. Namely that the
+ envelope sender is pushed thru all patterns and the final match or
+ non-match is used to determine whether to reject the mail. It's
+ implemented this way so that 'not' patterns work.
+ 
+ Here is a sample 'badmailpatterns' file:
+ 
+ *@earthlink.net
+ !fred@earthlink.net
+ [0-9][0-9][0-9][0-9][0-9][0-9]@[0-9][0-9][0-9][0-9].com
+ answerme@save*
+ 
+ This file stops all mail from Earthlink except from
+ fred@earthlink.net. It also stops all mail with addresses like:
+ 123456@1234.com and answerme@savetrees.com
+ 
+ This patch does not update the documentation or qmail-showctl.
+ 
+ Thanks to Rich Salz for providing wildmat.c by way of the INN
+ distribution. wildmat.c is fast, small and completely self-contained.
+ 
+ --
*** wildmat.c.orig	Wed Dec  3 11:46:31 1997
--- wildmat.c	Wed Dec  3 11:46:31 1997
***************
*** 0 ****
--- 1,172 ----
+ /*  $Revision: 1.1 $
+ **
+ **  Do shell-style pattern matching for ?, \, [], and * characters.
+ **  Might not be robust in face of malformed patterns; e.g., "foo[a-"
+ **  could cause a segmentation violation.  It is 8bit clean.
+ **
+ **  Written by Rich $alz, mirror!rs, Wed Nov 26 19:03:17 EST 1986.
+ **  Rich $alz is now <rsalz@osf.org>.
+ **  April, 1991:  Replaced mutually-recursive calls with in-line code
+ **  for the star character.
+ **
+ **  Special thanks to Lars Mathiesen <thorinn@diku.dk> for the ABORT code.
+ **  This can greatly speed up failing wildcard patterns.  For example:
+ **	pattern: -*-*-*-*-*-*-12-*-*-*-m-*-*-*
+ **	text 1:	 -adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1
+ **	text 2:	 -adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1
+ **  Text 1 matches with 51 calls, while text 2 fails with 54 calls.  Without
+ **  the ABORT code, it takes 22310 calls to fail.  Ugh.  The following
+ **  explanation is from Lars:
+ **  The precondition that must be fulfilled is that DoMatch will consume
+ **  at least one character in text.  This is true if *p is neither '*' nor
+ **  '\0'.)  The last return has ABORT instead of FALSE to avoid quadratic
+ **  behaviour in cases like pattern "*a*b*c*d" with text "abcxxxxx".  With
+ **  FALSE, each star-loop has to run to the end of the text; with ABORT
+ **  only the last one does.
+ **
+ **  Once the control of one instance of DoMatch enters the star-loop, that
+ **  instance will return either TRUE or ABORT, and any calling instance
+ **  will therefore return immediately after (without calling recursively
+ **  again).  In effect, only one star-loop is ever active.  It would be
+ **  possible to modify the code to maintain this context explicitly,
+ **  eliminating all recursive calls at the cost of some complication and
+ **  loss of clarity (and the ABORT stuff seems to be unclear enough by
+ **  itself).  I think it would be unwise to try to get this into a
+ **  released version unless you have a good test data base to try it out
+ **  on.
+ */
