>From: Bill Cole <sausers-20150...@billmail.scconsult.com> >Sent: Tuesday, November 24, 2015 3:31 PM >To: users@spamassassin.apache.org >Subject: Re: question re/ RDNS_NONE
>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? I didn't mean to imply that this check is being done in SA. Just meant to show the parts of a FCrDNS check and that one of those checks is effectively being done by Postfix putting in the 'unknown' when the PTR lookup doesn't have a matching A record. SA seems to be seeing this 'unknown' in the Received header and hitting the RDNS_NONE rule on my 8 mail filters. >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. I do not have any setting in my Postfix main.cf that would do that. Just the standard smtpd_recipient_restrictions entries: ... reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_non_fqdn_hostname, reject_invalid_hostname, reject_unauth_destination, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unknown_reverse_client_hostname, reject_unlisted_sender, reject_unlisted_recipient, ... >> 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. I do see these often and they do not hit RDNS_NONE in SA. >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. You don't see 'unknown' in the Received: header? Pretty sure that mine would. I am running Postfix 2.10.2 on a Redhat-based variant. >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. If I enable reject_unknown_helo_hostname, then I start blocking a lot of legit email from poorly configured servers.
