[feisty] sendmail unable to automatically determine domain name

[Fabien Tassin]

Binary package hint: sendmail

After upgrading from edgy to feisty, sendmail is no longer able to automatically determine domain name, and then, fails to send mails.

A locally generated email for a remote destination shows:

===
Received: from xxx.mydomain.tld (localhost [127.0.0.1])
        by ;; connection timed out; no servers could be reached
(8.13.8/8.13.8/Debian-3) with ESMTP id l2VEHi0q002193
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
        Sat, 31 Mar 2007 16:17:44 +0200
Received: (from yyy@localhost)
        by xxx.mydomain.tld (8.13.8/8.13.8/Submit) id l2VEHiA6002192;
        Sat, 31 Mar 2007 16:17:44 +0200
===

it triggers a bounce:
reason: 501 Syntactically invalid HELO argument(s))

and in the logs, sm-mta says "DSN: Service unavailable"

This ";;" comes from sendmail.cf:

root@xxx:/etc/mail # grep ';;' *
sendmail.cf:Dj;; connection timed out; no servers could be reached
sendmail.cf:Cw;; connection timed out; no servers could be reached
sendmail.cf:CG;; connection timed out; no servers could be reached

which is :
# my official domain name
# ... define this only if sendmail cannot automatically determine your domain
Dj;; connection timed out; no servers could be reached

I expected no Dj at all.

this .cf is automatically generated from sendmail.{mc,conf} using the provided Makefile.

root@xxx:/etc/mail # telnet 127.0.0.1 587
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 ;; ESMTP connection timed out; no servers could be reached Sendmail 8.13.8/8.13.8/Debian-3; Sat, 31 Mar 2007 17:16:14 +0200; (No UCE/UBE) logging access from: localhost(OK)-localhost [127.0.0.1]

This issue is new to festy. Edgy was okay. I'm no longer able to send any mail from this feisty box and I can't find a way to fix that, please advise.

[Fabien Tassin (fta)]

Seems like it comes from a bad /etc/mail/m4/dialup.m4

root@xxx:/etc/mail # grep -v ^# /etc/mail/m4/dialup.m4
LOCAL_CONFIG
dnl include(`/etc/mail/dialup.m4')dnl
Cw1.2.3.4
define(`confDOMAIN_NAME', `;; connection timed out; no servers could be reached')dnl
Cw;; connection timed out; no servers could be reached
CG;; connection timed out; no servers could be reached
root@xxx:/etc/mail #

It works if I remove (or dnl) the lines after the 1st Cw and rebuild the confs.
I don't know how those lines ended up there. They appeared during the upgrade from edgy to feisty (amd64) using upgrade-manager -d.

[Fabien Tassin (fta)]

It occured a second time last week after I did an update using the update manager. I had to manually edit dialup.m4 once again.

The bug is in sendmail-8.13.8/debian/local/dynamic.in in the find_host() function called by update_host().
I guess $(host $SM_ip) simply fails.
This is a serious flaw as it breaks mail delivery.

This box is on a fixed LAN with two resolvers properly configured (1 being on the same LAN). This is not a dialup box depending on an ISP. Those two DNS servers are perfectly fine. So either it's caused by another package (Avahi ? NetworkManager ?) or by something else being upgraded at the same time.

[charlie_pank (charlie-pank)]

I have reproduced this bug. It exists in Feisty even if you install it from scratch (ie not upgrade). I'm not sure what the root cause is, but I can tell you that if you manually edit sendmail.cf to remove line 99 ("Dj;; connection timed out; no servers could be reached") and then restart it doing /etc/init.d/sendmail restart then the problem goes away.

Each time you run sendmailconfig OR restart the machine, the problem returns - sendmail.cf line 99 is repopulated with the error message above. And if you run fetchmail to get your mail from your ISP then all your mail is lost forever. This is very very bad!

This is true EVEN WHEN the erroneous messages are removed from /etc/mail/m4/dialup.m4

[Fabien Tassin (fta)]

hmm, are you on AMD64 ?
I have 3 boxes running Feisty, 2 are running Feisty i386, 1 is Feisty amd64. I have this issue only on the later.

