| Our mail system will be based on a common design: one machine that acts as both a central mail server and the mail relay to the outside world. We'll use xenon for this task. All the remaining machines will act as mail clients and NFS-mount their mail directory (/var/mail) from the server. Figure 20.3 shows this configuration. Figure 20.3. The mail system design. 
Update DNS The first thing we'll do is update our DNS entries so that xenon is recognized as the mail server for our domain. This will allow external machines to perform a DNS lookup and search for our MX records. We won't add any redundant servers or allocate any priorities either, all of which means the setup will be easier to implement. We described DNS in Chapter 16, "Configuring DNS," so we'll quickly run through the commands here. All the changes will be made on the master machine, which is antimony. The only thing we need to do is to add an MX record into the forward file and update the serial number so that the changes are picked up, as shown here: antimony# cd /var/named antimony# cat master/solarisbootcamp.com ; ; named forward file for 192.168.44 ; @ IN SOA solarisbootcamp.com. root.solarisbootcamp.com. ( 2001123001 ; Serial num - <yyyymmddxx> 86400 ; Refresh every 24 hours 7200 ; Retry every 2 hours 3600000 ; Expire in 1000 hours 172800) ; TTL is 2 days <lines removed for clarity> ; ; mail server ; solarisbootcamp.com. IN MX 0 xenon.solarisbootcamp.com. <lines removed for clarity> antimony# Now that we've made the changes, we can inform named about them. After that, the data will be available to all DNS servers that query our domain: antimony# kill -HUP `cat /var/named/named.pid` antimony# Some servers may have already cached our details in the past, so we should allow at least two to three days before we can consider this information "available everywhere." The Mail Host Now let's configure the main mail host, xenon. A requirement with sendmail is that it knows the fully qualified name of the system it is running on. We can use one of the utility scripts located in /usr/lib/mail/sh to check this is correct, as shown below: xenon# /usr/lib/mail/sh/check-hostname Hostname xenon OK: fully qualified as xenon.solarisbootcamp.com Xenon# Next, we'll add a "mailhost" alias to the hosts file. We'll see later that the client uses this to forward mail on to the server. To do this, we'll simply update the hosts map on the NIS server as follows: tin# cat /etc/inet/hosts <lines removed for clarity> 192.168.44.54 xenon xe mailhost tin# cd /var/yp tin# make updated hosts pushed hosts tin# Generate Sendmail.cf Now we're ready to install the correct sendmail.cf file. We know that xenon is the main mail host, which means we need to use something similar to the main.cf template. We're not using any special features on this machine either, so all that remains is to copy the correct file into place and restart the sendmail daemons. Let's do that now: xenon# cd /etc/mail xenon# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.orig xenon# cp main.cf sendmail.cf xenon# /etc/init.d/sendmail stop xenon# /etc/init.d/sendmail start xenon# Good. Everything is in place, so let's move on and check that it all works OK. Send and Receive Test Mail To check that mail is working, we'll send a few test messages to one of the users. After that we'll login as that user and check that the user has received everything correctly. xenon# mail jgreen First test mail . xenon# mail jgreen Second test mail . xenon# This should have been sent via the MTA and delivered to the user's mailbox by mail.local. As before, we'll use the mail command to check that the user can read it correctly: xenon# su - jgreen xenon$ mail From root Wed Dec 26 19:59:57 2001 Date: Wed, 26 Dec 2001 19:59:56 GMT From: Super-User <root> Message-Id: <200112261958.TAA00565@xenon.solarisbootcamp.com> Content-Length: 18 Second test mail ? d From root Wed Dec 26 19:58:57 2001 Date: Wed, 26 Dec 2001 19:58:56 GMT From: Super-User <root> Message-Id: <200112261958.TAA00564@xenon.solarisbootcamp.com> Content-Length: 17 First test mail ? d xenon# Good. We've managed to read both messages. Share the Mail Directory The mail directory, /var/mail, needs to be shared from the mail server to allow it to be mounted by clients. This means that we will be more dependent upon xenon being up and running, otherwise we cannot read our existing mail, but it will be easier for us to administer. We explained how to share files in Chapter 18, "NFS, DFS, and Autofs," since we're using the standard mount options, we'll simply run through the commands here. First let's share the files: xenon# cat /etc/dfs/dfstab share -F nfs /var/mail xenon# shareall -F nfs The filesystem is now shared from xenon, so let's move on and configure the clients. Configure the Clients We'll use carbon as an example client for now. The first thing we'll do is to NFS-mount the mailbox directory from xenon. We can do this by updating either /etc/vfstab, so that the mount takes place at boot-time, or by updating the Autofs files to allow it to be mounted on demand. We'll do the latter because we're using Autofs to control the mounts on our system. We've already described this in Chapter 18, "NFS, DFS, and Autofs," so we'll quickly run through the commands here. Our entry will be placed in the direct file on the NIS master (the automounter maps are under the control of NIS). The following examples show the NFS mount options. These are that the device is "hard" mounted, with the minimum and maximum time-outs ("actimeo" variable) set to 0 (we need to do this to make sure the mailbox locking and access mechanisms work correctly): tin# cat /etc/auto_direct <lines removed for clarity> /var/mail -rw,hard,actimeo=0 xenon:/var/mail tin# cd /var/yp tin# make updated auto_direct pushed auto_direct If we didn't want to use Autofs, the corresponding entry for /etc/vfstab would be as follows: lithium# cat /etc/vfstab # #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # <lines removed for clarity> xenon - /var/mail /var/mail nfs - yes rw,hard,actimeo=0 Generate Sendmail.cf This step is very similar to the one performed for the master. We've already seen that the subsidiary file contains the definitions needed for a mail client and we've already updated our hosts file to include the mailhost entry so that the SMART_HOST setting will work. This means that we can simply copy the subsidiary template file into place and restart the daemons, which we'll do now: carbon# cd /etc/mail carbon# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.orig carbon# cp subsidiary.cf sendmail.cf carbon# /etc/init.d/sendmail stop carbon# /etc/init.d/sendmail start carbon# Send and Receive Mail Again, we need to check that we can send and receive mail to the users correctly. This means running the same sort of tests that we did for the main server. For that reason, we won't repeat them again here. At this point, we have a simple mail system up and running. However, external mail still needs to be addressed to the login names of the users for them to receive it (i.e., jgreen, and msmith). It would be nice to tidy this up, so let's look at how we can do this with aliases. | 
