|
|
|
A Linux Email Server
Copyright : 2000, Marcel Gagné
Approximately 3000 words.
Originally appeared in Feb 2000 issue of SysAdmin Magazine
Introduction
Electronic mail is one of those strange beasts. Take your average small company that is only now looking at the idea of getting set up with a domain name and electronic mail for the office. Yesterday, email was way off their corporate radar. Who needs it? You can get up, walk over to your co-worker's desk and chat with them. You can write them a letter or a memo or call them on the phone. Internet email? Even less useful. Maybe we'll look at it someday. Time passes. The boss is eventually convinced that maybe they could start with an email gateway in-house. A few short days later and everyone wonders how they ever did business without it. The question is no longer "Do we need email?" but "What does it take to get us on the internet?"
In the last few years, I've set up a number of electronic mail and internet gateways. Some of my customers tend to be smaller companies with a dozen employees and little desire to pay huge amounts of money for a 24x7 ISDN or DSL connection. They want to "try out" the internet and, by extension, email, and see how it fits into their corporate model. They can maybe spare an old PC (maybe a 486), a modem, and a few dollars a month for an internet connection. Mission unlikely?
For these companies, Linux is made to order. Out of the box, your favourite Linux distribution comes with everything you need to set up a complete internet/intranet solution, from email, to web services, and even firewall services. Best of all, in the spirit of Linux and open source, all the software you need is free!
Defining the Network
Let us create (or hypothesize) a local network consisting of our hot new Linux system and six PCs. The Linux server is at address 192.168.1.100 while the PCs are at addresses 192.168.1.31 through 192.168.1.36. We are using the private internal network addressing scheme as defined in RFC1918. We'll call the Linux server "gateway". The fully qualified domain name would be "gateway.mycompany.com".
Each PC will have its own mail client. All mail traffic will go through our Linux server. For this article (and space considerations) we are going to be creating a local mail server. Next month, we'll take this very network, add an internet connection and start talking to the world. For now, we'll keep it simple.
In creating this article, I used a RedHat 6.0 system. There should be little here that you cannot directly relate to your specific distribution. Any RPM-based distribution (Caldera, TurboLinux, Mandrake) will behave in much the same way as I describe.
The Components
As mentioned above, your Linux distribution comes with all the things you need to get yourself up and running. On the server end, those things are a mail transport agent or MTA, (sendmail), and a local delivery agent, or LDA (usually a program called 'deliver'). The client side consists primarily of a mail user agent, or MUA, which usually lives on the user's PC. This will be your favorite email package. I often recommend Pegasus, a great Windows email package that just happens to be freely distributed (though not GPL'ed). Your MUA could also be something like Netscape mail, Eudora, or Microsoft Outlook.
I should mention that we do have one other alternative which would make things amazingly simple, though not as exciting from the user perspective. Our users could telnet into the server, log in to a shell prompt, and use a text-only mailer like 'pine' or 'elm'. No fancy Windows packages and no GUIs. Going that route requires no MUA setup.
The packages you need (if not already installed) are as follows.
I've opted for sendmail rather than qmail (or some other alternative) because it is pretty much universal. My second reason is that sendmail will likely already be installed. Imap, on the other hand, was not part of my default RedHat install. Since the imap package contains the POP3 server, we should spend a moment and deal with it.
Setting up the POP3 Server
The POP3 server listens for mail pickup requests from the users. To check whether you have imap installed, use this version of the "rpm" command.
# rpm -q imap
If the system responds with something like this, "imap-4.5-3", then the package is already loaded. If not, mount your distribution CD-ROM and install imap.
# mount /mnt/cdrom
# cd /mnt/cdrom/RedHat/RPMS
# rpm -ivh imap-somereleasenumber.i386.rpm
One last thing before we leave POP3 and move on -- you will probably also need to activate those services in "/etc/inetd.conf". Here's the line pertaining to pop3 before I change it in /etc/inetd.conf.
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
Uncomment the line by removing the hash mark at the beginning. We will now need to refresh the "inetd" process in order for this change to take effect. Find inetd's process id and send a SIGHUP to it. That means you do a 'kill - 1' on the process. BE CAREFUL. A 'kill dash 1' looks an awful lot like a 'kill 1'. The master process on the system is 'init' and it runs at process id 1. Kill init and you kill the whole system. If you are worried and don't mind typing a few extra keystrokes, use 'kill -SIGHUP' instead of 'kill -1'. Here's how it looks.
# ps ax | grep inetd
391 ? S 0:00 inetd
6568 pts/0 S 0:00 grep inetd
# kill -1 391
#
On my RedHat system, I can also restart inetd like this.
/etc/rc.d/init.d/inet restart
The next step is to refresh sendmail.
Setting up sendmail
Depending on how your account is set up with your ISP, the domain name of your server may be something like dhch3-ip1.theirdomain.com which is probably not what we want in setting up our email gateway. For a return address, user 'fred' would wind up as "fred@dhcp3-ip.theirdomain.com when sending mail from the local system. You can have your sendmail program put in your domain name by making the one modification that I will recommend in your sendmail configuration file. Now, I realize that I mentioned that this email server was not going to be hooked up to the internet, but if you make the change now, you won't need to later. Besides, it's easy.
Using you favorite editor, open /etc/sendmail.cf and look for the following lines.
################## # local info # ################## Cwlocalhost # file containing names of hosts for which we receive email Fw/etc/sendmail.cw # my official domain name # ... define this only if sendmail cannot automatically determine your domain #Dj$w.Foo.COM Djmycompany.com CP. # "Smart" relay host (may be null) DSlocalhost |
Notice the part that talks about 'my official domain name'. The line that reads "Dj$w.Fo.COM" has been copied and rewritten with our domain name to define the 'Dj' macro. A macro in 'sendmail' parlance is very much like an environment variable in your bourne, korn, or C shell. The Dj macro references your canonical hostname. For this article, we'll call our domain mycompany.com.
That is the only change we want to make to our /etc/sendmail.cf file. The next file we need to modify is "/etc/sendmail.cw". This file contains a list of all the domains and systems that our server will accept mail for. For instance, if we edit the file with our favorite editor (vi?) and add our domain name (mycompany.com) and the localhost name (localhost), we wind up with this simple file.
# sendmail.cw - include all aliases for your machine here. gateway gateway.mycompany.com mycompany.com localhost
This tells our sendmail daemon to accept mail messages addressed to either "user@localhost" or "user@mycompany.com", or any of the aliases we have set up.
Next, you will need to edit "/etc/mail/relay-domains". One of the great annoyances of modern email is SPAM, those unwanted bits of advertising that seem to rain down in your email box. My personal favorites are the ones that promise to help me make money fast! Particularly galling are the spammers who use other people's email servers to route their mail traffic. All kidding aside, the modern incarnations of sendmail make it difficult for spammers to use your machine as a relay. In fact, unless otherwise specified, sendmail will refuse to deliver messages from machines or domains it has not been told about. That is where the "relay-domains" file comes into play.
Edit the file and add the following.
localhost
127.
mycompany.com
192.168.1.
This should cover all hosts in your small networked office, including any need you may have for using sendmail to relay messages on the server itself. Make sure you include the dot at the end of your localhost domain address (127.) and at the end of your private network and domain (192.168.1.).
Stopping and restarting sendmail.
After making these configuration changes, you need to restart sendmail. The different distributions will vary slightly in this manner. If you are using Red Hat or TurboLinux, simply do the following.
/etc/rc.d/init.d/sendmail restart
If your distribution of choice is Caldera, you can use the following command.
/etc/rc.d/init.d/mta restart
Caldera defines the MTA in "options" under /etc/mta .
If all else fails, you can kill the sendmail process and restart it the old-fashioned way by issuing this command.
/usr/sbin/sendmail -bd -q5m
Guess what? That's all we really need to do with sendmail and imap in order to send and receive mail on our small network. If it weren't for the fact that there are other pieces to the mail server puzzle, we could stop here. We are almost there.
An Incredibly Simple DNS Setup
For sendmail to route mail properly, it must be able to locate other machines throughout the world. To do this, it uses a program called a DNS, or Domain NameServer. A true DNS requires far too much complexity for a simple network like ours, particularly since it is a private, closed network (for now). In fact, on our little network, listing the machines in your /etc/hosts file is an easy alternative and it's really all we need. It's not a real DNS, but it will serve the purpose.
127.0.0.1 localhost 192.168.1.100 gateway.mycompany.com gateway mycompany.com 192.168.1.31 john 192.168.1.32 myrtle 192.168.1.33 bonnie 192.168.1.34 gilbert 192.168.1.35 elvis 192.168.1.36 tux
Usually, the standard Linux install fires up with a DNS already present. This is a very simple version called a "caching nameserver". For now and for this example, we want to get rid of it otherwise it will try to use the DNS to resolve the address of the local machine. The cost here is time. The mail client will usually time out waiting for the system to return with a failed DNS lookup. Not a good idea. The easiest way is to first rename the "/etc/resolv.conf" file.
# mv /etc/resolv.conf /etc/resolv.conf.orig
Next, stop the DNS by shutting down its process, the "named" daemon.
# /etc/rc.d/init.d/named stop
To make sure named does not restart on boot, use this command.
# chkconfig --del named
Setting up Users and Aliases
You can add users to your Linux system with the 'adduser' command. If you are running a desktop environment like KDE, you have access to 'kuser', a nice user and group maintenance program while GNOME provides 'linuxconf'. I confess that for user maintenance (as well as many system administration functions) I still prefer doing it the old-fashioned way, at the command line.
In its simplest form, 'adduser' works like this.
adduser user_name
You then assign a password with the 'passwd' command.
passwd user_name
One of the things you will likely want to do is create an alias for your office (or perhaps several). This is a fairly simple process. Aliases are also useful if you want to add something like 'sales@mycompany.com' which you want redirected to our two salespeople. Another useful alias, 'office@mycompany.com' sends mail to everybody. Here's how it's done.
The file you need to edit is called '/etc/aliases'. Using your favorite editor (vi?), open the file. The format of the aliases file is simple.
alias_name: real_name1,real_name2,real_name3, . . .
The 'alias_name' is the name you are creating the alias for. In the example above, this would be 'sales' or 'office'. After the colon, hit tab (or just put spaces) and type in your list of user names separated by commas. White space at the beginning of a line implies the continuation of an alias. Here's an example using office.
office: john,myrtle,bonnie,gilbert,elvis,tux
The six email addresses listed after 'office:' will receive a copy of any mail addressed to office@mycompany.com. Now, save your work, and run the following command.
/usr/sbin/sendmail -bi
The 'dash bi (or -bi)' stands for 'build index'. Running this command should return a message something like this :
/etc/aliases: 14 aliases, longest 10 bytes, 152 bytes total
Your new aliases are ready to roll.
Now we have our server with sendmail and a super simple DNS set up, our users have been created (in a virtual sense, that is), and we have aliases for the office and sales team. The only thing left is our clients.
Setting up Your Client MUAs
After spending all this time on the server side, it is finally time to tie it all in together by bringing our clients online.
The number of ways that a user can collect his or her mail has changed and continues to do so. A popular newcomer to the field is the browser-based email package. Still, most people in an office environment will have some kind of preferred email package. Earlier, I mentioned Pegasus and Netscape Communicator among others. Since our email server will both send and receive mail, our MUA configuration is simple.
If you are using "Netscape Communicator" for email, click "Edit", then click "Prefences". When the Preferences window pops up, click one more time on "Mail and Newsgroups" in the Category menu. There are two sets of settings you will want to change. The first is "Identity" (see Figure 1 - netsmail01.gif) and the second is "Mail Servers" (Figure 2 - netsmail02.jpg).
In the identity dialog, enter you full name ("Tux M. Penguin") and email address ("tux@mycompany.com"). At a minimum, this is all you need. On the "Mail Servers" dialog, click "Add" to specify an incoming (POP3) mail server. You will get another dialog box asking you to specify the POP3 server name. This is "gateway" and the Server Type is POP. The user name in this case is "tux". Click 'OK" to return to the "Mail Servers" dialog. There, you will enter "gateway" again as the Outgoing Mail (SMTP) Server. The outgoing user name is Tux's email address, "tux@mycompany.com".
Let's look at another example, "Pegasus Mail", a great Windows email client developed by David Harris. In Figure 3, you have a snapshot of the "Internet Options" dialog from Pegasus version 3.1 (click "Tools" on your Pegasus menu bar and choose "Internet options"). On the first tab ("General") we enter the user's email address, in this case, "tux@mycompany.com".
[ Figure 3, "pegasus.jpg" goes here ]
The second tab (pictured) is "Receiving (POP3)". For our POP3 host, we enter "gateway", our machine's hostname. The user name and password are "tux" and whatever password we assigned him when we created him earlier. Finally, under the "Sending (SMTP)" tab, we only need enter "gateway" one more time, since our server is handling both sending and receiving of mail.
I've included two examples to show you that most Windows email clients follow a similar setup. You need the SMTP and POP3 host defined, a user name and password to pick up mail, and, of course, your email address.
One last little bit.
Since we are not setting up a DNS at this time, the PCs need to have the address for our gateway in the HOSTS file. This file is located in the "C:\WINDOWS" directory. Edit the file by clicking "Start", "Run" and typing this command.
EDIT C:\WINDOWS\HOSTS
Now, add this single line.
192.168.1.100 gateway.mycompany.com gateway
Click on "File" in the editor, and choose "Save", then "Quit".
Let's Send Some Mail.
Bring up your mail client, and send mail to the office. In the "To" field, enter "office@mycompany.com". Now, enter some clever subject and text, then click on your "send" button. Each of your users should now be getting mail.
Conclusion.
Becoming a master of sendmail alone is a daunting task. This is a massive program. The classic sendmail reference from O'Reilly & Associates at over 1000 pages is intimidating to say the least. In my experience, you don't need to have everyone of those thousand pages memorized to create a useful, simple email server.
Besides being rock-solid, Linux is a wonderful platform to deploy network office applications like email. Its UNIX roots mean that it offers the same mature, stable network communications tools that connect the planet. With an unbeatable price tag (FREE), Linux is certainly an affordable platform for businesses of every size. Its ever increasing popularity means you won't be alone if you need help.
Next time around, we will hook this machine up to the Internet and get your users talking to the world. This will require setting up a basic firewall, a "real" DNS, and a dial-on-demand intelligent connection program.
Resources
O'Reilly & Associates
http://www.oreilly.com
The Linux Documentation Project
http://metalab.unc.edu/mdw/linux.html
Netscape Communications
http://www.netscape.com
David Harris' Pegasus Email website
http://www.pegasus.usa.com
Red Hat Software
http://www.redhat.com
The RFC Editor
http://www.rfc-editor.org
The Official Sendmail Website
http://www.sendmail.org
Author Bio:
Marcel Gagné lives in Mississauga, Ontario. In real life, he is president of Salmar Consulting Inc, a systems integration and network consulting firm. He is also a pilot, writes science fiction and fantasy, and edits <i>TransVersions<i>, a science fiction, fantasy, and horror magazine. He loves Linux and all flavors of Unix and will even admit it in public. He can be reached via email at mggagne@salmar.com. You can discover lots of other things from his website at www.salmar.com.