On 24 Nov 2015, at 14:54, David Jones wrote:
From: Bill Cole <sausers-20150...@billmail.scconsult.com>
Sent: Tuesday, November 24, 2015 1:41 PM
To: users@spamassassin.apache.org
Subject: Re: question re/ RDNS_NONE
On 24 Nov 2015, at 13:47, David Jones wrote:
Could this be dependent on the MTA used? I am using Postfix
which puts in Received headers like this:
Received: from econnect.dmsgs.com (unknown [8.224.216.57])
That IP has a PTR record but it doesn't match the SMTP HELO of
econnect.dmsgs.com so Postfix is putting in the 'unknown' causing
the RDNS_NONE hit on more than just no rDNS.
Incorrect. The HELO name (econnect.dmsgs.com) is not involved at all
in
why Postfix puts 'unknown' inside the parentheses.
Thank you for that clarification. However what you describe below
is one part of FCrDNS (a.k.a full circle DNS) check. The second part
would be the PTR record matching the SMTP HELO.
Where is the code or rule in SpamAssassin which performs that check?
In Postfix there is no such check that I am aware of, either by default
or with any of the optional smtpd_helo_restrictions settings. Can you
point to it in the Postfix docs? What you describe is NOT part of the
optional "reject_unknown_helo_hostname", which only requires a resolving
HELO name.
So this still means
that the RDNS_NONE check is more than just a missing PTR record
when using Postfix.
No PTR at all OR (as in the case you cited) a PTR to a name which
doesn't resolve back to the IP will (if you allow Postfix to accept mail
from such mismanaged machines) result in "unknown" being used where
otherwise a correct hostname would go: inside parentheses, before the
brackets-enclosed IP. The HELO name, *WHATEVER IT IS* is put right
after the word 'from' before the parentheses.
NOTE: I have just now tested that I can give Postfix (with
reject_unknown_helo_hostname not enabled) a fully-qualified HELO name
that has no A or one with an A resolving to 192.0.2.1 (and therefore: no
PTR) and in both cases Postfix neither logs anything about the "bad"
name nor indicates any DNS discrepancy in its Received header.
SpamAssassin's hits on the messages I sent myself that way include no
rules involving DNS or HELO names.
Apart from whether Postfix or SA actually can be made to compare the
result of a client IP PTR resolution to the HELO name or of a HELO A
result to the client IP, such verification is operationally worthless.
There are far too many innocently misconfigured MTAs claiming to be
localhost.localdomain or exchange01.local or whatever other default name
is the flavor of the month to arbitrarily ignore RFC5321 and send them
away. It generally IS safe to require that a HELO name be syntactically
valid and not match a few patterns chronically used by spambots but
unless you're fond of maintaining whitelists or of teaching users and a
particularly dense sub-population of admins about wise DNS hygiene,
validating HELO names tightly is wasted effort.
