Solaris Sendmail – Troubleshooting

 

In solaris 9 and above, sendmail uses a 2 queue paradigm structure (/var/spool/mqueue and  (var/spool/clientmqueue).

This is to make sendmail more secure by not giving out setuid for root in the binary, unlike Solaris 8 and below which has one queue (/var/spool/mqueue).

 

 



In Solaris 9 and above, there are 2 sendmail daemons for the 2 queues:

/usr/lib/sendmail -Ac -q15m” which is owned by smmsp and the other “/usr/lib/sendmail -bd -q15m” owned by root.

The former uses the /var/spool/clientmqueue and the latter uses /var/spool/mqueue.

Step 1 – verify the /etc/mail directory exist and sendmail.cf and submit.cf exist.

The main sendmail daemon which listen on port 25 uses the sendmail.cf, while the secondary one uses the submit.cf.

# ls -ail /etc/mail

total 924

1445 drwxr-xr-x   3 root     mail        1024 Mar 13 13:48 .

1403 drwxr-xr-x  76 root     sys         4608 Mar 27 11:59 ..

19564 -rw-r–r–   1 root     bin          163 Oct 29 12:40 Mail.rc

3964 -rw-r–r–   1 root     bin         1423 Oct 29 12:24 aliases

2405 -rw-r—–   1 root     smmsp      40960 Nov  6 14:45 aliases.db

22855 drwxr-xr-x   9 root     mail         512 Nov  6 14:35 cf

21951 -rw-r–r–   1 root     bin         5449 Dec 22  2006 helpfile

4055 -rw-r–r–   1 root     bin            9 Nov 30 10:43 local-host-names

2977 -r–r–r–   1 root     bin        39953 Dec 22  2006 local.cf

1865 -rw-r–r–   1 root     bin         1839 Oct 29 12:16 mailx.rc

4048 lrwxrwxrwx   1 root     root          11 Oct 29 12:24 main.cf -> sendmail.cf

42821 -rw-r–r–   1 root     root          50 Nov 30 11:09 relay-domains

42667 -r–r–r–   1 root     root       40551 Mar 14 14:58 sendmail.cf

41752 -r–r–r–   1 root     other      39900 Nov  6 14:35 sendmail.cf.old

4331 -rw-r–r–   1 root     root       40032 Nov 29 11:35 sendmail.cf_cust

21801 -r–r–r–   1 root     root       39875 Mar 13 13:48 sendmail.cf_orig

4054 -r–r–r–   1 root     bin        39895 Nov 28 10:39 sendmail.cf_save

4049 lrwxrwxrwx   1 root     root           8 Oct 29 12:24 sendmail.hf -> helpfile

21832 -rw-r–r–   1 root     bin        41448 Mar 14 15:01 submit.cf

41761 -r–r–r–   1 root     other      40241 Nov  6 14:35 submit.cf.old

21818 -rw-r–r–   1 root     root       40216 Mar 13 13:48 submit.cf_orig

4056 -r–r–r–   1 root     bin        40220 Nov  9 12:26 submit.cf_save

4050 lrwxrwxrwx   1 root     root          11 Oct 29 12:24 subsidiary.cf -> sendmail.cf

42853 -rw-r–r–   1 root     root           5 Nov 30 11:10 trusted-users

4058 -rw-r–r–   1 root     bin            0 Nov 30 10:47 trusted-users_save

 

Step 2 – Verify the sendmail.cf has the correct mailhost (this may differs from unique site, see summary) setup.

In Solaris 9 and above :

# grep DS sendmail.cf

DS

# grep Fallback sendmail.cf

O FallbackSmartHost=mailhost$?m.$m$.

 

Basically the default behaviour for sendmail is mail exchanger, it will use dns servicces to query for the MX host entry of the domainname used in the addresses for forwarding the messages. If this failed for some reasons, eg. the dns does not know the internet domains, it will fallback to use mailhost as defined in the FallbackSmartHost.m4 macros:

define(`confFALLBACK_SMARTHOST’, `mailhost$?m.$m$.’)

 

In Solaris 8 and below :

# grep DS sendmail.cf

DSmailhost$?m.$m$

sendmail by default is set to forward all messages to “mailhost” the

smarthost.

m4 macros:

define(`SMART_HOST’, `mailhost$?m.$m$.’)

 

Step 3 – Verify the submit.cf

# grep MTAHost submit.cf

D{MTAHost}[127.0.0.1]

This is to route the local messages to the localhost port 25.

# grep DS submit.cf

DS

 

Step 4 – Verify that the port 25 is configured

 

In Solaris 10 with patch 142436-03 or higher:

Enabling Access to Remote Clients   On an  unmodified  system,  access  to  sendmail  by  remote   clients  is enabled and disabled through the service management facility (smf).

In particular, remote access is determined by the value of the local_only SMF property:

svc:/network/smtp:sendmail/config/local_only = true

A setting of true, as above, disallows remote access;  false   allows remote access. The default value is true.



The following example shows the  sequence  of  SMF  commands   used to enable sendmail to allow access to remote systems:

# svccfg -s svc:/network/smtp:sendmail setprop config/local_only = false
# svcadm refresh svc:/network/smtp:sendmail
# svcadm restart svc:/network/smtp:sendmail

In Solaris 9 and above :

# grep Port sendmail.cf

O DaemonPortOptions=Name=MTA-v4, Family=inet

O DaemonPortOptions=Name=MTA-v6, Family=inet6

O DaemonPortOptions=Port=587, Name=MSA, M=E

These are the default configuration which has port 25 setup by the above and port 587 has been setup to listen as well.

 

In Solaris 8 and below :

 

# grep Port sendmail.cf

O DaemonPortOptions=Name=MTA-IPv4, Family=inet

O DaemonPortOptions=Name=MTA-IPv6, Family=inet6

O DaemonPortOptions=Port=587, Name=MSA, M=E

m4 macros :

DAEMON_OPTIONS(`NAME=MSA, Port=27, Addr=127.0.0.1, M=E’)

 

Step 5 – For receiving mail, ensure the local-host-names has populated with the localhost name eg.
# more local-host-names

v4u-x1c

 

 


Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

7 Responses

  1. Hasan Khalil says:

    Let me clarify our email architecture for our system email alerts.

    All unix/linux machines sendmail client is set to use two MTA relay sendmail servers internally in our network.

    Then those two MTA relay sendmail servers forwards all the email to our company’s microsoft exchange server (Microsoft servers are managed and administered by a seperate windows team).

    Then mircosoft exchange server delivers the system alerts to valid microsoft exchange email IDs, e.g. xyz@domain.com.

    So basically submit.cf of all the client machines has the IP address of internal network MTA relay sendmail server and MTA sendmail relay server has the IP of Microsoft exchange server for D{MTAHost} in submit.cf.

    All the system email alerts configured by us and different application/database team (in their scripts) is properly being delivered.

    Now the problem we are facing is this. Along with all the system alerts emails, all of the sendmail client machines are also sending out native OS users system generated emails (to the native user ) as well. And …… our internal network MTA relay sendmail server obviously also relay them to our domain’s microsoft exchange server, which obviously cannot recognize the destination address (e.g. user@server-hostname.domain.com) floods our outbound email gateway (sendmail server) with all those unwanted emails and overwhelms the mail queue.

    So far, we concluded to use ‘.forward’ option to at least deliver all the emails to proper email address (xyz@domain.com) of the respective owner team of the unix/linux system user. That way our corporate outbound sendmail email gateway will not be brought down due to 100,000+ unwanted system users email everyday.

    Another option we have read somewhere is to configure /etc/mail/access file on the internal MTA relay sendmail server, which would discard or reject any email addressed to user@server-hostname.domain.com. But we are not sure about the syntax to be used. Whether we can use wild card options to reject/discard all emails addressed to user@server-hostname.domain.com or we have to add lines for each and every user of all the servers.

  2. Ramdev Ramdev says:

    Hi Hasan, I understood what you are saying.  

    Configuring .forward file to redirect mails to the respective server owners sounds like an idea, but I am  concerned about the fact that you need to touch the sendmail configuration  everytime you have to add the servers in the network. That is not an ideal practice to do, and can make sendmail vulnerable for human mistakes.

    The other alternative, configuring /etc/mail/access is something I  would prefer to test as a solution. Because that will require one time configuration for the setup. you just need to Relay the specific domain name  and rest will be declined by default.

    I am just wondering what is bind and Os version you are using?

  3. Hasan Khalil says:

    Hi Ramdev, sendmail clients are mix of Solaris 10, Solaris 9, RHEL. Whereas internal MTA relay server is configured on primary internal DNS server which is Solaris 9 update 7.

  4. Hasan Khalil says:

    Or, our issue can also be resolved if cron emails are stopped. I have posted regarding to cron at http://www.unix.com/solaris/229187-solaris-cron-job-email-generation-not-required.html

  5. Ramdev Ramdev says:

    what is the Bind version?

  6. Hasan Khalil says:

    sendmail client running on Solaris 10 update 10 is “BIND 9.6-ESV-R5-P1”. sendmail MTA server on Solaris 9 update 7 has “BIND 8.3.3”.

  1. October 6, 2015

    […] Read – Basic Troubleshooting […]

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us