On Fri, 20 Aug 2010, Karsten Br�ckelmann wrote:
On Fri, 2010-08-20 at 17:47 +0200, Karsten Bräckelmann wrote:
On Fri, 2010-08-20 at 17:12 +0200, Jan P. Kessler wrote:
false-positives hitting on the rules JM_SOUGHT_1 and JM_SOUGHT_2.
Unfortunaley I can not give examples as these messages contain
confidental customer data (assurance company). We had more than 100
false-positives with these rules in the last 2 days.
I hope you can tell us the __SEEK_* sub-rules triggered, though. That
would help already. To extract these, either (a) pipe such a message to
spamassassin -D, and get the sub-rule from the debug output, or (b) add
a specific header only showing the sub-rules.
A word of caution: Do note that the seek sub-rules' names are generated
using a hash function, and thus identify the actual string matched!
You might want to check the string in 20_sought.cf, before disclosing
the seek ID. I'd be surprised if it contains sensitive data, tough --
after all, it is found massively in spam.
...as well as in SA SVN. The matches can't be confidential as they're
generated from public sources. The non-matching bits are what is
confidential.
I agree with Karsten, it's most likely disclaimer text that doesn't have a
ham exclusion in the SOUGHT rule generator.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
I'll have that son of a bitch eating out of dumpsters in less than
two years. -- MS CEO Steve Ballmer, on RedHat CEO Matt Szulik
-----------------------------------------------------------------------
4 days until the 1931st anniversary of the destruction of Pompeii
