ns1.daguru.net would have to be trusted for this to work. Otherwise anybody
could forge headers like this and there would be no way of knowing that the mail
really did come from paypal.com.

1. Is ns1.daguru.net trusted? If it is, then I have to fix whatever is
preventing the Received header with it from being used by the rule.

2. If it is not trusted, does it help to list it as trusted? If so, this is a
configuration problem, not a bug.

3. Is there some reason why it cannot be listed as trusted? What is the reason?
If so, we have to rethink this approach to deal with whatever is preventing this
site from being configured in a way that works.

Please let me know which is the case.

(copying reply into bugzsilla comments to keep the thread together)

Marc Perkel replied:
[begin quote]
No - it's not trusted - however - the first received line is from a legit paypal
server - so - can all the received lines be tested to see if ANY of them are legit?

The issue is - some people are getting the email delivered to Server A who then
sends it on to my server for spam processing. So - it should work in that
situation. Or - for backup MX servers that spool and forward when the main
server is down.
[end quote]

No, all Received lines cannot be tested to see if any of them say that this mail
which has a paypal.com From address was sent through a paypal.com server.

The only header{s} that can be tested for that are ones that SpamAssassin can
know are not forged.

The headers in this example say that ns1.daguru.net created a Received header
claiming that it received the mail from a server in the paypal.com domain. If
SpamAssassin cannot trust ns1.daguru.net then it cannot believe that header.
What if instead of ns1.daguru.net it was mail.spammer.biz?

The solution for backup MX servers is simple: They should be in the trusted
list. But if you run a SpamAssassin server that filters mail for people who send
it by mail redirection, that's trickier. I agree with you that this bug should
be left reopened as I think about it and I would appreciate any suggestions.

Subject: Re:  False Positives on FORGED_DEF_WHITELIST

How do you create "trusted" servers?

And - if the last received line is from a trusted server - can you then 
go back to the next level and test it?

You would have in the configuration a line like

trusted_networks 65.19.133.2

See man Mail::SpamAssassin::Conf for details. You can have more than one
trusted_networks options and there is syntax to specify a subnet.

That would tell SpamAssassin that 65.19.133.2 does not forge headers, meaning
that in this case the mail really was received from a paypal.com server.

Assuming that each site that you filter mail for has their own preferences,
their preferences would include their own mail server ip addfresses in
trusted_networks entries.

It's not a matter of "going back to the next level". As soon as you hit a
non-trusted server as you go back through the Received headers, SpamAssassin has
no way of knowing that anything after that is not forged, even if lower Received
headers claim to have servers that are on your trusted list.

Again, see the man page for details: You generally don't have to explicitly
declare your own servers as trusted, as that can be figured out automatically.
But your example is a case where you would need the configuration option.

Please let me know if that works out -- If it does we can close the bug again.

moving accuracy and some bugs to 3.1.0 milestone

with no updates in 7 months, and the fact it looks like a configuration issue,
I'm closing as wfm.