Emails not sending if daemon not running

[Kenneth Penland]

We reciently upgraded to sendmail version 8.12.9 and have a problem with what we think is a new "feature". In the past, if the daemon was not running, and an email was generated from the system, it would fire up sendmail and send the message off anyway. Now, if the daemon is not running, it throws the message in the clientmqueue directory with an unable to connect to 127.0.0.1 and they never send, even if the daemon gets started again. The only way to send these messages off is by doing a:
sendmail -q -Ac

any suggestions as to how to fix it so it will send these emails even if the daemon is down?

[Bill Hassell]

sendmail cannot start by itself. I suspect that running elm or mailx or if you uase a pop server, that sendmail was being scheduled from some custom-written code. sendmail should always be running to send and receive email. Sendmail is scehduled to run at bootup in /etc/rc.config.d/mailservs and should always be running to handle email.

[Kenneth Penland]

Several of our systems we had stopped the daemon from running so that the system would no longer recieve email. However, when an email was generated on the machine, and either piped to mailx or sendmail was envoked through a perl script, the email would still leave the box. Since upgrading, we have had to turn the daemon back on because the emails no longer leave the machine, they just sit in the clientmqueue directory unable to connect to localhost.

[Steven E. Protter]

I would back out sendmail 8.12.9

Last I checked the highest version HP supports with depot distribution is 8.11.1 There is probably a pretty good reason for this.

What happens when you run /sbin/init.d/sendmail start

Does the daemon keep running? If not there is something in this release.

SEP

[roadrunner_1]

I would agree with Steven. I had the same problem with the new version. When I backed out the latest sendmail patch, my Java application could send out emails.

RR

[Kenneth Penland]

uggg....not my favorite answer, but one deep down I was expecting...thanks for your assistance!

[Mark Landin]

Bill,

I rarely ever question what you've written, but I'm pretty sure that you don't need to have sendmail running in the background in order to SEND an email message. Now, the original request is implying that this condition may have changed, but your message implies it's always been required to have sendmail running as a daemon even if only to send an email. Could you clarify your understanding of this?

[Christopher Caldwell]

Most mail programs (e.g. mailx, mail, etc.) invoke sendmail as a client, which works fine if sendmail delivers the mail on the first try. If sendmail can't deliver the mail on the first try, the mail will be queued (you can use mailq to see _why_ the mail queued -- with later versions of sendmail, the queue reasons are generally DNS related, since many security and anti-spam techniques are predicated on DNS).

sendmail -bd -q30m says listen on port 25 for inbound mail requests and run the mail queue every 30 minutes.

sendmail -q30m says DON'T listen on port 25 for inbound mail requests, but still run the queue every 30 minutes -- a good configuration if you like to send but not receive.

[Mark Greene_1]

Check the permissions on your sendmail binary, it ought to look like this:

-r-sr-sr-t 1 root mail 864256 Apr 16 10:21 /usr/sbin/sendmail

hth
mark

[Bill Hassell]

I believe that Mark is correct. sendmail can be run as a client as well as a daemon. The issue is with the actual mail creation program or server in the case of pop or imap tools. There may have been a new default config 'feature 'added to sendmail 8.12.9 to disallow scheduling by a program.

[Kenneth Penland]

In response to Christophers comment, with 8.12.9 I cant take off the -bd option either, it seems that if the system is set to not accept incoming email, either by the daemon not running, or the daemon set to not recieve email, I get errors in the mailq -Ac saying:
h4DCLlFb029149 1282 Tue May 13 08:21 root
(Deferred: Connection refused by [127.0.0.1])

[Mark Landin]

OK so now the question becomes "is this how Sendmail is supposed to work now, and if so, can I get the old behavior back"? Sendmail is still such a large security exposure that I'd don't want to have to run it to recieve email just because I need to occasionally send some. Modifying my scripts to always remember to start sendmail and then kill it later isn't an attractive option.

[Christopher Caldwell]

... with 8.12.9 I cant take off the -bd option either, it seems that if the system is set to not accept incoming email, either by the daemon not running, or the daemon set to not recieve email, I get errors in the mailq -Ac saying:
h4DCLlFb029149 1282 Tue May 13 08:21 root
(Deferred: Connection refused by [127.0.0.1])

This seems like a misconfiguration - when you tell sendmail to queue only, everything should be normal except sendmail isn't recieving tcp connections.

If mail appears to be local [e.g. user], sendmail should use the local delivery agent and never hit tcp.

If you qualify the address [e.g. user@domain], the queue only technique will work iff the address or MX for domain is on another host [since this host isn't recieving mail].

In your case, sendmail is hitting the SMTP mail, since it thinks mail is going to user@localhost as opposed to user. You've told sendmail not to accept tcp connections, so mail isn't deliver to user@localhost [i.e. user@127.0.0.1].

Have you configured your sendmail to qualify unqualified senders?

Are you running DNS?

Who does your sendmail think it is? (Post the results of
/usr/sbin/sendmail -v -d0.4 root < /dev/null)