f



what does this authentication warning mean?

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.
0
Mike
7/12/2016 7:55:30 AM
comp.mail.sendmail 13518 articles. 1 followers. jfretby (35) is leader. Post Follow

6 Replies
130 Views

Similar Articles

[PageSpeed] 25

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
0
J
7/13/2016 5:05:39 AM
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.
0
Claus
7/13/2016 4:01:26 PM
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?



-- 
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex
"The only way is Brexit" -- anon.
0
Mike
7/14/2016 2:57:14 PM
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).


-- 
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.
0
Claus
7/18/2016 4:22:50 AM
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 :-)


-- 
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex
"The only way is Brexit" -- anon.
0
Mike
8/15/2016 1:46:54 PM
-----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
Carl
8/15/2016 3:00:54 PM
Reply: