sorry for the long pause but during the weekend I didn't have enough spare time to think about this thoroughly.
And sorry for my long pause.. I was off-site Monday, and yesterday I was playing catch-up. Urgh.
I don't think I mis-read your message but after reading your latest answer I am not sure about anything anymore. This starts to get confusing.
> Stop reading into the meaning of trusted_networks... Read exactly what I > told you to do. Since the first day that I had installed SA on my servers I had trusted_networks set to the IP of the machine where SA is running on. So I thought that part of your mail can't be the solution. Rich Puhek's answer calmed my fears because he said that my mail to the list didn't get high scores. Well, so that leaves the (hopefully simpler) problem that _my_ spamassassin scores mails from dialup IPs too high.
Maybe my problem (or our misunderstanding) is that SA is not running on my local machine (condor) but on my smart host. We have several machines which are acting as receiving mail servers and as smart hosts (using SMTP Auth). All incoming mails from outside are piped through SA and local.cf contains the IPs of all these servers like so: trusted_networks host1.xx.yy.zz host2.xx.yy.zz host3.xx.yy.zz ...
"host1.xx.yy.zz"... I do hope that's an IP address, and not a hostname.. Is it?
Now.. let's give a symbolic name to your smarthosts running SA.. lets call them "saserver1" "saserver2" etc..
Using that syntax.. does trusted_networks on "saserver1" contain "saserver1"?
Unfortunately not. I had my server(s) in trusted_networks from the beginning but for example my own mails to the list get tagged this way: X-Spam-Scores: AWL=-1.348,BAYES_00=-4.9,RCVD_IN_DYNABLOCK=2.599, RCVD_IN_NJABL=0.1,RCVD_IN_NJABL_DIALUP=3.536,RCVD_IN_SORBS=0.1, USER_IN_WHITELIST=-100
BTW that's why I was assuming that others see my mails like that, too. If you could explain me why my SA acts like that I'd be really grateful.
Hopefully I can help out.
In depth the common cause of this problem is a cascade of events:
First, when attempting to determine the trust path. SA fails to find any trusted hosts in the Received headers. This means the number of trusted headers is 0.
When SA encounters a situation where no headers are trusted. ALL rules are run against ALL Received headers. Matters of trust, first-hop, etc are completely ignored and disabled.
However, if SA determines it can trust any of the Received: headers (which it should be able to trust the one added by the local host), it will enable it's trust-path code and the first-hop skip code works properly.
