On 16 Sep 2014, at 17:24, AndreaML wrote:
hello all,
I am used to have in the config reject_unknown_hostname in the
smtpd_helo_restrictions and for literally years my mailserver were
good.
You were lucky.
That setting (in modern Postfix 'reject_unknown_helo_hostname') has
never been safe.
BUT in the last months, say from the start of the year i am rejecting
more and
more messages from reliable sources as the mail servers of pieces of
italian
government and some very big ISPs like FastWeb.
This is not a universal trend, it is a quirk of your particular
mailstream and/or environment. Otherwise legitimate MTA's have been
using variously bogus HELO/EHLO names for all of the past 23 years and
probably for all of the history of SMTP.
One factor which MAY be increasing the appearance of more failures is
the gradual migration towards IPv6. It is increasingly common for DNS
resolvers to support IPv6 by default and run on machines where IPv6 is
enabled but where there is no (or limited) IPv6 connectivity. This can
cause a resolver to query IPv6 NS addresses that it can't actually
reach, potentially resulting in resolution failures.
My log files are filled with (example)
Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT
from
wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 <wr001msr.intranet.fw>:
Helo
command rejected: Host not found; from=<VALID_ADDRESS>
to=<VALID_ADDRESS>
proto=ESMTP helo=<wr001msr.intranet.fw>
for a transaction of a prefectly valid test email i sent to myself.
More and more i see large installations with EHLOs to some local
intranet
names and thus not resolvable host names in dns provoking the reject
in my
postfix.
Is it also your experience? Has reject_unknown_hostname less and less
use in
favour of other anti-spam methods?
I am unaware of it ever being widely used. Note that RFC2821 S4.1.4
explicitly states:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
This is essentially a restatement of RFC1123 S5.2.5 and was retained in
RFC5321. Of course RFCs are not laws & one is free to do whatever one
feels like doing in deciding how to determine whether or not to accept
mail, but for 25 years the RFCs have been vehemently discouraging
verification of the HELO/EHLO argument *because* it has always been
well-known that such verification often fails for mail that is otherwise
entirely legitimate.
It is much safer to use 'reject_invalid_helo_hostname' or
'reject_non_fqdn_helo_hostname' or for maximal safety to use a
'check_helo_access' map to specifically reject HELO names & patterns
that fingerprint spambots (e.g. 'friend', 'ylmf-pc', '[127.0.0.1]', your
own local names/IPs, etc.) or gross incompetence (unqualified names,
*.local, etc.) and perhaps to exempt special cases where you are willing
to tolerate incompetence.
because in a server with 5000 mailbox and 80k-100k messages a day,
that
setting free me of 20k-30k spam messages easily, but catch these large
institutions.
i am just a bit confused. what is your experience on this?
I've never used that option with Postfix or any analogous setting in
other MTAs, but I have looked at it as a possibility a few times. When I
last examined it in depth (2007, at a site getting ~10E6 SMTP sessions
per day, because one IT manager had one spam with a bad HELO) the
overwhelming majority (>98%) of SMTP clients using unresolvable HELO
names that were not known sources of legitimate mail were also
identifiable as undesirable by some other mechanism before DATA (which
included a set of telltale HELO patterns.) It simply didn't matter that
we were not rejecting unresolvable HELO names, because the *marginal*
effect of doing so would have been many more more false positives than
additional actual spam being caught.
There are a lot of reasons that may not reflect your system today but
the important point that does is that you should focus on the net
marginal effect of that option instead of the raw fact that it catches a
huge pile of probable spam very early.
