>
> Viktor Dukhovni:
> The actual expectation is that the EHLO name is a valid DNS hostname,
> and should resolve to the IP address of the client.


Postfix does not seem to be able to check this right now. Wouldn't it be
good to have such features in smtpd_helo_restrictions?

ср, 10 февр. 2021 г. в 23:38, Viktor Dukhovni <postfix-us...@dukhovni.org>:

> On Wed, Feb 10, 2021 at 01:20:23PM -0700, Bob Proulx wrote:
> > Eugene Podshivalov wrote:
> > > I've just received a spam email from a client who presented itself as
> > > emx.mail.ru but its ip 117.30.137.22 resolves to
> > > 22.137.30.117.broad.xm.fj.dynamic.163data.com.cn
> > >
> > >  Are reverse client hostname and the ehlo one not supposed to match?
> >
> > And now some very large service providers will not provide Reverse-DNS
> > mapping for server's IP addresses.  This means that valid servers will
> > not be able to have a valid reverse mapping.  This means that if one
> > hard blocks on this full circle validity check then they will drop
> > valid email and people will not be happy.
>
> The actual expectation is that the EHLO name is a valid DNS hostname,
> and should resolve to the IP address of the client.  This is not always
> the same as the IP address resolving back to that name.
>
> Thus for a client connecting from 192.0.2.1 with an EHLO name of
> "ehlo.example" we might find a set of DNS records of the form:
>
>     ehlo.example.   IN A 192.0.2.1
>     1.2.0.192.in-addr.arpa. IN PTR some.name.example.
>     some.name.example. IN A 192.0.2.1
>
> Where the EHLO name is consistent with the connecting IP address when
> mapped forward from the name to the address.  Also the IP address has a
> PTR record, which in turn maps back that name, which may be different
> from the EHLO name.
>
> Best practice is for both names to be the same, but this is not
> required.  And sometimes either or both of the forward mappings may be
> missing or may map to a different address.
>
> --
>     Viktor.
>

Reply via email to