> On Nov 11, 2019, at 11:09 AM, Bill Cole
> <postfixlists-070...@billmail.scconsult.com> wrote:
>
>> mail.namase.de is the HELO (EHLO) name. You must not reject mail when helo
>> name differs from DNS name (RFC violation).
>
> True.
For the record, it is NOT an RFC violation for the EHLO name to
differ from the name in the PTR record of the connecting IP.
It suffices for the EHLO name to be some valid FQDN for the
client. Thus it is for example valid to have:
ehlo.example. IN A 192.0.2.1
ptr.example. IN A 192.0.2.1
1.2.0.192.in-addr.arpa. ptr.example.
The RFC merely says:
https://tools.ietf.org/html/rfc5321#section-4.1.1.1
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument clause contains the fully-qualified domain name
of the SMTP client, if one is available.
https://tools.ietf.org/html/rfc5321#section-2.3.5
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
https://tools.ietf.org/html/rfc5321#section-4.1.4
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have
an obvious name), an address literal SHOULD be substituted for the
domain name.
There is no requirement for any relationship between the EHLO name and
any PTR record for the connecting IP address.
> However, being a RFC violation is not by itself a sound reason to reject any
> particular mail security tactic.
Yes, even when moot.
--
Viktor.
