>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.

Reply via email to