X

Sendmail SMF services in Solaris

Sendmail SMF services in Solaris

With the latest versions of Solaris (10u6 and 11.x) the classic sendmail program has been split in two separate daemons

root@host1 # svcs -a |grep sendmail
online         20:31:17 svc:/network/smtp:sendmail
online         20:33:53 svc:/network/sendmail-client:default
root@host1 # svcs -p smtp:sendmail sendmail-client:default
STATE          STIME    FMRI
online         20:31:17 svc:/network/smtp:sendmail
               20:31:18    24564 sendmail
online         20:33:53 svc:/network/sendmail-client:default
               20:33:53    24574 sendmail
root@host1 # ps -aef|grep sendmail
    root 24595 24233   0 21:01:37 pts/1       0:00 grep sendmail
    root 24564     1   0 20:31:18 ?           0:00 /usr/lib/inet/sendmail -bd -q15m
   smmsp 24574     1   0 20:33:54 ?           0:00 /usr/lib/inet/sendmail -Ac -q15m

The first one is the real Message Transfer Agent (MTA), whereas the second one handles the client queues used by the local Message Submission Programs (MSP).

In an ideal world, with all the internet hosts up and running, and with all the connections between them working properly, the difference by these two instances won't be so immediate, but what happens in the real world?

In the real world, it could simply happen that the MTA program could be down for some reason (scheduled maintenance or unexpected issues):

root@host1 # svcadm disable smtp:sendmail sendmail-client
root@host1 # svcs -a |grep -i sendmail
disabled       21:27:33 svc:/network/smtp:sendmail
disabled       21:27:33 svc:/network/sendmail-client:default

but a generic MSPs (like mail or mailx) could still be allowed to submit the email:

root@host1 # mailq -Ac
/var/spool/clientmqueue is empty
                Total requests: 0
root@host1 # echo "Test message with mailx." | mailx -s "Test with both DOWN" user1@host1
user1@host1... Connecting to [127.0.0.1] via relay...
user1@host1... Deferred: Connection refused by [127.0.0.1]

root@host1 # echo "Test message with mailx." | mailx -s "Test with both DOWN" user2@host2
user2@host2... Connecting to [127.0.0.1] via relay...
user2@host2... Deferred: Connection refused by [127.0.0.1]

But in this case, since the MTA cannot deliver the message, the email is kept in the MTA-client queues:

root@host1 # mailq -Ac
                /var/spool/clientmqueue (2 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
u3CJUgsu024771       25 Tue Apr 12 21:30 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user1@host1
u3CJTMqr024760       25 Tue Apr 12 21:29 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user2@host2
                Total requests: 2

At this point, even if we enable the MTA and check again the queues, we will still see the same messages queued:

root@host1 # svcadm enable smtp:sendmail
root@host1 # svcs -a | grep sendmail
disabled       21:27:33 svc:/network/sendmail-client:default
online         21:32:54 svc:/network/smtp:sendmail
root@host1 # mailq -A
c
               /var/spool/clientmqueue (2 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
u3CJUgsu024771       25 Tue Apr 12 21:30 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user1@host1
u3CJTMqr024760       25 Tue Apr 12 21:29 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user2@host2
                Total requests: 2

The difference is that if now we try to send email messages, these will be immediately delivered, both locally, and remotely:

root@host1 # echo "Test message with mailx." | mailx -s "Test smtp:sendmail UP and sendmail-client DOWN" user1@host1
root@host1 # echo "Test message with mailx." | mailx -s "Test smtp:sendmail UP and sendmail-client DOWN" user2@host2

user1@host1 will see:

user1@host1 $ mail
From root@host1 Tue Apr 12 22:20:33 2016
Date: Tue, 12 Apr 2016 22:20:32 +0200 (CEST)
From: Super-User <root@host1>
Message-Id: <201604122020.u3CKKWP5024867@host1>
To: user1@host1
Subject: Test smtp:sendmail UP and sendmail-client DOWN
Content-Length: 25

Test message with mailx.

? d
user1@host1 $

and same thing will happen for user2@host2:

user2@host2 $ mail
From root@host1 Tue Apr 12 22:20:39 2016
Date: Tue, 12 Apr 2016 22:20:38 +0200 (CEST)
From: Super-User <root@host1>
Message-Id: <201604122020.u3CKKcmI024873@host1>
To: user2@host2
Subject: Test smtp:sendmail UP and sendmail-client DOWN
Content-Length: 25

Test message with mailx.

? d
user2@host2 $

but the messages submitted previously will still be in the client mail queues:

root@host1 # mailq -Ac
               /var/spool/clientmqueue (2 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
u3CJUgsu024771       25 Tue Apr 12 21:30 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user1@host1
u3CJTMqr024760       25 Tue Apr 12 21:29 root
                 (Deferred: Connection refused by [127.0.0.1])
                                         user2@host2
                Total requests: 2

Only if we enable the service which is taking care of the client queues, these emails will be delivered:

root@host1 # svcadm enable sendmail-client
root@host1 # svcadm refresh sendmail-client
root@host1 # mailq -Ac
/var/spool/clientmqueue is empty
                Total requests: 0
root@host1 #

And we can get a confirmation from the two users;

user1@host1 $ mail
From root@host1 Tue Apr 12 21:31:48 2016
Date: Tue, 12 Apr 2016 21:29:22 +0200 (CEST)
From: Super-User <root@host1>
Message-Id: <201604121930.
u3CJUgsu024771@host1>
To: user1@host1
Subject: Test with both DOWN
Content-Length: 25

Test message with mailx.

?

and:

user2@host2 $ mail
From root@host1 Tue Apr 12 21:31:48 2016
Date: Tue, 12 Apr 2016 21:29:22 +0200 (CEST)
From: Super-User <root@host1>
Message-Id: <201604121929.u3CJTMqr024760@host1>
To: user2@host2
Subject: Test with both DOWN
Content-Length: 25

Test message with mailx.

?

... Piece of cake ;-)

Join the discussion

Comments ( 2 )
  • sscdvp Wednesday, May 25, 2016

    This can lead to out-of-space problem on "misconfigured" Solaris hosts/zones: if smtp:sendmail isn't functioning then after some time such system will be overwhelmed with system mail stored on /var/spool/clientmqueue, also sendmail process starts to eat available CPU resources since dozens of thousand messages are queued.

    Unfortunately sendmail doesn't provide anything to stop that...

    Real-world example of "misconfigured" Solaris host (from the point of view of sendmail software): if DNS name localhost.localdomain (of any configured hostname via SMF identity:node service) couldn't be resolved. sendmail.cf is by default configured to use "localhost".


  • Marco Thursday, May 26, 2016

    Hi,

    of course I didn't mean to keep the smtp:sendmail service down forever, why would I want to do that to my machine? ;-)

    I was just trying to show what happens when the various components of the sendmail service are unavailable.


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.