Centralized Mail Server
Written by Greg King Saturday, 26 January 2013 22:05
DISCLAIMER! This document is nothing more than the musings of the author as he attempts to perform the stated tasks. Conclusions and approaches
may very well be incorrect, inefficient, or otherwise outside of professionally accepted best practices. Use this document at your own risk! In this
document, screen outputs will be presented in green. Where keyboard input is required, the prompt will be in bolded red. # means you should be at the
super user prompt, $ means you should be at an unprivileged user prompt. Do not include these prompts in your input! The command to be typed will be
shown in blue.
# ls -al
means you type ls -al at the super user prompt.
This is a hard topic to write about because there are many different ways to configure the server depending upon what it is you are attempting to accomplish. The main purpose for ME is to have each box email the system administrator type mail to a single box so I don't have to log into multiple boxes to check the mail.
Even having said that, there are many ways to configure such a system as well. In any configuration, one system will have to accept incoming mail from the other systems. The default mail package on Solaris (Sendmail) is not configured to listen on ethernet ports, so we will have to change it.
For clarification, 10ADM is the system we will use as our 'mail-server'. The other boxes (11ADM, 12ADM, etc ) will be configured to simply send their internally generated emails to 10ADM which will either deliver to accounts on the system, or process outbound mail.
CHANGES NEEDED ON ALL SYSTEMS
To get the basic centralized mail system to work, we need all subordinate systems to know there is a mail server. To do this, we add an entry into the host file like this
192.168.10.15 10adm mailhost mailhost.wwwpages.com
This entry needs to be added to the host file of every system. This tells the computer about our 'mailhost'. You could simply append the mailhost mailhost.wwwpages.com to the end of the exiting line, where we defined the loghost, but I like putting it on two lines for ease of reading.
now, give an alias for root on each system. This alias will auto-forward root's mail to where we specify in our alias file.
add the following line to the end of your /etc/mail/alias file
root: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
then compile the alias database
# newaliases
In this very basic setup, these are the only changes we need on each computer.
SENDMAIL ONLY LISTENS ON LOCAL HOST?
The "out of the box" configuration for sendmail is to only listen on localhost. It can send mail to the outside world, but will not accept incoming mail. To change this behavior on our mail server, we need to make a few changes.
First, we change the sendmail service
# svccfg -s svc:/network/smtp:sendmail setprop config/local_only= boolean: false
# svcadm restart svc:/network/smtp:sendmail
Now we will backup the sendmail.mc file so we can change it.
# cd /etc/mail/cf/cf
# cp sendmail.mc sendmail.mc.b0
Now modify your sendmail.mc file to look like this. Pay attention to the last line in our example which needs to be modified for your own setup.
# /usr/ccs/bin/m4 ../m4/cf.m4 sendmail.mc > /etc/mail/sendmail.cf
# svcadm restart sendmail
check to see if sendmail is listening
# netstat -a|grep -i listen
you should see a line like this in the output:
10ADM.smtp *.* 0 0 49152 0 LISTEN
In theory, this should work. I say "In theory" because my local test platform has some differences in that I send all of my home mail to a remote server and use a web based email client. I perform this task with a SMART_HOST directive in sendmail. It may work better to use a SMART_HOST directive on all of our computers pointing to 10ADM. This way we don't have to put in an alias for every user. Since I don't have any users on my network, I can't test for it.
Lastly, we need to protect our mail server. As it stands, everyone can access it (see the *.* in the listen output above?). Rogue elements are constantly scanning the internet for vulnerable systems. Unprotected email servers are a delicious target because they can be used to relay spam. To protect our server, we are going to use TCP_WRAPPERS. All of our other boxes only listen on the localhost, so the following steps only need to be done on 10ADM. The nice thing is, we don't have to reconfigure sendmail or it's service for TCP_WRAPPERS because it is automatically configured that way. All we need to do is define the wrappers via a host.allow file.
It is ok if your /etc/hosts.allow and /etc/hosts.deny file don't exist. Create them.
edit /etc/hosts.allow and add the following line
all: 192.168.
then edit /etc/hosts.deny and add the following line
all:all
This denies all traffic from wrapped ports (hosts.deny), but allows it from the local network (hosts.allow). You can get more granularity in the hosts.allow by specifying services individually, but allowing all traffic from your internal network is probably the correct configuration.
Even having said that, there are many ways to configure such a system as well. In any configuration, one system will have to accept incoming mail from the other systems. The default mail package on Solaris (Sendmail) is not configured to listen on ethernet ports, so we will have to change it.
For clarification, 10ADM is the system we will use as our 'mail-server'. The other boxes (11ADM, 12ADM, etc ) will be configured to simply send their internally generated emails to 10ADM which will either deliver to accounts on the system, or process outbound mail.
CHANGES NEEDED ON ALL SYSTEMS
To get the basic centralized mail system to work, we need all subordinate systems to know there is a mail server. To do this, we add an entry into the host file like this
192.168.10.15 10adm mailhost mailhost.wwwpages.com
This entry needs to be added to the host file of every system. This tells the computer about our 'mailhost'. You could simply append the mailhost mailhost.wwwpages.com to the end of the exiting line, where we defined the loghost, but I like putting it on two lines for ease of reading.
now, give an alias for root on each system. This alias will auto-forward root's mail to where we specify in our alias file.
add the following line to the end of your /etc/mail/alias file
root: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
then compile the alias database
# newaliases
In this very basic setup, these are the only changes we need on each computer.
SENDMAIL ONLY LISTENS ON LOCAL HOST?
The "out of the box" configuration for sendmail is to only listen on localhost. It can send mail to the outside world, but will not accept incoming mail. To change this behavior on our mail server, we need to make a few changes.
First, we change the sendmail service
# svccfg -s svc:/network/smtp:sendmail setprop config/local_only= boolean: false
# svcadm restart svc:/network/smtp:sendmail
Now we will backup the sendmail.mc file so we can change it.
# cd /etc/mail/cf/cf
# cp sendmail.mc sendmail.mc.b0
Now modify your sendmail.mc file to look like this. Pay attention to the last line in our example which needs to be modified for your own setup.
divert(-1)Now compile the mc file and restart sendmail
#
# Copyright (c) 1983 Eric P. Allman
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# Copyright 2009 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)sendmail.mc 1.12 10/03/24 SMI"
#
# This is a configuration file for SunOS 5.8 (a.k.a. Solaris 8) and later
# subsidiary machines. It has support for local and SMTP mail. The
# confFALLBACK_SMARTHOST macro is enabled, which means that messages will
# be sent to that host (which is set to mailhost.$m [$m is the local domain])
# if MX records are unavailable. A short-cut rule is also defined, which
# says if the recipient host is in the local domain, send to it directly
# instead of the smart host.
#
# If you want to customize this further, copy it to a name appropriate
# for your environment and do the modifications there.
#
divert(0)dnl
VERSIONID(`sendmail.mc (Sun)')
OSTYPE(`solaris8')dnl
DOMAIN(`solaris-generic')dnl
MAILER(`smtp')dnl
DAEMON_OPTIONS(`Name=wwwpages.com, Addr=mailhost.wwwpages.com')dnl
# /usr/ccs/bin/m4 ../m4/cf.m4 sendmail.mc > /etc/mail/sendmail.cf
# svcadm restart sendmail
check to see if sendmail is listening
# netstat -a|grep -i listen
you should see a line like this in the output:
10ADM.smtp *.* 0 0 49152 0 LISTEN
In theory, this should work. I say "In theory" because my local test platform has some differences in that I send all of my home mail to a remote server and use a web based email client. I perform this task with a SMART_HOST directive in sendmail. It may work better to use a SMART_HOST directive on all of our computers pointing to 10ADM. This way we don't have to put in an alias for every user. Since I don't have any users on my network, I can't test for it.
Lastly, we need to protect our mail server. As it stands, everyone can access it (see the *.* in the listen output above?). Rogue elements are constantly scanning the internet for vulnerable systems. Unprotected email servers are a delicious target because they can be used to relay spam. To protect our server, we are going to use TCP_WRAPPERS. All of our other boxes only listen on the localhost, so the following steps only need to be done on 10ADM. The nice thing is, we don't have to reconfigure sendmail or it's service for TCP_WRAPPERS because it is automatically configured that way. All we need to do is define the wrappers via a host.allow file.
It is ok if your /etc/hosts.allow and /etc/hosts.deny file don't exist. Create them.
edit /etc/hosts.allow and add the following line
all: 192.168.
then edit /etc/hosts.deny and add the following line
all:all
This denies all traffic from wrapped ports (hosts.deny), but allows it from the local network (hosts.allow). You can get more granularity in the hosts.allow by specifying services individually, but allowing all traffic from your internal network is probably the correct configuration.