-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think the problem is being caused by IMP being "too good" at generating a Received header that looks like a normal one added by an MTA. Good enough to fool SpamAssassin into thinking it's an SMTP one, anyway. ;) Could someone open a bug about this? we may indeed be able to look for the "with HTTP" and ignore that. - --j. Shane Williams writes: > I noticed the HELO_DYNAMIC_* thread and the conclusion that IMP adding > a Received header may be a source of problems. I pieced together the > same conclusion just this morning based on several false positives > that went through our campus' IMP-based webmail. In addition to > the several variations of HELO_DYNAMIC_*, I also saw one which hit an > SPF rule (since it didn't get relayed through the "official" relay. > > My first question, for anyone who knows the relavent RFCs better than > I, is IMP's behavior of adding a Received header following specs? > > Second, has anyone determined the best way to handle this? The two > options that immediately come to mind would be to turn off the > HELO_DYNAMIC_* rules (but I suspect this would cause more false > negatives), or create a score-lowering rule that fires when a > webmail/IMP header is detected (also problematic since a webmail > header isn't necessarily related to the spamminess of the email, only > to the likely existence of false triggers on other rules). > > Alternately, is this something that spammassassin should be taking > into account in its analysis? That is, when SA sees a "with HTTP" > descriptor in a received header, it should just ignore that header > altogether (or ignore it in relation to certain rules). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCJkV0MJF5cimLx9ARAh5pAJ9RTEcXz46ABrVa40PXEmzuVFIMHgCfSLiO HADKznPdV4nuEeRy3pVcLB8= =jNdY -----END PGP SIGNATURE-----
