You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jari Fredriksson <ja...@iki.fi> on 2009/10/09 16:58:06 UTC
Incresing numbers of DCC_CHECK in ham
This looks worrying. I have it at 2.2 pts, and not caused any false positives, but still, odd. Or is it? I know it is a SPAM indicator but a bulk indicator.
But it is triggered for example by some mailing list posts which are genuine and not bulk.
Is someone trying to poison DCC?
sa-stats:
Email: 967 Autolearn: 683 AvgScore: 12.63 AvgScanTime: 11.85 sec
Spam: 501 Autolearn: 408 AvgScore: 32.08 AvgScanTime: 9.91 sec
Ham: 466 Autolearn: 275 AvgScore: -8.27 AvgScanTime: 13.95 sec
Time Spent Running SA: 3.18 hours
Time Spent Processing Spam: 1.38 hours
Time Spent Processing Ham: 1.81 hours
TOP SPAM RULES FIRED
----------------------------------------------------------------------
RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
----------------------------------------------------------------------
1 BAYES_99 494 51.09 98.60 0.00
2 DCC_CHECK 482 60.19 96.21 21.46
3 RAZOR2_CHECK 482 49.95 96.21 0.21
4 RAZOR2_CF_RANGE_51_100 480 49.64 95.81 0.00
5 DIGEST_MULTIPLE 472 48.91 94.21 0.21
6 RCVD_IN_BRBL_RELAY 466 50.16 93.01 4.08
7 BOTNET 463 47.88 92.42 0.00
8 URIBL_BLACK 450 46.85 89.82 0.64
9 URIBL_SBL 448 46.33 89.42 0.00
10 RAZOR2_CF_RANGE_E8_51_100 448 46.33 89.42 0.00
11 HTML_MESSAGE 443 52.12 88.42 13.09
12 URIBL_JP_SURBL 378 39.09 75.45 0.00
13 URIBL_WS_SURBL 324 33.51 64.67 0.00
14 URIBL_AB_SURBL 305 31.54 60.88 0.00
15 RCVD_IN_BL_SPAMCOP_NET 297 31.02 59.28 0.64
16 RDNS_NONE 286 29.58 57.09 0.00
17 MIME_HTML_ONLY 273 29.89 54.49 3.43
18 RAZOR2_CF_RANGE_E4_51_100 201 20.79 40.12 0.00
19 URIBL_OB_SURBL 175 18.10 34.93 0.00
20 URI_HEX 137 14.48 27.35 0.64
----------------------------------------------------------------------
TOP HAM RULES FIRED
----------------------------------------------------------------------
RANK RULE NAME COUNT %OFMAIL %OFSPAM %OFHAM
----------------------------------------------------------------------
1 BAYES_00 422 43.64 0.00 90.56
2 AWL 318 35.06 4.19 68.24
3 RCVD_IN_DNSWL_LOW 131 13.55 0.00 28.11
4 DCC_CHECK 100 60.19 96.21 21.46
5 RCVD_IN_DNSWL_HI 84 8.69 0.00 18.03
6 DKIM_SIGNED 79 9.31 2.20 16.95
7 RCVD_IN_DNSWL_MED 70 7.34 0.20 15.02
8 HTML_MESSAGE 61 52.12 88.42 13.09
9 DKIM_VERIFIED 39 4.03 0.00 8.37
10 RCVD_IN_BRBL_RELAY 19 50.16 93.01 4.08
11 MIME_HTML_ONLY 16 29.89 54.49 3.43
12 MIME_HTML_MOSTLY 13 1.34 0.00 2.79
13 MIME_QP_LONG_LINE 13 2.17 1.60 2.79
14 USER_IN_DKIM_WHITELIST 12 1.24 0.00 2.58
15 HABEAS_ACCREDITED_SOI 8 0.83 0.00 1.72
16 OBFUSCATING_COMMENT 8 0.83 0.00 1.72
17 MPART_ALT_DIFF 8 0.83 0.00 1.72
18 RCVD_IN_BSP_TRUSTED 8 0.83 0.00 1.72
19 SARE_UNI 8 3.72 5.59 1.72
20 SARE_SPEC_LEO_LINE03a 8 0.83 0.00 1.72
----------------------------------------------------------------------
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
Thank you all guys, on list and especially off list.. You know who you are.
Thanks. I Put this to the list because I have certain difficulties to write a letter to each of you separately.
Thanks.
Re: Incresing numbers of DCC_CHECK in ham
Posted by Michael Scheidell <sc...@secnap.net>.
Jari Fredriksson wrote:
> This looks worrying. I have it at 2.2 pts, and not caused any false positives, but still, odd. Or is it? I know it is a SPAM indicator but a bulk indicator.
>
> But it is triggered for example by some mailing list posts which are genuine and not bulk.
>
>
and, fyi, if you have the commercial version of dcc, and not using
mark's new DCC.pm from the 3.0 alpha, the commercial version might
trigger a 'hit' if the reputation of the sending ip is > 20%
(as in, 20% bulk rate)
and, yes, you are ALWAYS told to whitelist your legit marketing lists
for dcc. either by ip, or something that can't be forged.
as an example, this mailing list scores 3%
http://www.rhyolite.com/cgi-bin/reps.cgi?tgt=140.211.11.3
MOSTLY BECAUSE THE SA ADMINS READING THIS LIST, either whitelisted the
list or don't use DCC.
(which still shows that 3% of you are still reporting this list as
'bulk'. )
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
_________________________________________________________________________
Re: Incresing numbers of DCC_CHECK in ham
Posted by LuKreme <kr...@kreme.com>.
On 9-Oct-2009, at 08:58, Jari Fredriksson wrote:
> triggered for example by some mailing list posts which are genuine
> and not bulk.
Mailing list messages are the very definition of bulk.
Precedence: bulk
--
If I were you boys, I wouldn't talk or even think about women.
'T'ain't good for your health.
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jeff Mincy <je...@delphioutpost.com>.
From: "Jari Fredriksson" <ja...@iki.fi>
Date: Fri, 9 Oct 2009 20:44:09 +0300
> DCC identifies mail that has been sent often. That's what
> the rule checks for, if other recipients have seen it,
> too.
>
> You voluntarily installed DCC, knowing SA will use it.
> This was on your discretion, and it's your duty to
> evaluate if it actually is, what you want.
>
> [1] Once, mind you. Which is what DCC does, counting. The
> "report spam" option in SA reports it differently as
> many.
1. So what is DCC good for?
DCC is extremely good at detecting bulk messages. All or nearly all
spam messages are bulk.
2. Why does SpamAssassin use it?
DCC is a separately configured plugin that does not run unless
configured to do so at each SpamAssassin site.
3. Should I uninstall DCC if I want to get bulk but not Spam?
You should whitelist legitimate bulk email in the DCC whiteclnt file.
Or you could bypass SpamAssassin for mailing lists. You could lower
the DCC_CHECK score. Or you could disable or uninstall DCC.
4. Question 2. again. SpamAssassin is about Spam, but I really need
to receive bulk, as in mailing lists and newspaper posts. Are
there people do not want any mail but what their friends send
them, and that is the purpose of DCC?
If you use DCC you have to whitelist legitimate sources of bulk email.
5. What special does the "Report to DCC" SpamAssassin function do for our good?
Using "Report to DCC" reports the message to DCC with a count of many.
After that everybody else querying the same message will get a count
of many.
-jeff
Re: Incresing numbers of DCC_CHECK in ham
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 20:44 +0300, Jari Fredriksson wrote:
> 1. So what is DCC good for?
Identifying bulk. And to some high extent, spam, by that measure.
> 2. Why does SpamAssassin use it?
SA *optionally* uses it, if you want it to. SA offers this choice,
because it happens to be a good spam measure for some.
> 3. Should I uninstall DCC if I want to get bulk but not Spam?
As with *all* optional stuff, and less so with stock, you need to
investigate if it applies to your particular mail in-stream. If it
doesn't suit your environment, don't use it.
> 5. What special does the "Report to DCC" SpamAssassin function do for our good?
This has been explained twice. An explicit report as spam adds much more
weight to the count, than a plain query does. The latter is merely an
implied "seen once".
(Which frankly, if you think about it, always holds true. If you query
for $something, it is a dead give-away you have seen $something, no?)
> Confused.
Yeah, I can see that. :)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
> DCC identifies mail that has been sent often. That's what
> the rule checks for, if other recipients have seen it,
> too.
>
> You voluntarily installed DCC, knowing SA will use it.
> This was on your discretion, and it's your duty to
> evaluate if it actually is, what you want.
>
>
> [1] Once, mind you. Which is what DCC does, counting. The
> "report spam" option in SA reports it differently as
> many.
1. So what is DCC good for?
2. Why does SpamAssassin use it?
3. Should I uninstall DCC if I want to get bulk but not Spam?
4. Question 2. again. SpamAssassin is about Spam, but I really need to receive bulk, as in mailing lists and newspaper posts. Are there people do not want any mail but what their friends send them, and that is the purpose of DCC?
5. What special does the "Report to DCC" SpamAssassin function do for our good?
Confused.
Re: Incresing numbers of DCC_CHECK in ham
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 19:51 +0300, Jari Fredriksson wrote:
> This is hebrew to me. I know nothing about DCC, I have just installed
> it and let SpamAssassin care the details.
> The problem I see here, is that especially Debian mailing list posts
> get a DCC hit, and once I just joined those lists, my SA statistics
> went ballistic with DCC_CHECK. I guess Debian lists are wide spread,
> but I do not see why DCC hits if the posts are not *reported*.
They are reported [1] -- by querying, as you say yourself.
> Why to report in the first place, if a query is a report?
>
> What's going on here? I do not believe people subscribe to Debian lists
> and then report those as SPAM. Can't be`.
They don't. They query DCC, which is an implied "I have seen this
mail" [1]. Do keep in mind that DCC is NOT about spam, but bulk. Which
directly translates to "how often is this mail sent out?"
DCC identifies mail that has been sent often. That's what the rule
checks for, if other recipients have seen it, too.
You voluntarily installed DCC, knowing SA will use it. This was on your
discretion, and it's your duty to evaluate if it actually is, what you
want.
[1] Once, mind you. Which is what DCC does, counting. The "report spam"
option in SA reports it differently as many.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
> From: "Jari Fredriksson" <ja...@iki.fi>
> Date: Fri, 9 Oct 2009 19:25:15 +0300
>
> > Is someone trying to poison DCC?
> >
> > Yes, you are....(:-) If you haven't whitelisted the
> > mailing list then
> > you are reporting the email from the mailing list to
> DCC, > which will
> > increase the DCC count.
>
> Me? But I do report to DCC/Razor2/SpamCop only spam. I
> do not report ALL my email.
>
> Using spamassassin --report reports the spam message to
> dcc with a -t
> target count of many
>
> How does DCC actually work? Is any query a report
> somehow for DCC?
>
> If you ask the DCC network you are reporting it.
>> From the dccproc man page.
> -Q only queries the DCC server about the checksums
> of messages instead of reporting and then
> querying. This is useful when dccproc is used
> to filter mail that has already been reported to
> a DCC server by another DCC client such as
> dccm(8). This can also be useful when applying
> a private white or black list to mail that has
> already been reported to a DCC server. No
> single mail message should be reported to a DCC
> server more than once per recipient, such as
> would happen if dccproc is not given -Q when processing a
> stream of mail that has already been seen by a DCC
> client. Additional reports of a message increase its
> apparent "bulkness." -jeff
This is hebrew to me. I know nothing about DCC, I have just installed it and let SpamAssassin care the details.
SpamAssassin does the query via dccifd and when I get SPAM in my Spam folder, my spamassassin reports it to DCC, Razor2 and SpamCop. I do not report HAM.
I do know nothing about dcc arguments.
The problem I see here, is that especially Debian mailing list posts get a DCC hit, and once I just joined those lists, my SA statistics went ballistic with DCC_CHECK. I guess Debian lists are wide spread, but I do not see why DCC hits if the posts are not *reported*.
Why to report in the first place, if a query is a report?
What's going on here? I do not believe people subscribe to Debian lists and then report those as SPAM. Can't be`.
I may be drunk, so bare with me..
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jeff Mincy <je...@delphioutpost.com>.
From: "Jari Fredriksson" <ja...@iki.fi>
Date: Fri, 9 Oct 2009 19:25:15 +0300
> Is someone trying to poison DCC?
>
> Yes, you are....(:-) If you haven't whitelisted the
> mailing list then
> you are reporting the email from the mailing list to DCC,
> which will
> increase the DCC count.
Me? But I do report to DCC/Razor2/SpamCop only spam. I do not report ALL my email.
Using spamassassin --report reports the spam message to dcc with a -t
target count of many
How does DCC actually work? Is any query a report somehow for DCC?
If you ask the DCC network you are reporting it.
>From the dccproc man page.
-Q only queries the DCC server about the checksums of messages instead
of reporting and then querying. This is useful when dccproc is used
to filter mail that has already been reported to a DCC server by
another DCC client such as dccm(8). This can also be useful when
applying a private white or black list to mail that has already been
reported to a DCC server. No single mail message should be reported
to a DCC server more than once per recipient, such as would happen
if dccproc is not given -Q when processing a stream of mail that has
already been seen by a DCC client. Additional reports of a message
increase its apparent "bulkness."
-jeff
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
>
> Is someone trying to poison DCC?
>
> Yes, you are....(:-) If you haven't whitelisted the
> mailing list then
> you are reporting the email from the mailing list to DCC,
> which will
> increase the DCC count.
Me? But I do report to DCC/Razor2/SpamCop only spam. I do not report ALL my email.
How does DCC actually work? Is any query a report somehow for DCC?
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
>> Auto correct: That should be 'I know it is *not* a spam
>> indicator but a bulk indicator.'
>
> Correct ;)
>
>>
>> You have to whitelist the mailing list in the dcc
>> whiteclnt file.
>>
>
> Ok, have to learn something new here. I have whiteclnt
> now in my vi as a starting point.
>
> Thanks all for your comments!
How do I know my new settings work? (Is this wrong ML to ask?)
I added these but no idea if they work or not..
# Apache
ok substitute mail_host mail.apache.org
#Debian
ok substitute mail_host liszt.debian.org
# Sourceforge
ok substitute mail_host lists.sourceforge.net
# JBoss
ok env_from boss-user-bounces@lists.jboss.org
# ClamAV
ok substitute mail_host tad.clamav.net
# Netbeans
ok substitute mail_host netbeans.org
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jari Fredriksson <ja...@iki.fi>.
>
> Auto correct: That should be 'I know it is *not* a spam
> indicator but a bulk indicator.'
Correct ;)
>
> You have to whitelist the mailing list in the dcc
> whiteclnt file.
>
Ok, have to learn something new here. I have whiteclnt now in my vi as a starting point.
Thanks all for your comments!
Re: Incresing numbers of DCC_CHECK in ham
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 12:48 -0400, Jason Bertoch wrote:
> Karsten Bräckelmann wrote:
> >
> > Probably because you are not short-circuiting on the whitelist. ;)
>
> Is there a reason whitelist entries aren't short-circuited by default?
They are, in 60_shortcircuit.cf.
IFF you enable the optional Shortcircuit plugin. I guess it is disabled
by default, because it results in quite some different behavior.
> > If you *know* a given message is not spam, you can just as well spare
> > the cycles calling SA on it -- and have your glue avoid SA for those.
>
> Because of things like user_prefs and such. I don't want to give users
> access to glue configuration. Besides, if editing glue was _always_ the
> appropriate tactic, SA wouldn't need the ability to whitelist.
I did not say "always", neither did I imply it. However, with stuff like
mailing lists, it is a good choice and frequently advised on this list.
As per the documentation, the whitelist options in SA are "Used to
whitelist [...] mail that is often tagged (incorrectly) as spam." Which
is not the same as a mailing list.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jason Bertoch <ja...@i6ix.com>.
Karsten Bräckelmann wrote:
>
> Probably because you are not short-circuiting on the whitelist. ;)
>
>
Is there a reason whitelist entries aren't short-circuited by default?
>
> If you *know* a given message is not spam, you can just as well spare
> the cycles calling SA on it -- and have your glue avoid SA for those.
>
>
Because of things like user_prefs and such. I don't want to give users
access to glue configuration. Besides, if editing glue was _always_ the
appropriate tactic, SA wouldn't need the ability to whitelist.
Short-Circuit (was: Incresing numbers of DCC_CHECK in ham)
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 10:32 -0700, R-Elists wrote:
> > Probably because you are not short-circuiting on the whitelist. ;)
> >
> > Any whitelist rule is just that -- a plain, ordinary rule. With a score.
> > There is no magic, and other matching rules always can overrule any
> > other fraction of the equation.
> >
> > If you *know* a given message is not spam, you can just as well spare
> > the cycles calling SA on it -- and have your glue avoid SA for those.
>
> Karsten,
>
> is it in the SA docs where to specifically put ALL (or most) whitelist rules
> and how to specifically shortcircuit them correctly??
One would assume it is in the Shortcircuit plugin docs... No, wait, it
actually *is* in the docs. :)
See the docs. Also 60_shortcircuit.cf.
It is irrelevant where to put the whitelist options. But see below.
> is it done with priority?
Yes. See the docs.
> or should be local.cf and blah?
> ...or some other way to be first in the rule chain etc?
> or a specifcally labeled rulename.cf and blah?
Sorry, this doesn't make sense and blah. ;)
The name of the .cf files only affects the order of *reading* the
configuration. It does in no way affect the order of evaluating rules.
That's what priority does.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
RE: Incresing numbers of DCC_CHECK in ham
Posted by R-Elists <li...@abbacomm.net>.
>
> Probably because you are not short-circuiting on the whitelist. ;)
>
> Any whitelist rule is just that -- a plain, ordinary rule.
> With a score.
> There is no magic, and other matching rules always can
> overrule any other fraction of the equation.
>
> If you *know* a given message is not spam, you can just as
> well spare the cycles calling SA on it -- and have your glue
> avoid SA for those.
>
Karsten,
is it in the SA docs where to specifically put ALL (or most) whitelist rules
and how to specifically shortcircuit them correctly??
is it done with priority?
or should be local.cf and blah?
...or some other way to be first in the rule chain etc?
or a specifcally labeled rulename.cf and blah?
:-)
- rh
Re: Incresing numbers of DCC_CHECK in ham
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 12:25 -0400, Jason Bertoch wrote:
> Jeff Mincy wrote:
> > You have to whitelist the mailing list in the dcc whiteclnt file.
>
> Interesting point here that I never considered. I assumed that if I
> whitelisted a mailing list in SA, then it would not bother calling DCC
> and so I need not worry about DCC's config. Is SA really calling DCC on
> a whitelisted e-mail and, if so, why?
Probably because you are not short-circuiting on the whitelist. ;)
Any whitelist rule is just that -- a plain, ordinary rule. With a score.
There is no magic, and other matching rules always can overrule any
other fraction of the equation.
If you *know* a given message is not spam, you can just as well spare
the cycles calling SA on it -- and have your glue avoid SA for those.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jason Bertoch <ja...@i6ix.com>.
Jeff Mincy wrote:
> You have to whitelist the mailing list in the dcc whiteclnt file.
>
>
Interesting point here that I never considered. I assumed that if I
whitelisted a mailing list in SA, then it would not bother calling DCC
and so I need not worry about DCC's config. Is SA really calling DCC on
a whitelisted e-mail and, if so, why?
Re: Incresing numbers of DCC_CHECK in ham
Posted by Jeff Mincy <je...@delphioutpost.com>.
From: "Jari Fredriksson" <ja...@iki.fi>
Date: Fri, 9 Oct 2009 17:58:06 +0300
This looks worrying. I have it at 2.2 pts, and not caused any false
positives, but still, odd. Or is it? I know it is a SPAM indicator
but a bulk indicator.
Auto correct: That should be 'I know it is *not* a spam indicator but a bulk indicator.'
Yes - it indicates bulk. Lots of people have seen the email message.
DCC will hit spam, mailing lists, and retail email such as amazon, and
various extremely short email messages.
But it is triggered for example by some mailing list posts which are genuine and not bulk.
What is a genuine mailing list post that is not bulk? If lots of
people are on the mailing list then the message is, by definition, bulk.
Is someone trying to poison DCC?
Yes, you are....(:-) If you haven't whitelisted the mailing list then
you are reporting the email from the mailing list to DCC, which will
increase the DCC count. Eventually somebody will report the mailing
list as spam to DCC and you will get a DCC match on the default
many=999999.
You have to whitelist the mailing list in the dcc whiteclnt file.
-jeff
Re: Incresing numbers of DCC_CHECK in ham
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-10-09 at 17:58 +0300, Jari Fredriksson wrote:
> This looks worrying. I have it at 2.2 pts, and not caused any false
> positives, but still, odd. Or is it? I know it is a SPAM indicator but
> a bulk indicator.
Missed a 'not' before the Spam, eh? ;)
> But it is triggered for example by some mailing list posts which are
> genuine and not bulk.
Ahem -- with a non-negligible amount of subscribers, mailing lists ARE
indeed bulk per the very definition.
Genuine does not equal 'not bulk'. They might be genuine, but still be
bulk.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}