A Linux Email Server
Marcel Gagné Electronic mail is a strange beast. In the past few years, I've set up a number of electronic mail and Internet gateways. Some of my customers are smaller companies with a few employees and no desire to pay huge amounts of money for a 24x7 ISDN or DSL connection. They want to try out the Internet and email, and see how it fits into their corporate model without investing in a lot of hardware and software. For companies such as these, Linux is made to order. Out of the box, your favorite Linux distribution comes with everything necessary to set up a complete Internet/intranet solution -- from email to Web servers and even firewalls. Best of all, in the spirit of Linux and open source, all the software is free! Defining the Network Imagine a local network consisting of the hot new Linux system and six PCs. The Linux server is at address 192.168.1.100, and the PCs are at addresses 192.168.1.31 through 192.168.1.36. The private internal network addressing scheme as defined in RFC1918 is used. I'll call the Linux server “mailserv”. The fully qualified domain name is mailserv.mycompany.com. Each PC has its own mail client. All mail traffic goes through the Linux server. For this article, I'll create a local mail server. For this example, I used a RedHat 6.0 system. There should be little here that does not directly relate to your specific distribution. Any RPM-based distribution (Caldera, TurboLinux, Mandrake) will behave in a similar manner. The Components As I mentioned, the Linux distribution will come with all the things you need to get 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 should be your favorite email package. I often recommend Pegasus, a great Windows email package that is freely distributed (though not GPL'ed). Your MUA could also be something like Netscape mail, Eudora, or Microsoft Outlook. Another alternative that would simplify things would be to have users telnet into the server, log into 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. Before I move on to the specifics of those components, I will review how an email message moves from one person or system to the next. Imagine the user “Tux” writes user “Elvis” an email message. Tux fires up his Netscape email package, clicks “New Message”, and addresses it to “Elvis”. After Tux finishes typing, he clicks “send”. In the background, Tux's mail package (MUA) calls Sendmail (MTA) to handle the message. Sendmail does several things -- first, it deciphers the message and determines how to transfer it. In this case, Sendmail recognizes this as a local address and passes it on to procmail (LDA) for local delivery. If Tux had addressed this message to the Internet, the local Sendmail would have contacted the remote machine (via TCP/IP port 25) and transferred the message.The remote Sendmail would analyze the header, recognize the local address, and pass the message to the LDA for delivery. After taking over from Sendmail, the LDA would route the message to “Elvis'” inbox. Depending on the remote machine's operating system, the LDA could be another procmail, deliver, or a simple program called mail. Some time later, Elvis starts his MUA (i.e., Pegasus mail or Outlook) and collects the message. By clicking “check for mail”, he tells his MUA to contact the mail server and send any mail sitting in his mailbox. The program that accepts requests for mail pickup from the MUA is called a POP3 server. Therefore, the packages you need (if not already installed) are:
• Sendmail (your MTA) • procmail (your LDA) • IMAP (which includes you POP3 server, ipop3d)
I've chosen Sendmail rather than qmail (or some other alternative) because it is pretty universal and Sendmail will probably be installed already. IMAP, on the other hand, was not part of my default RedHat installation. Since the IMAP package contains the POP3 server, I'll briefly cover that. Setting up the POP3 Server The POP3 server listens for mail pickup requests from the users. If the POP3 server receives a pickup request, the POP3 server forwards all waiting messages to the email client program on the user's PC. To check whether you have the IMAP POP3 server installed, use this version of the rpm command:
# rpm -q imap If the system responds with something like 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 You may 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. Next, refresh the inetd process 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 because a kill -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 concerned, 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 not the best name for setting up the 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 the Sendmail program put in your domain name by making the one modification that I recommend in the Sendmail configuration file. I mentioned that this email server is not going to be connected to the Internet, but if you make this easy change now, you won't need to do it later. Using your editor, open /etc/sendmail.cf and look for the lines shown in Listing 1. Notice the part that talks about my official domain name. The line that reads Dj$w.Foo.COM has been copied and rewritten with the 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, I'll call the domain mycompany.com. That is the only change needed in the /etc/sendmail.cf file. The next file to modify is /etc/sendmail.cw. This file contains a list of all the domains and systems for which the server will accept mail. For instance, if you edit the file with your editor, and add the domain name (mycompany.com) and the localhost name (localhost), you end up with this simple file:
# sendmail.cw - include all aliases for your machine here. mailserv mailserv.mycompany.com mycompany.com localhost This tells the Sendmail daemon to accept mail messages addressed to either user@localhost, or user@mycompany.com, or any of the aliases you have set up. Next, you 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). Particularly galling are the spammers who use other people's email servers to route their mail traffic. Fortunately, 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 unfamiliar machines or domains. 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 have for using Sendmail to relay messages on the server. Be sure to 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, restart Sendmail. The different distributions will vary slightly in this manner. With 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 That's all you really need to do with Sendmail and IMAP in order to send and receive mail on this small network. To DNS or Not to DNS For Sendmail to route mail properly, it must be able to resolve domain names to IP addresses. An email server operating on the Internet uses DNS servers for name resolution. Simply put, a DNS, or Domain Name Server, takes a system's IP address and converts it to a more “human” name (like mailserv.mycompany.com). It will also convert that name back to its numeric IP address. On the server, mailserv.mycompany.com would become 192.168.1.100, or vice-versa. This requires the setup of “zone” files and domain tables and can be quite complex. For the small network here, it is easier to list host-to-name-to-IP-address mappings in the /etc/hosts file:
127.0.0.1 localhost 192.168.1.100 mailserv.mycompany.com mailserv 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 simple version called a “caching nameserver”. For this example, you need to get rid of it or it will try to use the DNS to resolve the address of the local machine. The mail client will usually time out waiting for the system to return with a failed DNS lookup, which is not a good idea. The easiest way is to rename the /etc/resolv.conf file:
# mv /etc/resolv.conf /etc/resolv.conf.orig Next, stop the DNS by shutting down 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 Of course, if your network has been set up for a while and you have a fully configured DNS, you should simply continue using it. 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 systems administration functions) I 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 thing to do is create an alias for your office. Aliases are also useful if you want to add something like sales@mycompany.com that you want redirected to the salespeople. Another useful alias, office@mycompany.com sends mail to everybody. The file you need to edit is called /etc/aliases. Open the file using the editor. The format of the aliases file is simple:
alias_name: real_name1,real_name2,real_name3, . . . The alias_name is the name for which you are creating the alias. In the example above, it would be “sales” or “office”. After the colon, hit tab (or 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. 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 similar to this:
/etc/aliases: 14 aliases, longest 10 bytes, 152 bytes total The new aliases are ready to roll. The server now has Sendmail and a simple DNS set up, the users have been created (in a virtual sense), and there are aliases for the office and sales team. The only thing left is the clients. Setting up Your Client MUAs The ways that a user can collect mail continually change. 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.) Because the email server will both send and receive mail, the MUA configuration is simple. If you are using “Netscape Communicator” for email, click “Edit”, then click “Preferences”. When the Preferences window pops up, click one more time on “Mail and Newsgroups” in the Category menu. There are two groups of settings need to change -- the first is “Identity” (see Figure 1) and the second is “Mail Servers” (Figure 2). In the identity dialog, enter the full name (i.e., Tux M. Penguin) and email address (tux@mycompany.com). 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 “mailserv” 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 “mailserv” again as the Outgoing Mail (SMTP) Server. The outgoing user name is Tux's email address, “tux@mycompany.com”. Another example is Pegasus Mail, a great Windows email client developed by David Harris. Figure 3 shows 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”) enter the user's email address (in this case, tux@mycompany.com). The second tab (pictured) is “Receiving (POP3)”. For our POP3 host, enter “mailserv”, the email server's hostname. The user name and password are “tux” and whatever password assigned to him earlier. Finally, under the “Sending (SMTP)” tab, enter “mailserv” one more time, since the server is handling both sending and receiving of mail. I've included two examples to show 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 your email address. One Last Little Bit Since we are not setting up a DNS in this example, the PCs need to have the address for the email server 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 Add this line:
192.168.1.100 mailserv.mycompany.com mailserv Click on “File” in the editor, and choose “Save” then “Quit”. Send Some Mail Bring up your mail client, and send mail to the office. In the “To” field, enter office@mycompany.com. Enter some clever subject and text, then click on the “send” button. Each of the users should now be getting mail. Conclusion Becoming a master of Sendmail alone is a daunting task -- this is a massive program. However, 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. Resources http://metalab.unc.edu/mdw/linux.html -- The Linux Documentation Project. http://www.netscape.com -- Netscape Communications. htt p://www.pegasus.usa.com -- David Harris' Pegasus Email Web site. http://www.redhat.com -- Red Hat Software. http://www.rfc-editor.org -- The RFC Editor. http://www.sendmail.org -- The Official Sendmail Web site.
About the Author
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 TransVersions, 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 contacted at: mggagne@salmar.com. You can discover lots of other things from his Web site at: www.salmar.com.
|