Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

what does this authentication warning mean?

152 views
Skip to first unread message

Mike Scott

unread,
Jul 12, 2016, 3:55:32 AM7/12/16
to
I'm getting sendmail log messages like

Jul 12 06:29:07 data sendmail[9210]: Authentication-Warning:
data.scotts: Host [39.54.122.34] claimed to be 39.54.122.34

(data.scotts being my sendmail server)

Can someone say exactly why this merits a warning please? A host
claiming to be itself doesn't seem so dreadful a thing! :-}

TIA

--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex
"The only way is Brexit" -- anon.

J.O. Aho

unread,
Jul 13, 2016, 1:05:35 AM7/13/16
to
On 07/12/16 09:55, Mike Scott wrote:
> I'm getting sendmail log messages like
>
> Jul 12 06:29:07 data sendmail[9210]: Authentication-Warning:
> data.scotts: Host [39.54.122.34] claimed to be 39.54.122.34
>
> (data.scotts being my sendmail server)
>
> Can someone say exactly why this merits a warning please? A host
> claiming to be itself doesn't seem so dreadful a thing! :-}


I guess it's this scenario:

Host name1 claimed to be name2
In the HELO message of an SMTP conversation the remote host name1
specified its canonical name as name2, and the two didn't match. This
always indicates a problem. Either the remote host is misconfigured (a
bad value in $j; see Section 31.10.20), the DNS maps for that host are
wrong, or someone is trying to spoof the local sendmail.

copy'n'past from http://www.c3.hu/docs/oreilly/tcpip/sendmail/ch35_10.htm

I would guess it can have to do with that the host do not connect and
use it's host name and that ip don't resolve to a host name.

Think you need to fix your DNS settings to get rid of the message.


--

//Aho

Claus Aßmann

unread,
Jul 13, 2016, 12:10:04 PM7/13/16
to
Mike Scott wrote:

> data.scotts: Host [39.54.122.34] claimed to be 39.54.122.34

> Can someone say exactly why this merits a warning please? A host
> claiming to be itself doesn't seem so dreadful a thing! :-}

AFAICT:

[39.54.122.34] != 39.54.122.34


--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Mike Scott

unread,
Jul 14, 2016, 10:57:16 AM7/14/16
to
On 13/07/16 17:01, Claus Aßmann wrote:
> Mike Scott wrote:
>
>> data.scotts: Host [39.54.122.34] claimed to be 39.54.122.34
>
>> Can someone say exactly why this merits a warning please? A host
>> claiming to be itself doesn't seem so dreadful a thing! :-}
>
> AFAICT:
>
> [39.54.122.34] != 39.54.122.34
>
>
Well, true.

But the host isn't pretending to be who it isn't.

After a quick look at rfc5321, I'm wondering if the problem is down to
the client using a bad ehlo line. If I read correctly, if you're not
using a domain name, you use an address literal, which has square
brackets. So is the example I gave complaining that my server has
checked the client IP, and is saying it expects the client to say
ehlo [39.54.122.34]
whereas it /actually/ says
ehlo 39.54.122.34

Right reasoning???


Which leads me to a long-standing mis-configuration of my own mail
server - it's behind a natted router on a dynamic IP - which conspires
to mean it's nigh impossible to send a fully correct ehlo line. The
sendmail server doesn't know the public IP, so I can't use an address
literal. Any domain name has to be an A (AAAA) record for the public IP
(why???!), which again doesn't really work unless I use the dynamic IP
provider name which doesn't seem a good thing to make public (and bad in
principle). The saving grace is the server "MUST NOT" refuse mail
because of a mismatch here. Is there a good solution though?

Claus Aßmann

unread,
Jul 18, 2016, 12:40:02 AM7/18/16
to
Mike Scott wrote:

> checked the client IP, and is saying it expects the client to say
> ehlo [39.54.122.34]
> whereas it /actually/ says
> ehlo 39.54.122.34

> Right reasoning???

Yes. You could even look at a transcript of an SMTP session...

Or you could turn off the compile time option PICKY_HELO_CHECK.

See also "WHO AM I" in cf/README.


> Which leads me to a long-standing mis-configuration of my own mail
> server - it's behind a natted router on a dynamic IP - which conspires
^^^^^^

> to mean it's nigh impossible to send a fully correct ehlo line. The
> sendmail server doesn't know the public IP, so I can't use an address
> literal. Any domain name has to be an A (AAAA) record for the public IP
> (why???!), which again doesn't really work unless I use the dynamic IP
> provider name which doesn't seem a good thing to make public (and bad in
> principle). The saving grace is the server "MUST NOT" refuse mail
> because of a mismatch here. Is there a good solution though?

Your "mails server" is only acting as a client on the internet, right?

This looks more like a DNS/network setuo problem, not a real sendmail
problem (except that SMTP and hence sendmail have specific requirements
about (valid) host/domain names etc).

Mike Scott

unread,
Aug 15, 2016, 9:46:56 AM8/15/16
to
On 18/07/16 05:22, Claus Aßmann wrote:
...
> Or you could turn off the compile time option PICKY_HELO_CHECK.

Yes; I used to have this, but since a freebsd upgrade have reverted back
to the supplied binary which has this enabled.

>
> See also "WHO AM I" in cf/README.
>
>
>> Which leads me to a long-standing mis-configuration of my own mail
>> server - it's behind a natted router on a dynamic IP - which conspires
> ^^^^^^
>
>> to mean it's nigh impossible to send a fully correct ehlo line. The
>> sendmail server doesn't know the public IP, so I can't use an address
>> literal. Any domain name has to be an A (AAAA) record for the public IP
>> (why???!), which again doesn't really work unless I use the dynamic IP
>> provider name which doesn't seem a good thing to make public (and bad in
>> principle). The saving grace is the server "MUST NOT" refuse mail
>> because of a mismatch here. Is there a good solution though?
>
> Your "mails server" is only acting as a client on the internet, right?

No. I'm using sendmail as a smarthost on my home LAN. My domain has MX
records pointed here and I handle incoming email myself (benefiting both
privacy and spam rejection). Everything from the desktop boxes is
directed there, and it alone can send mail to my ISP's server - which is
where I see the potential problem on the HELO line, as I've no way of
providing a strictly correct address parameter (as described above)

(Apologies for delay following up; several personal issues have been
occluding the merely technical :-)

Carl Byington

unread,
Aug 15, 2016, 11:00:55 AM8/15/16
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 15 Aug 2016 14:46:54 +0100, Mike Scott wrote:

> My domain has MX records pointed here and I handle incoming email
> myself (benefiting both privacy and spam rejection).

What is the domain name? You apparently have some name for the rhs of
the MX record, and that name has an A record that points to your dynamic
public ip address. Why not use that name in your HELO?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlex2QwACgkQL6j7milTFsHzxwCfQu8OvUVgGuPXz6ZBqhzCAPxU
PZYAoIN49hjM/rVl/ORiObtxkzDHWyvz
=HIeB
-----END PGP SIGNATURE-----
0 new messages