Setting Up DNS and Mail Host

By Gerry Patterson

Domain Name Server

Setting up DNS is relatively straight forward. There are three basic steps.

Buy a copy of DNS and BIND by Paul Albitz and Cricket Liu.
Read it from cover to cover.
Install DNS.

If you hurried to this page looking for an easy way to setup DNS, you are probably disappointed to see that I recommend RTFM. Still, if you want to take short cuts, there is a very good cookbook approach to installing DNS in Greg Lehey's The Complete FreeBSD. However I believe it is necessary to do the background reading, because although it is easy to setup, it can go horribly wrong if it is done incorrectly. And the theory is easy to understand. The only problems I had were network related and these turned out to be hardware problems.

sendmail

There was a little girl who had a little curl
Right in the middle of her forehead
And when she was good she was very very good
And when she was bad she was horrid!

And her name must have been sendmail!

I wanted to have my mail going straight to the domain. I thought that this would just be a matter of tweaking sendmail. FreeBSD comes out of the box, sendmail ready. So I looked at the config files -- added an MX record to DNS. And I was able to send and receive messages. "This is just too easy!", I thought. Now I looked at persuading sendmail to allow me to present my mail as coming directly from the parent domain. Let me illustrate with an example. Let's suppose the server is called mail.mydomain.com. So if a user has an account on the host mail.mydomain.com, I wanted sendmail to send and receive mail to user@mydomain.com rather than user@mail.mydomain.com. This is really just for appearance sake. It looks neater as an e-mail address. And I did want my e-mail address to look professional. After it is done, I intended to put an IMAP or POP server on the mail server. So what I wanted was to allow a user to retrieve his/her mail with his/her favourite mail program. Nothing could be easier ... right? It turned out to be quite difficult! (sendmail is like that).

I don't pretend to be a sendmail guru, but having installed and maintained sendmail on HP, Sun, Intel-Linux and Intel-BSD, I can claim to be a seasoned veteran. Despite the temptation to get things working quickly, I have found that it is best to leave sendmail.cf alone. It is often possible to fix a problem with a one line sledge-hammer kludge. For example the well known $j macro controls the official FQDN. So the old sledgehammer:

	Dj$w.mydomain.com

Will probably fix your problems. In my case a slightly more subtle sledgehammer:

	Dj$m

Would get rid of the hostname from outgoing mail. However I must say that it is best not to start with configuration file kludges. Later, as the site matures, you may find yourself making once-off changes to the configuration file, but it is best to make a clean start with the m4 macros. This is because in the long run hacking the configuration file may not save time. You might spend hours tweaking sendmail macros in sendmail.cf only to discover that you have to rebuild it with the m4 macros anyway. In which case the m4 floodgates will open and wash away your carefully crafted sendmail hacks. If you must hack sendmail.cf, make sure you document what you have done, because you will have to re-enter everything, if (when) you rebuild due to a network re-configuration, version upgrade to sendmail, or just losing your way in the torturous internals of sendmail macros. As far as BSD 4.4 goes, there is a Makefile in /etc/mail and this has everything one might need. And that was where I started.

Here is an outline of the steps which were taken to get sendmail sending and receiving from the parent domain:

First create a file called /etc/mail/virtusertable using virtusertable.sample as a template.
The key to this is the line:
```
	@mydomain.com	%1
```
Which should be added as the last line in the virtusertable. %1 is the user portion of the address. So this line will direct all mail to the corresponding name on the mail server. (NB each user must have an account on the mail server for this approach to work)
Next add mydomain.com to the file /etc/mail/local-host-names. Add just the domain. This will allow the mail server to intercept mail directed to user@mydomain.com. You can also add any other hostnames whose mail you wish to intercept (e.g. slug.mydomain.com beast.mydomain.com etc). Read the README file in the cf directory of the sendmail distribution.
There should be a config file in /etc/mail it will be called mail.mydomain.com.mc. If it doesn't exist you can create it using freebsd.mc as a template. Add the following line to this file:
```
	FEATURE(`genericstable', `hash -o /etc/mail/genericstable')
```
This will allow the reverse mapping to occur (i.e. mail from user@mail.mydomain.com shows the return address of user@mydomain.com).
Lastly, the client machines need to be configured to send mail to the mailhost.

So far so good. Now the fun began. When I tried mailing user@mydomain.com, I got a message something like this:

	MX list for mydomain.com points back to mail.mydomain.com

This message appeared on the system console, and was bounced back to the sender and the postmaster on the mailhost. It also appeared in the system logs. So I could hardly miss it. And it kept me up into the wee small hours! I spent some time playing around with DNS. Well, the message did mention MX records. So it seemed a good place to start. I soon discovered that by manipulating DNS records, I could make worse problems, but not make my problems go away. Closer inspection revealed that it was a sendmail problem, not a DNS problem. I must admit I would have discovered this earlier if I had read the error messages in the log files more carefully.

After spending some time poking around with the debug switches in sendmail, and reading the FreeBSD handbook, which is an excellent HTML document installed from the distribution disk, I found a description of the problem. It seems this error was caused by not including the domain in the local-host-names file. But hadn't I already done that? I reviewed the local-host-names file. When I entered the data, I had put a full stop after the domain name. I've been burned so many times in the past entering FQDNs in DNS records that I did it without thinking. I removed the full-stop -- and it started working.

!@#%^%*()

I just gotta laugh ... otherwise I'd cry!

NB: Before attempting to play around with sendmail, I recommend you buy "sendmail" by Bryan Costales and Eric Allman. I really would have gone crazy without a decent manual to help me navigate around the problem.

IMAP or POP server?

The next project was to decide on an IMAP or POP server. The first IMAP server I decided to evaluate was Cyrus for BSD. This was because it was on the BSD 4.4 distribution disk and also because it seems to be a good product. The information on the Cyrus home page boasted impressive security. This included SSL and KEREBROS. Although I am willing to concede that probably the only way to to make an IMAP server truly secure is to lock it in a room with steel doors, and make sure it is not connected to the internet. Which is not a practical solution if you want the convenience of being able to access your e-mail from anywhere in the world. For BSD, there is a complete list of instructions in the /usr/local/share/doc directory, which were mostly accurate. However, there is an important caveat. These instructions were written for the standard install. The BSD distribution package has been modified slightly. This is not really clear from the documentation. So you don't need to copy the file normal.conf (which doesn't exist in the BSD package) to /etc/cyrus.conf. Nor do you need to create /etc/imapd/cyrus.conf. The configuration files can all be found in /usr/local/etc. The installation failed about half-way through, because I had fallen into another trap when I installed BSD. This was taking the default installation disklabels, which created a small root file system, a swap space about twice this size, and a very small /var file system. The rest (almost 19GB) was devoted entirely to /usr. So be warned if you wish to follow a similar path. Don't take the default disklabels. The disklabels can be altered during the initial system setup. You simply choose "custom" rather than "recommended" in the second phase of the install. Of course, if I'd read the instructions at the beginning of the install I would have seen the caveat that a mail server requires a much larger /var (it was just a another example of RTFM!). Now I was paying the price for the hasty initial installation. The lack of space in /var had caused the IMAP installation to fail. There are numerous kludges I could have used to get around this. I'm sure that most sysadmins could name half a dozen. So, I won't go into them here. In my case, I decided to re-build the entire system. If you're curious, here is what I did:

	shutdown +0
	find / | egrep -v '^/dev|^/nfs' | cpio -o | gzip -c - > /nfs/temp.arch

(My NFS is mounted at /nfs)
Next, I destroyed the contents of the hard disk and recreated my filesystems using a more sensible value for /var. Then I overwrote this with the saved archive:

	ifconfig rl0 1.2.3.4/24 up
	shutdown +0
	mkdir /nfs
	mount_nfs 1.2.3.5:/path /nfs
	gzip -d < /nfs/temp.arch | cpio -iuvmd

Where 1.2.3.4 is the IP address of my former DNS and 24 is the number of bits required to identify the subnet. And 1.2.3.5:/path is the IP address and path of the exported NFS. I couldn't use a hostname because I'd just destroyed my primary DNS -- right? If you were planning to use commands like this in a similar situation, you would replace these with values appropriate for your own network.

After this last command had completed I rebooted, and I had my primary DNS back. There were a few things that had to be tweaked again with /stand/sysinstall. Obviously there are some items ferreted away in hidden corners of the disk. I also gained the impression that /stand/sysinstall would have rebuilt the filesystems with the new disklabels, if I had edited them in situ. However, before attempting this I would have backed up anyway. If it is true that /stand/sysinstall does rebuild the file systems, I suspect that it would have to be in single-user mode to work. I will RTFM (when I get time) to find out if this is the case. If anyone knows for sure maybe you could drop me a line at feedback This approach (i.e. backing up to an archive on the NFS mounted drive) worked so well, that I will use it as a backup method for the mail server (it will be called from cron). Hopefully the zipped archive will fit on a single tape on my rather ancient tape drive.

I then returned to the IMAP installation. This was mostly a matter of following the instructions. There are a number of steps to follow in the installation process but it is well documented in the documentation shipped with the product (just point lynx at /usr/local/share/doc/cyrus/index.html). One thing you have to do is fix up the user cyrus, which is installed with a home directory of /nonexistent (which does not exist), and a shell of /sbin/nologin. I changed these values because there are a few things that need to be done by the cyrus user during the install. It is probably a good idea to set it back when these tasks are completed. The cyrus user could be a security hazard since it is able to decrypt system passwords (including root), and it is safer to deny login to this user. This is the way that that most system or daemon users are setup in BSD, although it is not really an issue for a small site like mine. The setup of clients is even more difficult For the time being I have chosen mutt as my MUA which have only been using for a few weeks. Up till now I have used elm or (don't laugh) mailx on Unix systems. On Microsoft systems I have used Netscape Messenger. I have been meaning to evaluate mutt for a while now. I tried to build it on CygWin a couple of years ago, without success. I do like the features, and the description (a mongrel of an MUA) is very droll. However it seems that the IMAP and SSL support is still in the developmental stage. I may have a look at pine (which like mutt is a descendant of elm). During the testing of the IMAP server, my ISP had an outage. And the server died! At first I thought it was some strange bug in the IMAP software. It turned out that the problem was the Dyanlink modem. When the ISP's network goes down it seems that the RTA020 can no longer route. So not only do I have the inconvenience of losing connectivity to the internet, but my LAN goes down as well. This was certainly a good incentive to to hasten the plans to build my own router.

There were a two things I was not happy with:

The server did not support virtual hosts.
I had to clobber my existing mail boxes (delivered to /var/mail).

The next server I was going to trial was Eudora but I only got as far as reading the documentation. As far as I could tell it would have the same approach to cyrus. What I would have preferred was a mail server that read from the existing /var/mail mailboxes and then moved the read mail to another folder. In the end I was running out of time, so I have opted for SMTP. The other (Unix) machines are configured with the "nullclient" feature in sendmail and everything gets forwarded throught the mailhost. This is fine in the Unix world, but an MUA on a Microsoft machine will work better with IMAP or POP3, so I will have to continue with the evaluation of servers. In the meantime I will leave my mailhost as plain old vanilla SMTP.