On 24 Nov 2015, at 17:20, David Jones wrote:
[...]
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?
No. See: http://www.scconsult.com/bogushelo.png (redacted screenshot of
the 2 test delivered messages) There's a real name (mostly redacted, but
you can see it's there) in those Received headers Postfix recorded the
name it got for the client via DNS at that time. The PTR for the client
IP resolved to a name which had an A record that resolved to the client
IP.
My point (probably obscured by verbosity...) is that whether Postfix
deems the client hostname to be "unknown" is not influenced in any way
by the HELO name. As a result, SA's RDNS_NONE is also not influenced by
the HELO name.
Pretty sure that
mine would. I am running Postfix 2.10.2 on a Redhat-based variant.
My tests were on my QA instance running unmodified Postfix 3.0.2 with a
relatively simple commonplace config. Based on the docs, this general
area of Postfix hasn't seen much change since 2.3, so I doubt your
system behaves differently.
I'd bet against you seeing "unknown" in a Postfix Received header just
because a HELO name was wrong.
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.
Precisely. Nothing has ever broken due to a HELO name being wrong but
valid (i.e. a string that COULD be a hostname) so there's nothing
working against persistent widespread wrongness.
Examining HELO arguments is generally worthless for generic rules, i.e.
ones that don't use key off the specific server (e.g. using a local
identity) or to particular bad actors/agents (e.g. 'EHLO ylmf-pc' is
ALWAYS a Cutwail spambot.) The only generic HELO test I've seen which
doesn't have a false positive rate over 1% is Postfix's
'reject_invalid_helo_hostname' which catches very little but is never
wrong.
