You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by qu...@apache.org on 2004/05/31 07:55:50 UTC
svn commit: rev 20683 - incubator/spamassassin/trunk/rules
Author: quinlan
Date: Sun May 30 22:55:49 2004
New Revision: 20683
Modified:
incubator/spamassassin/trunk/rules/70_testing.cf
Log:
removing T_SPF_PASS_NO_SBL - all of my hits are really spam
Modified: incubator/spamassassin/trunk/rules/70_testing.cf
==============================================================================
--- incubator/spamassassin/trunk/rules/70_testing.cf (original)
+++ incubator/spamassassin/trunk/rules/70_testing.cf Sun May 30 22:55:49 2004
@@ -66,28 +66,6 @@
########################################################################
-# (looks good for T_SPF_PASS_NO_SBL, for everyone except Michael.
-# half of my FNs are misfiled hams! --j.)
-# 0.497 0.1446 2.5959 0.053 0.41 -0.00 SPF_PASS
-# 0.700 0.6002 0.8002 0.429 0.38 -0.00 SPF_PASS:jm
-# 0.880 1.1405 0.6428 0.640 0.23 -0.00 SPF_PASS:parkerm
-# 2.482 0.7534 4.2123 0.152 0.58 -0.00 SPF_PASS:quinlan
-# 0.078 0.0170 12.4542 0.001 0.34 -0.00 SPF_PASS:theo
-# 0.439 0.0774 2.5959 0.029 0.45 -0.01 T_SPF_PASS_NO_SBL
-# 0.425 0.0500 0.8002 0.059 0.54 -0.01 T_SPF_PASS_NO_SBL:jm
-# 0.845 1.0684 0.6428 0.624 0.23 -0.01 T_SPF_PASS_NO_SBL:parkerm
-# 2.285 0.3600 4.2123 0.079 0.65 -0.01 T_SPF_PASS_NO_SBL:quinlan
-# 0.064 0.0030 12.4542 0.000 0.50 -0.01 T_SPF_PASS_NO_SBL:theo
-
-meta T_SPF_PASS_NO_SBL (SPF_PASS && !RCVD_IN_SBL)
-tflags T_SPF_PASS_NO_SBL net nice
-
-# I don't think this one is worth keeping though. not much effect...
-# in fact, most of my hits for this are from forwarders.
-# 6.090 2.3287 28.4943 0.076 0.43 -0.01 T_SPF_HELO_PASS_NO_SBL
-meta T_SPF_HELO_PASS_NO_SBL (SPF_HELO_PASS && !RCVD_IN_SBL)
-tflags T_SPF_HELO_PASS_NO_SBL net nice
-
# after all that work, the best two (which are not great), maybe let the
# perceptron decide between these two before promoting one
header T_MANY_MX_5 From:addr =~ /\@mx\d{2,4}\..{1,20}\./i
Re: svn commit: rev 20683 - incubator/spamassassin/trunk/rules
Posted by Sidney Markowitz <si...@sidney.com>.
Daniel Quinlan wrote:
> For example, it should be required for our default whitelist.
If we add something for SPF as a more flexible form of the recvd check
on whitelist entries, we should also expand the forged_whitelist check.
That is the ideal use of SPF, as a negative test for blocking forgery of
a well known address when we are sure that the domain uses SPF.
-- sidney
Re: svn commit: rev 20683 - incubator/spamassassin/trunk/rules
Posted by Daniel Quinlan <qu...@pathname.com>.
Daniel Quinlan <qu...@pathname.com> writes:
>> missed. We should be attempting to couple SPF pass with specific names.
>> For example, it should be required for our default whitelist.
Theo Van Dinter <fe...@kluge.net> writes:
> I don't know about "required" (we can't force these places to use
> SPF), but if SPF exists we should definitely use it for the whitelist.
We can't force them, but they can't force us to include a whitelist
either. We could easily add a requirement: no SPF, no whitelist.
> Perhaps we should modify whitelist_from_rcvd that instead of
> specifying the Received header we can specify a rulename (ala
> SPF_PASS)? Well, it should have a new whitelist name, but it's the
> idea really ... ;)
>
> Without that, perhaps a meta rule ala:
>
> meta DEF_WL_FORGED USER_IN_DEF_WHITELIST && SPF_FAIL
>
> this is the same idea, but doesn't require SPF records to exist at
> the start.
We need testing for both a negative and a positive rule. I think that a
negative rule will be safer since SPF_PASS falses are not dropping off
as fast as I'd like.
0-1 months old:
1.224 1.3110 0.0144 0.989 0.80 1.00 SPF_FAIL:0-1
0.080 0.0375 0.6749 0.053 0.33 -0.00 SPF_PASS:0-1
1-3 months old:
2.473 3.3886 0.0217 0.994 0.79 1.00 SPF_FAIL:1-3
0.969 0.3478 2.6307 0.117 0.39 -0.00 SPF_PASS:1-3
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: svn commit: rev 20683 - incubator/spamassassin/trunk/rules
Posted by Theo Van Dinter <fe...@kluge.net>.
On Sun, May 30, 2004 at 11:51:25PM -0700, Dan Quinlan wrote:
> I don't think any small set of rules is sufficient. And if you include
> too many rules, then the entire point of having a negative rule is
I agree with this -- SPF_PASS isn't usable as a whitelist since the whole
goal of SPF is to have spammers stop forging, and therefore switch from
SPF_FAIL to SPF_PASS.
> missed. We should be attempting to couple SPF pass with specific names.
> For example, it should be required for our default whitelist.
I don't know about "required" (we can't force these places to use
SPF), but if SPF exists we should definitely use it for the whitelist.
Perhaps we should modify whitelist_from_rcvd that instead of specifying
the Received header we can specify a rulename (ala SPF_PASS)? Well,
it should have a new whitelist name, but it's the idea really ... ;)
Without that, perhaps a meta rule ala:
meta DEF_WL_FORGED USER_IN_DEF_WHITELIST && SPF_FAIL
this is the same idea, but doesn't require SPF records to exist at
the start.
--
Randomly Generated Tagline:
BBSing: Files, folks and fun.
Re: svn commit: rev 20683 - incubator/spamassassin/trunk/rules
Posted by Daniel Quinlan <qu...@pathname.com>.
I'll comment on this before anyone else does. :-)
> Author: quinlan
> Date: Sun May 30 22:55:49 2004
> New Revision: 20683
>
> Modified:
> incubator/spamassassin/trunk/rules/70_testing.cf
> Log:
> removing T_SPF_PASS_NO_SBL - all of my hits are really spam
I don't think any one rule is sufficient to make a simple "does an SPF
record exist" test worthwhile. The test needs to be paired with *actual
domain names* that are known to be good senders.
I took all SPF_PASS hits (318) in the last 14 days of corpus results and
looked at the other rules hit on those spam messages:
318 SPF_PASS <- spammers with SPF records
247 HTML_MESSAGE
239 SPF_HELO_PASS <- both!
197 T_SPF_PASS_NO_SBL
169 URIBL_WS_SURBL
159 RAZOR2_CF_RANGE_51_100
157 URIBL_SBL
134 RAZOR2_CHECK
130 MIME_HTML_ONLY
121 T_SPF_HELO_PASS_NO_SBL
121 RCVD_IN_SBL
114 BAYES_99
112 T_RCVD_IN_SBL
106 URIBL_BE_SURBL
103 T_RATWARE_RCVD_PF_1
98 CLICK_BELOW
... long tail
I don't think any small set of rules is sufficient. And if you include
too many rules, then the entire point of having a negative rule is
missed. We should be attempting to couple SPF pass with specific names.
For example, it should be required for our default whitelist.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/