I have recently started using sendmail on a server running ZoneMinder to send notifications when my cameras detect motion. My setup is very simple as I don't need my server to receive or store emails, just be able to send them, and I haven't changed any config files related to sendmail.

Everything seems to work fine, with one exception: when I first boot up and try to send an email (either running sendmail on the command line or by causing ZoneMinder to generate an alert), I never receive it. If I restart /etc/rc.d/rc.sendmail, the emails come through and future ones are received promptly. /etc/rc.d/rc.sendmail has execute permissions. Am I missing something obvious here?

Are you sure that /etc/rc.d/rc.sendmail is being used at initial boot?

I was under the impression that if it has execute permissions, it should start when I boot. Also, I enabled it during setup when I installed Slackware.

Upon rebooting, the output of ps aux | grep sendmail:

But when I send an email, it is not received. After restarting /etc/rc.d/rc.sendmail, the emails I sent previously are received right away and the output of `ps aux | grep sendmail` is the same as it was before. So yeah, it beats me what's going on.

EDIT: Actually, I will have to check this again. The emails that I send to my phone via the text gateway are definitely not received until after restarting the sendmail service. I'm not sure if that is true for emails sent to my regular email address.

I just checked again, and it's definitely all emails that are not coming through, not just SMS gateway emails. I rebooted my computer, started ZoneMinder, and sent a test email. About ten minutes later, I restarted sendmail, and all the notifications and the test email came through at once. Has anyone else experienced this?

Is your server behind a fixed IP address? If not it's possible your ISP's relay mail servers are imposing a delay. A genuine mail server will resend, but a spammer is unlikely to bother resending. I'm not familiar with Sendmail, but the Postfix delay is configurable. If you wait a while, after the server boots up, without restarting Sendmail, you might find the mail is sent after all, without your intervention. Try to find out what the default delay is for Sendmail.

Another possibility is a delay in your DNS coming up at boot.

Either way, I think this is a network or ISP issue. Not a Slackware or Sendmail problem.

It's not a fixed IP address.

Does that make sense for my symptoms, though? After restarting sendmail, I receive emails (including the previously sent ones and any additional ones I send after the restart) instantly, with no noticeable delay. If there is a delay, it is definitely much less than the amount of time I have waited before restarting sendmail.

I haven't changed anything in the default config file, and I didn't really see anything that looked pertinent in there, but I'm also a newbie to sendmail and networking in general. It's quite possible it is something to do with my configuration or my network, especially if no one else has had this problem. When all is said and done, if the solution for me is to just restart sendmail after booting, that's not a big deal, especially since I don't intend to reboot this server very often.

Just a wild guess. Is this system booting from an SSD? There are known related entropy problems with sendmail not starting correctly. I installed haveged on one system to avoid the boot delays. Could be network or DNS, but the symptoms are tad similar.

Nope, I am still stuck in the last decade with an HDD and traditional BIOS.

I had that some years ago when running sendmail on a computer which set up its IP interfaces using NetworkManager or wicd (whatever I was using at the time, I can't remember), possibly using wi-fi (I can't remember that either). As I recall, the problem was that the network interface needs to be up when sendmail is started, which it wasn't at boot-up time using the standard slackware boot scripts with this particular computer.

One solution is to not to start sendmail using the slackware init, but instead to start it only when the interfaces are up. However, I solved the problem more satisfactorily by switching to postfix, which as it happens will be the default MTA in the next version of slackware. You can get a build script for postfix using slackbuilds or by borrowing the one from slackware-current. This enables me to run postfix on my laptop, as postfix doesn't care if the wi-fi interface is available when the laptop is started or not - if it isn't up, postfix will send the emails once it detects that the IP connection is working.

1 members found this post helpful.

By the way, if you are just using sendmail as a relay - say you are relaying to your internet provider's SMTP server or to the gmail SMTP server - you can do all this more easily by using mailx, which comes with slackware. I use mailx to notify changes of IPv4 address to remote computers which might want to ssh into the main computer (a kind of poor man's DynDNS). You do not need to bother with sendmail and postfix if that is all you want to do. mailx will also automatically handle the TLS stuff for you if you are using gmail's servers.

1 members found this post helpful.

I think that must be the problem. I am using NetworkManager on wi-fi, and I just tried not starting Sendmail at all until after I was connected to the network, and then emails came through right away. Again, I'm a newb to this whole thing, and I know very little about how it works under the hood, but I find it strange that Sendmail needs to be connected to the network on startup even if no emails need to be sent until after the network is up.

Thanks for the suggestion. I will give postfix a try. Marking this as solved.

I agree with you, but that was the problem for me. At one time there was a configuration macro you could put in your submit.mc file when generating submit.cf which worked (I can't now remember what it was) but that was dropped from sendmail at some point, which is what drove me to postfix.

postfix is a welcome improvement generally in my view, although the slackware-current supplied version for some reason did not seem to configure itself as well as my own home-prepared versions (perhaps it was confused by my pre-existing installation). You might get errors on first start-up if not all the fields in main.cf are filled out correctly: make sure that in main.cf setgid_group is set to postdrop, and if you have vacant entries in main.cf for something like 'html_directory =', comment it out rather than leaving it blank. Once you have those correctly set you may need to run 'postfix set-permissions' as root (you will if your main.cf was in error, because then the slackware installation script will have been unable to do it for you).

1 members found this post helpful.

Thanks for the tips. Using the SlackBuild from -current, it looks like everything is set up correctly already in main.cf. Here are some notes on the things I needed to do to get it working:

• Before installing Postfix, make sure Sendmail is stopped, the sendmail package is removed, and /etc/rc.d/rc.sendmail is removed.
• Follow the instructions given when you run the SlackBuild to set up the appropriate users and groups for Postfix.
• After installing, I had to add the following directory:
  
  /var/spool/clientmqueue
  
  And chown it to smmsp:smmsp

Maybe the last thing would have been taken care of automatically if I had remembered to run postfix set-permissions, but I'm not sure, because I forgot to do that until after.

Anyway, it's all working now. I added a line to start /etc/rc.d/rc.postfix to my /etc/rc.d/rc.local, and now no other intervention is needed to send emails after booting.