Matt Kettler wrote:
>> There's
>> nothing in trusted networks, I don't trust anything...


> Jo, that's impossible in spamassasin. You cannot have an empty trust, it
> doesn't make any logical sense, and would cause spamassassin to fail
> miserably.


I should rather have said trust is only localhost.

> If you don't declare a trusted_networks, SA will auto-guess for you.
> (And the auto-guesser is notorious for failing if your MX is NAT mapped)
>
> And please, understand that "trust" here means "trusted to never forge a
> received header" not "trusted to never relay any spam".


I know this.

> In spamassassin, under trusting is BAD. It is just as bad as
> over-trusting. SA needs at least one trustworthy received header to work
> with.


How and why? Are you saying I *must* have a 2nd-level MX host for SA to
work? That's not my experience, and 2-layer relays are backscatter
sources. Milter from the local MTA works just fine.

> Also, to work properly, SA needs to be able to determine what is a part
> of your network, and what isn't. Unless you declare internal_networks
> separately, it bases internal vs external on the trust.


There is no network. There is only a single host. I don't control any
other host on the subnet.

> "trust no-one" is NOT a valid option, and would actually result in the
> problem you're suffering from. After all, if no headers are trusted, all
> email comes from no server, so SA would never be able to tell the
> difference between an email you really sent, vs a forgery from the outside.


This statement parses as nonsense. SA can't parse an e-mail because it
doesn't trust the source? Isn't that all e-mail?

> If your trust path is working properly, SA knows the difference. If it's
> not working, you get a broken AWL, broken RBLs, broken ALL_TRUSTED, and
> dozens of other broken things.


Okay, seriously I think you're both underestimating my understanding of
this and further confusing the matter by making all sorts of unclear
claims that don't reflect in reality.

I get trust paths. This issue I reported is not related to trust paths.
It's not a broken trust path problem. The e-mail came from an
untrusted source, but was given a negative AWL score based on the sender
name. That has nothing to do with trust.