1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
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.
+ */
|
