Doesn't help. (BTW, this interface is not NATed.)
Hmm.. Ok.. it's not NATed, but it is a RFC 1918 IP address.
I suppose I should generalize my statement to "Any system using a RFC 1918 IP address, including typical NAT configurations, can be affected by this bug"
Here's some debug output, with only names changed and bayes lines removed. Note that trusted = yes:
And THAT is a bug... mail.rifton.com should trust itself.. It should NOT trust 192.168.1.10.
I'll repeat myself.. trusted_networks should contain ONLY your mailservers.. it should NOT contain your clients and workstations. 192.168.1.10 is a workstation. It is NOT to be trusted in the sense of SA's trust-path.
Trusted_networks does not mean "trusted to not send spam".. it means "trusted relay" 192.168.1.10 is not relaying, so don't include it in your trust path.
