diff options
Diffstat (limited to 'doc/Old/README.wildmat')
| -rw-r--r-- | doc/Old/README.wildmat | 100 |
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. ++ */ |