I also have an issue (on that amd64) with the NetworkManager applet. It always says the link (eth0) is disabled, while it's not and I've noticed during an upgrade (during the late beta phase of feisty) that sendmail was updated while the network was shut (too bad I don't remember which package shutted the network) which is probably the reason why debian/local/dynamic failed.

I also had an issue with slow (remote) syslog caused by Avahi trying to do lookups for IP addresses without reverse DNS. That's my 2nd possible culprit for this sendmail mess. I've removed Avahi since (as it's useless for me) and I monitor sendmail expecting the ";;" error to come back.

Last issue, my amd64 box has been blacklisted in some RBL just because it was emitting emails with this obviously bad HELO/EHLO header. Fixed now but that caused me a lot of troubles.

[charlie_pank (charlie-pank)]

I'm not on AMD64, although I will be in a couple of weeks.

I have looked further into this and I've found that this problem is caused by /usr/share/sendmail/dynamic this is sourced by /etc/network/if-up.d/sendmail and then the /usr/share/sendmail/dynamic update_host() function is run by the /etc/network/if-up.d/sendmail script.

I use a usb modem to connect over pppoa and, in the boot sequence, this is brought up after eth0. /etc/network/if-up.d/sendmail is run by eth0 when no dns is available, thus you get the horrible message as dialup.m4 is rebuilt as eth0 comes up.

When ppp0 comes up it doesn't overwrite it.

I've found that commenting the call to update_host in /etc/network/if-up.d works for me, although I think a proper fix would involve looking out for the text "connection timed out; no servers could be reached" in /usr/share/sendmail/dynamic find_host() function.

[Fabien Tassin (fta)]

[ for AMD64, I plan to go back to 32bit ASAP as so many things are broken in AMD64. That was my first try with a 64bit linux, not ready for my taste (I've been running Debian for 10 years, always the so called unstable, both servers and desktops, I was happy). Well, maybe this issue is not 64bit related. Nice to see I'm not the only one experiencing this :P ]

All my boxes are on an Ethernet LAN, fixed IP addresses (no DHCP), rock stable. No reason for the DNS lookup to fail, except if the box itself is killing its network parameters.

[Fabien Tassin (fta)]

I re-installed this feisty amd64 box with feisty i386. I've experienced this sendmail issue once again. It's indeed the /etc/network/if-up.d/sendmail script that produces that.

[gnustavo (gnustavo)]

The same issue affects edgy i386. I have three of them as the cpqd.com.br domain MXs. It seems that when /etc/network/if-up.d/sendmail is called it cannot resolve the reverse of the host's IP address and that strange string ends up being inserted in /etc/mail/m4/dialup.m4.

The problem occurs whenever I reboot the servers. If I only perform a "ifdown eth0; ifup eth0" it doesn't occur.

I edited /etc/mail/sendmail.conf to set DAEMON_NETMODE="Static" (the default is Dynamic) but it didn't solve the problem. (I followed the scripts and could not find where this variable is used. Perhaps it's a left over.)

The problem has a very bad side effect for mail servers facing the Internet. Yesterday I rebooted the three machines (for a memory upgrade) and they came out with this error in the sendmail configuration. It took me an hour more or less to notice the problem and to manually solve it. It was enough to have all of them blacklisted at http://cbl.abuseat.org/lookup.cgi.

[gnustavo (gnustavo)]

In order to bypass the problem I did this after having edited dialup.m4 manually:

# cd /etc/mail/m4
# mv dialup.m4 dialup-good.m4
# ln -s dialup-good.m4 dialup.m4

I don't know why, but the function update_host() in /usr/share/sendmail/dynamic, which is responsible for creating dialup.m4, refrains from touching it if it is a symbolic link.

[charlie_pank (charlie-pank)]

Be warned, your solution of moving dialup.m4 is only a temporary fix, the problem will recurr in my experience.

My ultimate solution is to use postfix instead of sendmail. As this bug is completely intolerable - it loses mail forever!!

[Fabien Tassin (fta)]

Status changed to Confirmed as we all see the same issue. 3 months untriaged for such a critical bug..

[copsewood (rich-copsewood)]

This bug also seems to be upstream and unfixed in the Debian Etch Sendmail package as bug 375787 . I have added the following report there as follows:

My /etc/mail/m4/dialup.m4 contained:

define(`confDOMAIN_NAME', `;; connection timed out; no servers could be
reached')dnl

This seems to end up within the HELO/EHLO greeting for sent messages,
breaking RFC2821 .

This resulted in my server ( 80.68.90.112 ) getting a cbl.abuseat.org
blacklisting which was picked up by zen.spamhaus.org causing my
outgoing mail to be blocked.

[Ross Vandegrift (vandegrift)]

This bug is from the upstream distribution. I hit it today on a Debian lenny system.

See DBTS #375787

[Tapani Tarvainen (ubuntu-tapani)]

This hit me yesterday as well.
Since the network connection in the machine in question is static, I simply removed the lines

include(`/etc/mail/m4/dialup.m4')dnl
include(`/etc/mail/m4/provider.m4')dnl

from sendmail.mc. As far as I can tell, none of the current config tools will put them back,
although I guess a future upgrade could do even that.

Another solution that sticks would be setting HANDS_OFF in sendmail.conf
(and that's what I'll do if some automaton starts messing with my sendmail.mc).

[Tapani Tarvainen (ubuntu-tapani)]

Forgot to mention that I already had explicit
define(`confDOMAIN_NAME',...
in my sendmail.mc, as well as
FEATURE(use_cw_file)dnl
and
GENERICS_DOMAIN_FILE(...
which pretty obviously make the dialup.m4 useless anyway.