Justin Mason wrote: > Matt Kettler writes: > >> Justin Mason wrote: >> >>> To be honest, I intended them as a whitelist ;) >>> >>> If a message never touched an untrusted host (ALL_TRUSTED), in >>> a correctly-configured trust setup, is that not safe to whitelist? >>> >>> >>> >> Only if the trust-path auto-detector code works perfectly, for all >> sites. Which is impossible. >> > > Yep. But if it is conservative, and doesn't over-extend trust beyond the > trusted nets any more, that would be safe enough I think... > > --j. > > Personally, I think categorically flipping to the other trust-guess behavior (ie: don't trust the ambiguous first public IP) is an extraordinarily bad idea. It's simply making a bad problem harder to find.
Remember, we've already established that it's just as bad to under-trust as over-trust. Under-trust screws up anything that tries to use the "first untrusted" just like over-trust does. However, right now we over-trust problems, which have this nice handy flag to detect people who need manual configs for this case. Look for ALL_TRUSTED hitting on external mail. If we flip, then how do we detect people with bad configs? Ask them if any DUL rbl's have ever hit anything? Look for SPF false-positives (only works if they actually have SPF loaded at all)? Ask them if their whitelist_from_rcvd's never work right? That said, I could seriously see adding a config option like "nated_external_mailserver" that when set to 1 uses the low-trust case, and when set to 0 uses the current behavior. This would make things easy for folks to fix, and if they read the conf manpage, it might jump out at them as something they need to set.
