-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Shane Williams writes: > Let me make it clear that I'm not convinced yet where the "problem" > really lies. IMP's Received header seems deceptively "real", but for > all I know this meets (or at least doesn't contradict) some RFC. On > the other hand even if the problem should be fixed by the IMP devs, it > may be easier to "fix" spamassassin. I don't know. That's why I > posted. yes, I agree we should fix it (although possibly IMP should do so *too*). that's why I was asking that someone open a BZ bug about it ;) > While the original question about HELO_DYNAMIC_* may have been > complicated by several localhost and 127.0.0.1 appearences in the > headers, neither of my examples have that issue. I'm providing two > examples to maybe help clarify what's happening. > > I also want to understand how the trusted_hosts is interacting here. > I have no trusted_networks or internal_networks defined in my config. > Thus, SA is deciding on the fly that since webmailapp1.cc.utexas.edu > and fiat.ischool.utexas.edu are in the same domain, the former is > trusted? Thus, a dynamic address talking directly to webmailapp1 > triggers the HELO_DYNAMIC_* rules? And if I tell my SA that > webmailapp1 is not trusted, then those hits go away? What about the > SPF hit in the first example? Or should I be defining > internal_networks instead of trusted_networks? I can't really tell, you need to post full messages and/or the debug output from "spamassassin -D -L -t < msg". If it's not guessing correctly, anyway, I would strongly recommend setting those parameters. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCKH6WMJF5cimLx9ARAj6mAJ0RU84pI/HxXnMU7TbjqoFdK/EXQwCgkF8d yTOzaE6rt9O/ylWT8H+Hxbg= =vor+ -----END PGP SIGNATURE-----
