sendmail and new gTLDs (.hermes)

[LC's No-Spam Newsreading account]

We have internally several machines with different versions of SUSE and
sendmail. Our users are dispersed on several machines (some receive
locally, some receive on an IMAP server). Let us consider the following
cases:

A) Sendmail 8.14.4/8.14.4 (Suse 11.3)
B) Sendmail 8.14.7/8.14.9 (Suse 13.1)
C) Sendmail 8.14.7/8.14.4 (Suse 13.1) this is also an IMAP server
D) Sendmail 8.14.9/8.14.9 (Suse 13.2)

Yesterday what happened is that it suddenly became impossible to send
e-mail from machines like B and D to users on machine C. Machines like A
(older sendmail) work normally. Note that machine B was originally
8.14.7/8.14.4 like C (the sendmail.cf is generated on one machine
centrally and distributed to all other machines, so all machines except
the newest D had the 8.14.4 sendmail.cf)

We did *several* tests, most with mailx -v to have a log of the entire
transaction. In a few cases we did directly a telnet on port 25
simulating the SMTP session.

What happens in a NORMAL case (say A to C) is that we see

- (1) a session "connecting to 127.0.0.1 via relay" (this should be the
one driven by submit.cf) which among the rest correctly resolves the
NIS alias for the addressee

- (2) a "resolved alias - connecting to C via smtp" message
- (3) a regular session which delivers the e-mail

What happens in the problematic case (say B to C or D to C) is

- (1) a session "connecting to 127.0.0.1 via relay" as above
- (2') a "resolved alias - connecting to
your.dns.needs.immediate.attention.hermes via smtp"
- (3') the mailer daemon of B sends back a 5.3.5 local configuration
error

If on B we do a telnet C 25 and simulate session (3) directly it works.

We were rather puzzled by the your.dns.needs.immediate.attention.hermes
thing. hermes.lambrate.inaf.it is the FQDN of machine C. We sent with
mailx -v user, where user is a NIS alias, which resolves to
user@imap-her, and imap-her is a DNS CNAME which resolves to
hermes.lambrate.inaf.it.

We tested the functioning of our NIS and DNS servers, we played with the
/etc/nsswitch.conf disabling dns and defining the IP of our hermes in
/etc/hosts (after that we realized we should have used
/etc/mail/service.switch instead), but all this at no avail.

The problem seemed related with the NAME hermes of machine C !!!

Then we googled for your.dns.needs.immediate.attention.hermes
(previously we were careful to strip the host name and google just for
your.dns.needs.immediate.attention !) and found this page
http://www.mrp.net/ipv6_survey/diagnostics/hermes.html

Apparently the parfume multinational Hermes has registered a gTLD
.hermes !!!!!

And in fact even on a machine like A the resolver gives these replies

42 > host hermes
hermes.lambrate.inaf.it has address 155.253.16.12

43 > host hermes.
hermes has address 127.0.53.53
hermes mail is handled by 10 your-dns-needs-immediate-attention.hermes.

Now, I do not know why and how they could have something in 127.0, but
obviously what happens is that the machines like A with an old sendmail,
at step (2) of the sendmail transaction, do resolve "hermes" as
"hermes.lambrate.inaf.it" (our local machine), while machines like B
with a newer sendmail do resolve "hermes" as "hermes." !!!

The 8.14.4 and 8.14.9 sendmail.cf are extremely similar, so I think it
is the code of sendmail which in 8.14.4 (machine A) is unaffected by the
new gTLDs, while the code of 8.14.7 or later (machines B/C/D) interprets
hermes as a gTLD.

Our current workaround has been to rename machine hermes as hermex (and
repointing the CNAMEs).

But I wonder if there is some FEATURE at sendmail.cf build time which
can be use with 8.14.7 or later to prevent the anomalous behaviour.


--
----------------------------------------------------------------------
nos...@mi.iasf.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

[Hans Mayer]

hi

i am reading your posting with interest.
but without having an answer for you.
both addresses ( the MX for hermes. and www.hermes. ) are loopback addresses. it's 127.0.53.53
you can find this in rfc3330. 127.0.0.0/8 is reserved for loopback. and DNS does not prevent to define a loopback address for a hostname.

it seems that you are not using the FQDN anywhere in your configuration.

kind regards from austria to italy
hans

--