On 30 May 2016, at 15:07, Alex wrote:
Yeah, that's it exactly. Particularly overseas where it doesn't appear NAT and/or submission are used as readily as they are here.
Irrelevant in this case because if you trust that header not to be an intentionally deceptive lie, the receiving server claims the mail was received with authentication, making it very unlikely that the message is spam. That is what "with esmtpa" in an Exim Received header means, and your other rule hits indicate that you trust 116.251.209.92 (vio1.naveca.biz) so I don't quite get why this didn't also hit "ALL_TRUSTED" and why SA is doing DNSBL checks on the authenticated client of a trusted host.
And in ANY case, getting *a customer* to use port 587 submission with authentication over an encrypted channel directly to your server instead of trusting an intermediate machine that maybe should not be trusted should not be hard. Even shoddy PHP mailing scripts these days can handle it. If you are nominally selling any sort of email service to that customer and not requiring them to submit though your server to be treated as a trusted customer, you're making a mistake.
So even though that IP is on virtually every blacklist, you wouldn't add any points? And there's nothing further the user could do to fix the problem, given the dynamic nature of the IP?
I think there's a more complex problem in this case that is not evident in a single Received header and list of SA hits.
Note that the IP you are worried about was at the time you scanned its output and was still today either itself a badly compromised system or is a shared NAT address with one or more compromised systems behind it, and either way: it is an ongoing source of spam of the worst sorts to the outside world. It isn't listed because it's a dynamic IP, it's listed because it's an active ongoing spamming IP.
(and to answer the original question: I don't trust other people's mail servers to tell me the truth about where they get mail, so my SA instances don't ever hit those rules. However, I would NEVER make a mailspike 'none' listing contribute to anything at all, even as a meta rule. LOC_MULTI_RBL seems like a bad idea, whatever it is...)
