Jo Rhett wrote:
I just realized something re: the previous message about SPF failure.
trusted_hosts is also apparently blocking whitelist_from_rcvd from
working.
misconfigured trusted/internal networks breaks *MANY* things in
SpamAssassin. Pretty much everything that looks at Received: headers
depends on this being configured right. RBL lookups,
whitelist_from_rcvd, SPF, the AWL. This is not a setting you want to
just blow off. You really want it to be 100% correct.
See also:
http://wiki.apache.org/spamassassin/TrustPath
This is getting out of control. I understand the original intent
here, but basically what is happening is that by making a host
"trusted" you are basically saying to ignore
SPF
whitelist_from_*
etc...
Everything that says "any message from this host is good" is
compromised/broken.
Honestly, I think we need two separate forms here:
trusted_relays should be what trusted_hosts is today. We trust that
this host won't add false headers to the e-mail. If you read the
description of trusted hosts, that's clearly what the rule is meant to
do.
trusted_hosts should mean "no, we really truly trust this host and
want everything it gives us"
No, it shouldn't. If you really trust the mail that much, configure your
mail chain to bypass SA entirely for this mail. as a bonus, it will be
much faster to process this way too.
trusted_networks refers to trust of the headers, and not origination of
spam. Nothing more. Period.
The problem with the kind of "unlimited trust" is that it isn't useful
to many people. Most of the time if you've got internal hosts you never
trust to send spam, then they, and everything they relay through, should
be trusted.
The only case an unlimited trust would be useful is if you trust the
mail, even if the host relays mail from untrusted hosts. But if the
sources are untrusted, why are you trusting the mail just because it
came through some super-trusted server?
