https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
--- Comment #118 from Adam Katz <[email protected]> 2009-10-20 13:38:04 UTC --- (In reply to comment #117) > > bb_trec_enron has 98.9497% of its ham match RDNS_NONE, which is to say > > that it's bogus. > > Indeed. From the dev list earlier today, that's "a corpus with generated > (synthetic) headers [...], only useful for body hits", and is not included > in the re-scoring. Ah, I thought I saw that corpus mentions somewhere ... only thought to search the bug. I had assumed that if the rulesqa page mentioned it, it was factored in everywhere. > > Many of the people on the sa-users list have > > manually scored RDNS_NONE higher than the default 0.1. > > FWIW, nailed to 0.1 as per comment 56. I saw that but did not understand it ... It says "most of these are already documented and labeled as [fixed/immutable]" but it doesn't say where. Is this because it triggers when rDNS checks aren't performed by the first trusted relay, and if so, can we work around that somehow (wasn't that bug 5586 )? Or is this a remnant of Justin's checkin r497852 from 2007 which states: > move 20_dynrdns.cf from sandbox into main ruleset, so RDNS_DYNAMIC > and RDNS_NONE are core rules; lock their scores to an informational > 0.1, however, since they still have a high ham hit-rate alone ... despite the current corpus data (unless 1.7% is a high ham hit-rate)? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
