On 11 Nov 2019, at 8:47, Matus UHLAR - fantomas wrote:
On 11.11.19 14:27, ratatouille wrote:
Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
I would like to reject incoming email if dns- and rdns-entries
differ.
Does this make sense and how could I achieve this?
they do not differ above. The IP 62.173.139.77, rDNS is
s1.bomberg.city and
points back to 62.173.139.77.
If the 62.173.139.77 did not have reverse name, or its reverse name
(s1.bomberg.city
here) would not point back to 62.173.139.77, you'd see unknown instead
of
s1.bomberg.city (the DNS name).
You can reject those cases by reject_unknown_client_hostname (either
fails)
Which is unsafe, if you care about not rejecting even small amounts of
legitimate mail from some systems that transport large amounts of
legitimate mail.
or reject_unknown_reverse_client_hostname (IP has no reverse DNS, no
matter
if it points back).
The 2nd clause inside the parentheses is redundant. :)
reject_unknown_reverse_client_hostname is much safer than
reject_unknown_client_hostname. In many years of using it I have only
seen a handful of undesirable rejections due to it or its analogs with
other MTAs. In every case, those have been due to objectively and
transiently broken DNS.
mail.namase.de is the HELO (EHLO) name. You must not reject mail when
helo
name differs from DNS name (RFC violation).
True.
However, being a RFC violation is not by itself a sound reason to reject
any particular mail security tactic. RFC821, RFC822, and their
descendants are strongly influenced by the Postel's Robustness
Principle. Unfortunately, that has historically meant that MTA
implementations tolerate practices that are useful for spammers or are
simply wrong and idiosyncratic to particular spammers or spamming tools.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
