https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6645
--- Comment #18 from [email protected] 2011-08-08 07:51:38 UTC --- (In reply to comment #17) > I'm confused. Receiving SpamAssassin installations should only be doing > dial-up DNSBL checks on the relay that connects to them. They should not be > doing it on relays all throughout the received chain. > > Your sample header appears to be generated from systems entirely local to your > network. With 192.168.0.0/16 addresses, I'm not surprised that the initial > client is being checked. In a case like this you need to define your > MSA_NETWORKS. Spamassassin won't check the sender's IP if it would correctly detect the authentication against the relay. I don't think you have tried running "spamassassin -t < file" with file being my test header and spotted the difference that correct header detection makes. If it knows qmail-scanner-2.05st headers it seems to work correctly in either case. > Please provide an actual header sample that includes the received header of > the > remote network to demonstrate the issue you have described. You won't get any other header sample from me because real-world sample would look the same (imagine a big network using internal ip ranges between several dislocated departments with the feature that you don't know every other mail server in this network). As the problem depends on spamassassin not correctly detecting the header forget the internal ips at the moment, because it would work with correct detection. It can be that this special case causes extra problems, but the source of this particular problem seems to be the missing detection for newer/authenticated qmail-scanner-headers. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
