Arvinn Løkkebakken wrote: > I aggree, and this is probably the reason most of the times. I just > felt it was necessary to comment on your *never*. It_is_likely that > ALL_TRUSTED will misfire as long as it trusts unparseable headers > containing whatever IP-addresses. Generally we should acknowledge the > fact that this bug exists in 3.0.2 and not categorically blame it on > the frequently TrustPath misunderstanding. > I think you misunderstood my use of *never*. I didn't mean to imply the rule never failed except due to broken trust path.
To requote myself: "You have a broken trust path. ALL_TRUSTED should *never* match email from outside your network." I suppose I should have re-phrased the first part "you probably have a broken trust path". However, the "ALL_TRUSTED should *never* match email from outside your network" is 100% correct. It SHOULD never hit mail from outside, if it was working correctly. I suppose I'm just so used to seeing NATed mail headers and equating it to the trust path configuration issue because I see it several orders of magnitude more frequently than the mis-parsing bug. NATed MXes are now as common as dirt in new networks. There's just rarely any reason to ever have a non-NATed one other than not understanding how to use the Cisco PIX "static" command, or equivalent commands in your firewall of choice. Broken AV appliances and weird MTAs are not too uncommon, but not nearly as common as NATed servers. However, you are correct, I should acknowledge both.
