client and ehlo hostname mismatch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

client and ehlo hostname mismatch

Eugene Podshivalov
Hello,

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?

--Eugene
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Bill Cole-3
On 10 Feb 2021, at 14:41, Eugene Podshivalov wrote:

> Hello,
>
> 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?

In  principle, yes. In reality, they very often do not, even with
entirely legitimate email.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Bob Proulx
In reply to this post by Eugene Podshivalov
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?

It's been an old traditional recommendation and best practice.

    https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS

RFC1912 dates from 1996.  Back then we could count the number of
systems on the Internet.  Possibly someone knew each of them
individually!  I'm not saying it wasn't possible then.  And requiring
reverse DNS to map was one way to avoid dynamically assigned
addressing often used by abusers.  But now there are so many systems
on the network and they change so fast that this is definitely not
possible now.

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.

Instead of Forward-Reverse-DNS matching the newer Best Practice is to
set up SPF, DKIM, DMARC for your own outgoing mail and other
anti-abuse for incoming mail.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Dirk Stöcker
On Wed, 10 Feb 2021, 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?
>
> It's been an old traditional recommendation and best practice.
>
>    https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS
>
> RFC1912 dates from 1996.  Back then we could count the number of
> systems on the Internet.  Possibly someone knew each of them
> individually!  I'm not saying it wasn't possible then.  And requiring
> reverse DNS to map was one way to avoid dynamically assigned
> addressing often used by abusers.  But now there are so many systems
> on the network and they change so fast that this is definitely not
> possible now.

The more important question is how many services are running on a single
host. It's not uncommon that a host has more than one purpose and thus
also multiple domain names. With IPv4 this means DNS and reverse DNS
cannot match, as you always can satisfy only one of the services (except
you have too many IPv4 addresses).

E.g. my mail server mail.stoecker.eu resolves correctly for the IPv6
address, but for v4 the name differs.

Ciao
--
https://www.dstoecker.eu/ (PGP key available)
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Viktor Dukhovni
In reply to this post by Bob Proulx
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 | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Eugene Podshivalov
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 <[hidden email]>:
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 | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Viktor Dukhovni
On Wed, Feb 10, 2021 at 11:59:39PM +0300, Eugene Podshivalov wrote:

> > 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?

Postfix can check that the EHLO name resolves to some IP address.  There
is no check that the address is that of the connecting client, because
that is not a sufficiently useful policy criterion.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Eugene Podshivalov
Viktor Dukhovni:
Postfix can check that the EHLO name resolves to some IP address.
Then what is the sense of doing this if the name can be whoever else's name?
 
чт, 11 февр. 2021 г. в 00:03, Viktor Dukhovni <[hidden email]>:
On Wed, Feb 10, 2021 at 11:59:39PM +0300, Eugene Podshivalov wrote:

> > 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?

Postfix can check that the EHLO name resolves to some IP address.  There
is no check that the address is that of the connecting client, because
that is not a sufficiently useful policy criterion.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Viktor Dukhovni
On Thu, Feb 11, 2021 at 12:15:32AM +0300, Eugene Podshivalov wrote:

> > Viktor Dukhovni:
> > Postfix can check that the EHLO name resolves to some IP address.
>
> Then what is the sense of doing this if the name can be whoever else's name?

Spam bots are sloppy, and typicall default to the name from the RHS of
the PTR.  If that has no forward name, and you require a forward IP
then you'll block them.

I would not recommend a global rule of that sort.  Rather, I do this
selectively for name suffixes from various ISP dynamic pools that I've
observed to sources of repeat spam that evades other filters and where
filtering the HELO is effective.  My filters are fairly light, some
junk gets through, but I don't lose legitimate mail.  I'm willing to
engage in occasional whack-a-mole updates to some of the local rules.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Bob Proulx
In reply to this post by Eugene Podshivalov
Eugene Podshivalov wrote:
> Then what is the sense of doing this if the name can be whoever else's name?

For anti-spam and anti-abuse software.  It's all available for the
anti-spam to use to decided how to classify the message.  Perhaps not
as a hard block as that would definitely have false positives.  But as
part of a larger scoring system it can add to the filter analysis.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Eugene Podshivalov
Are there any wise cases for a legitimate client to provide a valid ehlo hostname (which maps to some address) but that address will differ from the address it connects from?

