> The problem is that 10.x is a private net, therefore SpamAssassin infers > it cannot possibly be the external MX sitting out there on the internet. > (for a host to be sitting on the public internet accepting SMTP > connections, it'd obviously need a public IP addr.) > > so the *next* step must be the external MX.
My 10.x server is inside a firewall which NATs port 25 so this conclusion is not correct. I imagine that my setup isn't all that different from a lot of other peoples.
Yes, it is incorrect, but SA can't know that. Thus, SA assumes, incorrectly, that any 10.x host must not be externally addressable. It's not a very good assumption in modern networks, but there's not much else one can do.
SA's trust path code has pretty much always been incompatible with NAT'ed mailservers. And it's hard for SA to autodetect such things from mail headers.
> Yep, that's right -- and trusted_networks will fix it.
Yes trusted_networks does indeed fix the issue, but I'm still not so sure that the algorithm to deduce trusted_networks is correct (if not specified).
Do you know of an algorithm that will allow SA to deduce the difference between a NATed mailserver, and an internal relay server which feeds a local non NATed mailserver?
ie: consider these two setups
PC 10.1.1.1 internal groupware server 10.2.2.2 local internet mail gateway 208.39.141.94 --- end of local network --- outside mailserver 1.1.1.1 outside PC 10.0.1.1
vs
PC 10.1.1.1 NATed mail server 10.2.2.2 --- end of local network --- outside list server 208.39.141.94 outside mailserver 1.1.1.1 outside PC 10.0.1.1
It's very hard from Received: headers alone to know the difference.. You can't make assumptions based on the domain names being the same, because if 208.39.141.94 is an untrusted server, such things can easily be forged.
