add sqmail-4.2.29asqmail-4.2

1 files changed, 100 insertions, 0 deletions

diff --git a/doc/Old/README.wildmat b/doc/Old/README.wildmat
new file mode 100644
index 0000000..ccfbe0e
--- /dev/null
+++ b/doc/Old/README.wildmat
@@ -0,0 +1,100 @@
+/* THIS FILE IS INCLUDED FOR HISTORICAL REASONS ONLY */
+
+
+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.
++ */