чт, 11 февр. 2021 г. в 01:01, Bob Proulx <[hidden email]>:
Eugene Podshivalov wrote:
> Then what is the sense of doing this if the name can be whoever else's name?

For anti-spam and anti-abuse software.  It's all available for the
anti-spam to use to decided how to classify the message.  Perhaps not
as a hard block as that would definitely have false positives.  But as
part of a larger scoring system it can add to the filter analysis.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Viktor Dukhovni
> On Feb 10, 2021, at 9:38 PM, Eugene Podshivalov <[hidden email]> wrote:
>
> Are there any wise cases for a legitimate client to provide a valid ehlo
> hostname (which maps to some address) but that address will differ from
> the address it connects from?

I don't know about "wise", but this is not uncommon.

As an example of a less blatant mismatch, today I received a legitimate
newsletter from Cornell:

  Received: from mm.list.cornell.edu (vs-01.mm.list.cornell.edu [128.253.150.167])

The EHLO name resolves to the same IP as the connecting client, but
the PTR is a variant of that name.

Here the sort of mismatch you're asking about:

  Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5a::72c])

The EHLO name (presently) resolves to:

        $ getent hosts NAM12-MW2-obe.outbound.protection.outlook.com
        2a01:111:f400:fe5a::200 NAM12-MW2-obe.outbound.protection.outlook.com

        $ getent hosts mail-mw2nam12on2072c.outbound.protection.outlook.com
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

        $ getent hosts 2a01:111:f400:fe5a::72c
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Cooper, Robert A

My primary outbound relay cluster connects through a load balancer NAT so when it gives "helo host1.services.domain.tld" it actually reverses to the hostname assigned to the load balancer (relay.domain.tld).  there are multiple nodes that all lookup with the single NAT IP when connecting outbound.


RobertC


(Sorry for top-posting, I can't find any options in Outlook Web to change the reply thread settings!)




From: [hidden email] <[hidden email]> on behalf of Viktor Dukhovni <[hidden email]>
Sent: Wednesday, February 10, 2021 18:39
To: [hidden email]
Subject: Re: client and ehlo hostname mismatch
 
> On Feb 10, 2021, at 9:38 PM, Eugene Podshivalov <[hidden email]> wrote:
>
> Are there any wise cases for a legitimate client to provide a valid ehlo
> hostname (which maps to some address) but that address will differ from
> the address it connects from?

I don't know about "wise", but this is not uncommon.

As an example of a less blatant mismatch, today I received a legitimate
newsletter from Cornell:

  Received: from mm.list.cornell.edu (vs-01.mm.list.cornell.edu [128.253.150.167])

The EHLO name resolves to the same IP as the connecting client, but
the PTR is a variant of that name.

Here the sort of mismatch you're asking about:

  Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5a::72c])

The EHLO name (presently) resolves to:

        $ getent hosts NAM12-MW2-obe.outbound.protection.outlook.com
        2a01:111:f400:fe5a::200 NAM12-MW2-obe.outbound.protection.outlook.com

        $ getent hosts mail-mw2nam12on2072c.outbound.protection.outlook.com
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

        $ getent hosts 2a01:111:f400:fe5a::72c
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Eugene Podshivalov
Bob Proulx:
Instead of Forward-Reverse-DNS matching the newer Best Practice is to
set up SPF, DKIM, DMARC for your own outgoing mail and other
anti-abuse for incoming mail.

Is it safe enough nowadays to drop dmarc failed incoming mail with opendmarc?

чт, 11 февр. 2021 г. в 08:46, Cooper, Robert A <[hidden email]>:

My primary outbound relay cluster connects through a load balancer NAT so when it gives "helo host1.services.domain.tld" it actually reverses to the hostname assigned to the load balancer (relay.domain.tld).  there are multiple nodes that all lookup with the single NAT IP when connecting outbound.


RobertC


