Re: [opensuse] SpamAssassin missfiring.
Carlos E. R. wrote: > The thing is that SA comes with many rules enabled by default whose > policies I don't even know, and which sometimes I came to strongly > distrust and disable - after the "damage". I think there is a small problem of expectation-setting here. To a large extent, people expect SA to come all ready to go. Just turn it on, and voila you're free of (most) spam. But with e.g. postfix and smartd we don't have the same expectations - we know that some setup is required before postfix will behave as our mail-server and before smartd will do some SMART monitoring for us. The thing with SA is that its ruleset is large and complex and not very transparent, which tends to "scare" people away and into thinking "it's probably allright as it is". > And the SuSE/Novell folks > don't seem to do a good review of those rules. They cannot and they shouldn't have to. Overall, that is the responsibility of the SA folks, but SA has to be individually configured/optimised to max its performance. > No, I meant the www.bondedsender.org people, they have an email for > reports ([EMAIL PROTECTED]). But I'm not a client of > them, I don't know who is the sender, etc. Too many doubts, and > reading their site I'm not clear on them. Yes, I agree, it's confusing. I also don't like that they talk in probabilities, about number of complaints per mail sent etc. Which is why I have "score RCVD_IN_BSP_TRUSTED 0" in my SA config. >> You can't really blame SA for this one - it probably is fairly >> reasonable to trust the bonded-sender guys. > > I don't know. > In fact, I don't think so. Then you should simply disable the rule like I have. Nonetheless, I still think it is _reasonable_ to trust them, but in my case I chose not to. Using the BSP rule is a matter of avoiding false-positives and I don't think the BSP rule does that very well. > How can SA (or any program) know that the received lines it is > examining are true, ie, real and not faked? The bonded sender people > may say that monopost.com people are reliable, but can we know > (automatically, ie, by a program) that the email really came from > their servers? You can always tell where an email came from. The headers are written by your email-program and it knows which client delivered the email. Whether you can trust the rets of the path is another question. But SA is pretty good at checking the emails headers and finding inconsistencies. >> RCVD_IN_WHOIS* - as far as I'm concerned, the completeWhois people >> can't be depended on to deliver quality data, > > Every server should be in whois, no? The good and the bad. It must be > something else. Well, in some cases I have had reports of "invalid IP" although it had a perfectly good whois report. I think the RCVD_IN_WHOIS is dodgy, and I've disabled it. /Per Jessen, Zürich -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] SpamAssassin missfiring.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Thursday 2007-06-21 at 16:48 +0200, Per Jessen wrote: > > Now, the culprit seems to be "RCVD_IN_BSP_TRUSTED". What on earth is > > that? My method to learn a bit more is to grep for the token, via > > "grep RCVD_IN_BSP_TRUSTED /usr/share/spamassassin/*", and what I got > > is this: > > I've also seen that rule fire once or twice recently too. Whether you > use it or not depends quite a bit on how much you trust the > bonded-sender guys. Yep. - From a cursory glance at their site they seem to make a score for "senders", but I don't know who is a "sender": the from address, the sending server (the first of the chain), or what. The thing is that SA comes with many rules enabled by default whose policies I don't even know, and which sometimes I came to strongly distrust and disable - after the "damage". And the SuSE/Novell folks don't seem to do a good review of those rules. > > Interestingly, spamassassin is so inconsistent that only the German > > version contains a web link. It appears that failures can be reported, > > but I don't know "who" is marked as trusted in that email. > > spamassassin is an apache project, you just use their bugzilla. No, I meant the www.bondedsender.org people, they have an email for reports ([EMAIL PROTECTED]). But I'm not a client of them, I don't know who is the sender, etc. Too many doubts, and reading their site I'm not clear on them. > > Two questions: > > > > How do I know which of the several received headers is considered > > "trusty"? > > You'll have to run the addresses through the test manually - I think. > Or maybe run the mail through spamassassin with debug on. Possibly... [EMAIL PROTECTED]:~> spamassassin -D < spam 2> spamlog Now, the "spamlog" file has 431 lines. There is only one with "RCVD_IN_BSP_TRUSTED", at the very end: [31642] dbg: check: tests=AWL,BAYES_00,FROM_EXCESS_BASE64,HTML_MESSAGE,HTML_MISSING_CTYPE,HTML_TAG_BALANCE_BODY,HTML_TITLE_EMPTY,RCVD_IN_BSP_TRUSTED,SUBJECT_EXCESS_BASE64 [31642] dbg: check: subtests=__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ALT,__ENV_AND_HDR_FROM_MATCH,__FROM_ENCODED_B64,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__MIME_VERSION,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__NONEMPTY_BODY,__RATWARE_0_TZ_DATE,__SANE_MSGID,__SUBJECT_ENCODED_B64,__TAG_EXISTS_BODY,__TAG_EXISTS_HEAD,__TAG_EXISTS_HTML,__TAG_EXISTS_META,__TOCC_EXISTS Which is Chinese, ie, Greek, to me. Let me see... It might be this one: [31642] dbg: dns: checking RBL sbl-xbl.spamhaus.org., set sblxbl [31642] dbg: dns: IPs found: full-external: 10.20.102.201, 87.245.192.62, 10.10.111.24 untrusted: 87.245.192.62 originating: [31642] dbg: dns: only inspecting the following IPs: 87.245.192.62 [31642] dbg: dns: checking RBL sa-other.bondedsender.org., set bsp-untrusted [31642] dbg: dns: IPs found: full-external: 10.20.102.201, 87.245.192.62, 10.10.111.24 untrusted: 87.245.192.62 originating: [31642] dbg: dns: only inspecting the following IPs: [31642] dbg: dns: checking RBL combined.njabl.org., set njabl-lastexternal [31642] dbg: dns: IPs found: full-external: 10.20.102.201, 87.245.192.62, 10.10.111.24 untrusted: 87.245.192.62 originating: [31642] dbg: dns: only inspecting the following IPs: 87.245.192.62 Now, which are the IPs, the line before "sa-other.bondedsender.org.", or the line after? I guess it means 87.245.192.62, which "host" says it belongs to "cluster.monopost.com", and that's the first received line. Actually, the second: Received: from cluster.monopost.com (87.245.192.62) by ctsmtpmx1.frontal.correo (7.2.056.6) id 46769531000F0D4E for [EMAIL PROTECTED]; Tue, 19 Jun 2007 22:04:49 +0200 Received: from [10.10.111.24] (HELO mail.mlan) by cluster.monopost.com (CommuniGate Pro SMTP 5.1.9) with SMTP id 129056509 for [EMAIL PROTECTED]; Tue, 19 Jun 2007 21:04:47 +0100 Received: by mail.mlan (sSMTP sendmail emulation); Tue, 19 Jun 2007 20:04:47 + No, the third one (bottom up). It shouldn't be so difficult, SA should report this explicitly :-( > > Now, where do spamassassin document the rationale for choosing a > > particular test, how and when to use it, etc? > > A lot of it is done with statistics and checking the spamassassin > collections of spam/ham (corpi). I know, but first they have to decide to include a particular test. And you know statistics... the bosses love them, but they are meaningless. (here, they do polls to say who is going to gain so many parliament members on the next election: depending on who pays the forecast, the result is one or the contrary. Even measurement statistics are very inaccurate.) > > It doesn't seem to me to be that reliable. > > It is not the first time I have had to disable a > > particular SA test. :-/ > > You can't really blame SA for this one - it probably is fairly > reasonable to trust the bonded-sender guys. I don't know. In fact, I don't think so. How can SA (or any program)
Re: [opensuse] SpamAssassin missfiring.
Carlos E. R. wrote: > Now, the culprit seems to be "RCVD_IN_BSP_TRUSTED". What on earth is > that? My method to learn a bit more is to grep for the token, via > "grep RCVD_IN_BSP_TRUSTED /usr/share/spamassassin/*", and what I got > is this: I've also seen that rule fire once or twice recently too. Whether you use it or not depends quite a bit on how much you trust the bonded-sender guys. > Interestingly, spamassassin is so inconsistent that only the German > version contains a web link. It appears that failures can be reported, > but I don't know "who" is marked as trusted in that email. spamassassin is an apache project, you just use their bugzilla. > Two questions: > > How do I know which of the several received headers is considered > "trusty"? You'll have to run the addresses through the test manually - I think. Or maybe run the mail through spamassassin with debug on. > Now, where do spamassassin document the rationale for choosing a > particular test, how and when to use it, etc? A lot of it is done with statistics and checking the spamassassin collections of spam/ham (corpi). > It doesn't seem to me to be that reliable. > It is not the first time I have had to disable a > particular SA test. :-/ You can't really blame SA for this one - it probably is fairly reasonable to trust the bonded-sender guys. However, there are a few other weird and wonderful SA rules that need fixing or disabling: SUBJECT_ENCODED_TWICE - this happens a lot in emails written in Outlook in other languages but English. RCVD_IN_WHOIS* - as far as I'm concerned, the completeWhois people can't be depended on to deliver quality data, OBSCURED_EMAIL - it would never be able to do what it says it does. And that's just a few samples. /Per Jessen, Zürich -- http://www.spamchek.com/ - your spam is our business. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse] SpamAssassin missfiring.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just got an email, which while being obviously spam, was marked -4.7,
ie, absolutely "non spam":
X-Spam-Status: No, score=-4.7 required=5.0
tests=BAYES_00,FROM_EXCESS_BASE64,
HTML_MESSAGE,HTML_TITLE_EMPTY,RCVD_IN_BSP_TRUSTED,SUBJECT_EXCESS_BASE64
autolearn=disabled version=3.1.8
Now, the culprit seems to be "RCVD_IN_BSP_TRUSTED". What on earth is that?
My method to learn a bit more is to grep for the token, via "grep
RCVD_IN_BSP_TRUSTED /usr/share/spamassassin/*", and what I got is this:
20_dnsbl_tests.cf:header RCVD_IN_BSP_TRUSTED
eval:check_rbl_txt('bsp-firsttrusted', 'sa-trusted.bondedsender.org.',
'(?i:bonded)')
20_dnsbl_tests.cf:describe RCVD_IN_BSP_TRUSTED Sender is in Bonded Sender
Program (trusted relay)
20_dnsbl_tests.cf:tflags RCVD_IN_BSP_TRUSTEDnet nice
20_dnsbl_tests.cf:#reuse RCVD_IN_BSP_TRUSTED
30_text_de.cf:lang de describe RCVD_IN_BSP_TRUSTED Senderechner in Liste von
http://www.bondedsender.org/
30_text_fr.cf:lang fr describe RCVD_IN_BSP_TRUSTED Relais participant au
Bonded Sender Program (relais connu)
30_text_nl.cf:lang nl describe RCVD_IN_BSP_TRUSTED Verzender is
opgenomen in het Bonded Sender Program (trusted relay)
30_text_pl.cf:lang pl describe RCVD_IN_BSP_TRUSTED Nadawca bierze udzia w
'Bonded Sender Program' (zaufany relay)
50_scores.cf:score RCVD_IN_BSP_TRUSTED 0 -4.3 0 -4.3
Interestingly, spamassassin is so inconsistent that only the German version
contains a web link. It appears that failures can be reported, but I don't
know "who" is marked as trusted in that email.
Two questions:
How do I know which of the several received headers is considered
"trusty"?
Now, where do spamassassin document the rationale for choosing a
particular test, how and when to use it, etc? It doesn't seem to me to be
that reliable. It is not the first time I have had to disable a
particular SA test. :-/
- --
Cheers,
Carlos Robinson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFGeHYltTMYHG2NR9URApfgAJ9ehqBiVVYVB+WrJEvNU6f0WB+qAACfQJao
YuFX8w1BZayrOl3wp3/2BgQ=
=ltGU
-END PGP SIGNATURE-
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
