>From: RW <rwmailli...@googlemail.com> >Sent: Saturday, November 21, 2015 1:43 PM >To: users@spamassassin.apache.org >Subject: Re: question re/ RDNS_NONE
>On Sat, 21 Nov 2015 15:35:54 +0000 >David Jones wrote: >> Read the Received headers from the bottom up. >> >> Received: from [93.104.16.254] (helo=localhost.unixarea.de) >> >> This IP has a lot of issues and will always hit RDNS_NONE because >> there is no way to make the FCrDNS check pass to match the SMTP HELO >> of localhost.unixarea.de. >You missed the next line: > by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) >This is a submission header, so the DNS of 93.104.16.254 doesn't >matter. Thank you for pointing that out. Also now that we know that SA is running on a local netbook, it would make sense that the problem server is 178.254.4.77. It's SMTP HELO is imap.1blu.de but it's forward and reverse DNS is mf-13.1blu.de. Interesting that this Received header was added via IMAP. That IP or subnet could be added to the trusted_networks list if it's always going to be in there. If it's the ISP's hosting mail server then it needs to be skipped to get back to the first public IP that sent to smtp.1blu.de. The server before smtp.1blu.de should be the one where all of the network checks are done. https://wiki.apache.org/spamassassin/Rules/RDNS_NONE RDNS_NONE checks more than just the PTR (reverse) DNS record. It really should be named FCRDNS_NONE or better yet FCRDNS_FAILED since some of the parts could be present but all 3 of them didn't line up. It's easy for 2 of the 3 to be correct but you have to know what you are doing and usually be a legit sender to get all 3 parts correct. Correct FCrDNS is crucial to having reliable outbound delivery to the Internet.