You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Rich Shepard <rs...@appl-ecosys.com> on 2009/06/06 19:48:44 UTC
Next Rule Causing False Positives: BOTNET
Now that the EMPTY_BODY and mis-identified spam issues have been resolved
I've countered a new one creating false positives: the rule (in
/etc/mail/spamassassin/Botnet.cf is:
describe BOTNET Relay might be a spambot or virusbot
header BOTNET eval:botnet()
score BOTNET 5.0
I've read Botnet.txt but I've no clue what to do to reduce the number of
false positives. I could include a specific example that came today from a
client via his Crackberry, if that would help.
Do I need to build a white list of all such senders? Is there a better way
to tune this rule so it's not triggered so frequently?
Rich
--
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
Re: Next Rule Causing False Positives: BOTNET
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2009-06-06 at 13:32 -0700, Rich Shepard wrote:
> On Sat, 6 Jun 2009, Karsten Br?ckelmann wrote:
>
> > This is a third-party plugin, deliberately installed by you.
Given the previous thread I was actually wondering about the phrasing.
Anyway, make that "any admin, or previous admin".
> Actually, it was most likely installed with the SA upgrade because I've
That sounds too close to sa-update -- which by default does not allow
plugins or touches that dir. Stock SA updates definitely is not it
anyway.
Upgrading your distro supplied SA version -- maybe. Though seriously I
doubt that. It's a third-party plugin, and if your distro installs it as
part of SA, please flame them.
> not made any modifications or tuning to the system. I figure that those who
> set up defaults know much more than do I, so I leave things until there's a
> reason for change.
Yeah, I was more about inheriting it from an old install plus custom
settings. Stock SA plugins *never* will be installed to your *site*
config dir -- where you reported that plugin to be.
Checked the file's age?
> > With any custom rule-set, it's definitely the admins duty to score it
> > appropriately, and to tune to their specific mail stream. After all, you
> > already "tuned" SA by installing the rule-set in the first place.
>
> It must have been the Slackware build/installation script that included it
> because adding such a plug-in would not have occurred to me. Regardless, I
> will decrease the score by 80%.
If it doesn't work reliably for you, decreasing the score is a good
first step.
Anyway, let me stress the point: It is not SA that installed it, and if
so, never with a sore a like that. And I would guess it is not Slackware
either. Or at least, not part of the Slackware SA, but a separate
module.
In conclusion I can only re-iterate my previous recommendation, to
review your custom settings. By default, there are NO .pm modules or
rules in your site config /etc/mail/spamassassin dir. Only .pre files
and some, few options in local.cf.
--
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: Next Rule Causing False Positives: BOTNET
Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Sat, 6 Jun 2009, Karsten Br?ckelmann wrote:
> This is a third-party plugin, deliberately installed by you.
Actually, it was most likely installed with the SA upgrade because I've
not made any modifications or tuning to the system. I figure that those who
set up defaults know much more than do I, so I leave things until there's a
reason for change.
> With any custom rule-set, it's definitely the admins duty to score it
> appropriately, and to tune to their specific mail stream. After all, you
> already "tuned" SA by installing the rule-set in the first place.
It must have been the Slackware build/installation script that included it
because adding such a plug-in would not have occurred to me. Regardless, I
will decrease the score by 80%.
Thanks,
Rich
--
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
Re: Next Rule Causing False Positives: BOTNET
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sat, 2009-06-06 at 10:48 -0700, Rich Shepard wrote:
> Now that the EMPTY_BODY and mis-identified spam issues have been resolved
> I've countered a new one creating false positives: the rule (in
> /etc/mail/spamassassin/Botnet.cf is:
This is a third-party plugin, deliberately installed by you.
> describe BOTNET Relay might be a spambot or virusbot
> header BOTNET eval:botnet()
> score BOTNET 5.0
This is a custom score. Generally, consensus is that no single rule in
SA should be able to single-handedly flag a mail as spam. That means,
use a score lower than your required_score threshold.
Yes, I do realize (IIRC) that it actually is the Botnet plugin default.
However, it also offers a fine-grained scoring approach with more rules
and lower scores each.
With any custom rule-set, it's definitely the admins duty to score it
appropriately, and to tune to their specific mail stream. After all, you
already "tuned" SA by installing the rule-set in the first place.
Given your previous thread, my advice is to seriously go through your
entire custom settings, and carefully review them.
> I've read Botnet.txt but I've no clue what to do to reduce the number of
> false positives. I could include a specific example that came today from a
> client via his Crackberry, if that would help.
If it hits too often on ham for you, it isn't what you want.
guenther
--
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: Next Rule Causing False Positives: BOTNET
Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Sat, 6 Jun 2009, John Rudd wrote:
> Probably a good approach for your situation. Let me know how the lower
> score works out for you (when you said 80% in the other message, do you
> mean you're lowering it to a score of 1.0, or to a score of 4.0?)
John,
It seems to be working better with the SPAMBOT score lowered to 2.0, and
scores of 0.4 for the individual components.
Now that my mail has settled back to normal I'll again thank everyone and
leave the list.
Rich
--
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
Re: Next Rule Causing False Positives: BOTNET
Posted by John Rudd <jr...@ucsc.edu>.
On Sat, Jun 6, 2009 at 13:38, Rich Shepard<rs...@appl-ecosys.com> wrote:
> On Sat, 6 Jun 2009, John Rudd wrote:
>
>> The thing thing to do to fix messages from given locations is lean,
>> heavily, upon the sender to get their sending environment fixed. What
>> botnet finds are sites with bad DNS (no full circle reverse DNS), or
>> sending hosts that look like clients instead of looking like servers. If
>> the exact cause was the former, then that site is poorly configured
>> (violating best practices).
>>
>> If it's the latter, then that's a little more tricky. But there are
>> entries you can put in the Botnet.cf to exempt sites that actually can't
>> fix their own reverse DNS, or sites that you really need to communicate
>> with, but that wont fix their reverse DNS.
>
> John,
>
> The false positives I'm seeing now are primarily from people who know
> virtually nothing about computers. Sure, they have some competence in their
> Microsoft applications, but to them anything else is a black box. Not only
> do they not run their own servers, but they couldn't clearly communicate the
> problem to someone who could fix it even if they wanted to do so.
When I send those reports to the sender, I typically also send it to
the postmaster, abuse, and hostmaster addresses for their
ISP/hosting-provider/whatever, exactly because I don't expect the end
user to know much about it. From there, ISPs that are difficult to
deal with, wrt to suggesting that they follow best practices, I put
into the same category as ISPs that condone spam. But... I know of
VERY few providers that are difficult about it. Once AOL and
earthlink started to get picky about it, the little guys started to
fall into line.
Out of a few dozen false positives in the 3-4ish years since I made
Botnet public, only 2 have required a local whitelist entry. The
other providers fixed their configurations. The funniest one was that
the end user (a marketing person) had been trying to get his sysadmins
to fix it for years, and my report back to them actually provided
ammunition for the _MARKETING_ person to get the TECHNICAL person do
to the right technical thing.
> I'm lowering the score on that rule.
Probably a good approach for your situation. Let me know how the
lower score works out for you (when you said 80% in the other message,
do you mean you're lowering it to a score of 1.0, or to a score of
4.0?)
Re: Next Rule Causing False Positives: BOTNET
Posted by Rich Shepard <rs...@appl-ecosys.com>.
On Sat, 6 Jun 2009, John Rudd wrote:
> The thing thing to do to fix messages from given locations is lean,
> heavily, upon the sender to get their sending environment fixed. What
> botnet finds are sites with bad DNS (no full circle reverse DNS), or
> sending hosts that look like clients instead of looking like servers. If
> the exact cause was the former, then that site is poorly configured
> (violating best practices).
>
> If it's the latter, then that's a little more tricky. But there are
> entries you can put in the Botnet.cf to exempt sites that actually can't
> fix their own reverse DNS, or sites that you really need to communicate
> with, but that wont fix their reverse DNS.
John,
The false positives I'm seeing now are primarily from people who know
virtually nothing about computers. Sure, they have some competence in their
Microsoft applications, but to them anything else is a black box. Not only
do they not run their own servers, but they couldn't clearly communicate the
problem to someone who could fix it even if they wanted to do so.
There are obviously many poorly or mis-configured servers and clients on
the 'Net. That's why there's so much spam and malware out there.
I'm lowering the score on that rule.
Thanks,
Rich
--
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
Re: Next Rule Causing False Positives: BOTNET
Posted by John Rudd <jr...@ucsc.edu>.
Different people run botnet at different score levels, depending on
what they want the rule to do. The default is 5 because 5 is the
common point where people set messages aside for review (remove them
from their regular mail stream). That's what botnet is saying about
such messages: this message needs to be reviewed/quarantined.
If you don't agree with that intent, then you should lower the score.
The thing thing to do to fix messages from given locations is lean,
heavily, upon the sender to get their sending environment fixed. What
botnet finds are sites with bad DNS (no full circle reverse DNS), or
sending hosts that look like clients instead of looking like servers.
If the exact cause was the former, then that site is poorly configured
(violating best practices).
If it's the latter, then that's a little more tricky. But there are
entries you can put in the Botnet.cf to exempt sites that actually
can't fix their own reverse DNS, or sites that you really need to
communicate with, but that wont fix their reverse DNS.
On Sat, Jun 6, 2009 at 10:48, Rich Shepard<rs...@appl-ecosys.com> wrote:
> Now that the EMPTY_BODY and mis-identified spam issues have been resolved
> I've countered a new one creating false positives: the rule (in
> /etc/mail/spamassassin/Botnet.cf is:
>
> describe BOTNET Relay might be a spambot or virusbot
> header BOTNET eval:botnet()
> score BOTNET 5.0
>
> I've read Botnet.txt but I've no clue what to do to reduce the number of
> false positives. I could include a specific example that came today from a
> client via his Crackberry, if that would help.
>
> Do I need to build a white list of all such senders? Is there a better way
> to tune this rule so it's not triggered so frequently?
>
> Rich
>
> --
> Richard B. Shepard, Ph.D. | Integrity Credibility
> Applied Ecosystem Services, Inc. | Innovation
> <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
>