-----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 (abuse@senderscorecertified.com). 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... cer@nimrodel:~> 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 robin.listas@***t; 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 robin.listas@***t; Tue, 19 Jun 2007 21:04:47 +0100 Received: by mail.mlan (sSMTP sendmail emulation); Tue, 19 Jun 2007 20:04:47 +0000 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) 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? In fact, it does come from them. The email has a "from: noreply@amigospc.com", and looking up that one: cer@nimrodel:~> host amigospc.com ... amigospc.com mail is handled by 5 cluster.monopost.com. So, cluster.monopost.com. seems to be an spamming organization that is listed as trustworthy by the bonded-sender guys. :-/ Have a look at http://www.bondedsender.org/senderscorecertified/who.php ] Standards for acceptance are exceptionally high, with only the best ] programs being accepted to ensure the validity and effectiveness of ] Sender Score Certified. Some of these requirements include: ] ] * Consent with appropriate disclosure ] * A working unsubscribe option available for every email ... ] Examples of email sent by members of the Sender Score Certified include ] important, time sensitive communications like: ] ] * Auction Alerts ] * Travel Itineraries ] * Transaction Confirmations ] * Delivery Notifications ] * Account Statements ] * Opt-in newsletters Ie, their users/client are mass mail senders!!! The very spammers!!! :-/
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.
Yes, I have seen that one a lot.
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.
OBSCURED_EMAIL - it would never be able to do what it says it does.
And that's just a few samples.
And I have added some rules of my own. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGe7BPtTMYHG2NR9URAslPAJ92MYPogMzTahvAQ6IQh3Rdf1oa0ACfZzmu OtvhnsqVOYTmx5yZFUSW63E= =bs3k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org