(Sorry for top-posting, I can't find any options in Outlook Web to change the reply thread settings!)




From: [hidden email] <[hidden email]> on behalf of Viktor Dukhovni <[hidden email]>
Sent: Wednesday, February 10, 2021 18:39
To: [hidden email]
Subject: Re: client and ehlo hostname mismatch
 
> On Feb 10, 2021, at 9:38 PM, Eugene Podshivalov <[hidden email]> wrote:
>
> Are there any wise cases for a legitimate client to provide a valid ehlo
> hostname (which maps to some address) but that address will differ from
> the address it connects from?

I don't know about "wise", but this is not uncommon.

As an example of a less blatant mismatch, today I received a legitimate
newsletter from Cornell:

  Received: from mm.list.cornell.edu (vs-01.mm.list.cornell.edu [128.253.150.167])

The EHLO name resolves to the same IP as the connecting client, but
the PTR is a variant of that name.

Here the sort of mismatch you're asking about:

  Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5a::72c])

The EHLO name (presently) resolves to:

        $ getent hosts NAM12-MW2-obe.outbound.protection.outlook.com
        2a01:111:f400:fe5a::200 NAM12-MW2-obe.outbound.protection.outlook.com

        $ getent hosts mail-mw2nam12on2072c.outbound.protection.outlook.com
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

        $ getent hosts 2a01:111:f400:fe5a::72c
        2a01:111:f400:fe5a::72c mail-mw2nam12on2072c.outbound.protection.outlook.com

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Dominic Raferd
On 11/02/2021 09:32, Eugene Podshivalov wrote:
>
> Is it safe enough nowadays to drop dmarc failed incoming mail with
> opendmarc?

I would say not. I quarantine DMARC failures but do not reject - there
are still fps because of misconfiguration by senders or mailing lists
that are not DMARC-friendly (including, ironically, opendmarc-users).

Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Matus UHLAR - fantomas
In reply to this post by Eugene Podshivalov
>> 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.

On 10.02.21 23:59, Eugene Podshivalov wrote:
>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?

It's quite comnon to fill smtpd_helo_restrictions with
reject_unknown_helo_hostname,
reject_invalid_helo_hostname, and
reject_non_fqdn_helo_hostname.

you can also disable concrete strings by using check_helo_access

...but set smtpd_helo_required to "yes" or clients can avoid that by not using
helo/ehlo at all.


there's no setting to reject HELO name that doesn't resolve to IP of a
client, mostly because it violates so far all SMTP RFCs.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Matus UHLAR - fantomas
In reply to this post by Eugene Podshivalov
>> Bob Proulx:
>> Instead of Forward-Reverse-DNS matching the newer Best Practice is to
>> set up SPF, DKIM, DMARC for your own outgoing mail and other
>> anti-abuse for incoming mail.

On 11.02.21 12:32, Eugene Podshivalov wrote:
>Is it safe enough nowadays to drop dmarc failed incoming mail with
>opendmarc?

yes, however that has nothing to do with helo.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Bastian Blank-3
In reply to this post by Eugene Podshivalov
Hi

On Thu, Feb 11, 2021 at 12:32:25PM +0300, Eugene Podshivalov wrote:
> Is it safe enough nowadays to drop dmarc failed incoming mail with
> opendmarc?

No.  You can reject them however.

Bastian

--
Prepare for tomorrow -- get ready.
                -- Edith Keeler, "The City On the Edge of Forever",
                   stardate unknown
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Bill Cole-3
In reply to this post by Eugene Podshivalov
On 11 Feb 2021, at 4:32, Eugene Podshivalov wrote:

> Is it safe enough nowadays to drop dmarc failed incoming mail with
> opendmarc?

No. It very likely never will be, particularly as long as Sendmail is in
widespread use.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: client and ehlo hostname mismatch

Benny Pedersen-2
On 2021-02-11 15:12, Bill Cole wrote:
> On 11 Feb 2021, at 4:32, Eugene Podshivalov wrote:
>
>> Is it safe enough nowadays to drop dmarc failed incoming mail with
>> opendmarc?
>
> No. It very likely never will be, particularly as long as Sendmail is
> in widespread use.

why ?

is it the 8bitmime problem signing 8bitmime content ?, or other problems
?

reference amavisd how to dkim sign
12