FreeBSD Mail Server with GUI

John C. Place

Some time ago, I was assigned to set up a mail server. However, I did not want the hassles of adding and deleting users as they came and left the company, changed their names, and so on. I decided that it would make most sense if the people doing the personnel changes did the upkeep of the mail accounts. I chose not to deal with one of the many MS Windows-based mail servers for two reasons: usability and cost. Quite a bit of the Internet’s email is handled by UNIX and Sendmail, so why should I be any different? UNIX is a stable and proven platform. But UNIX and Sendmail, although a good combination from a stability and cost view, are terrible when it comes to the user interface. Many people would call it, when compared to Windows mail servers, user hostile. I also wanted to be able to control what the human resources department does to the mail server. With the help of FreeBSD and Apache, and some CGI scripting, this has become a reality.

The process of installing and configuring FreeBSD and Apache is outside the scope of this article, but they do install quite easily on a wide range of hardware. If you have any experience with UNIX or Linux, I have found that it will take less than 2 hours to get the FreeBSD and Apache up and running. There is plenty of documentation at www.freebsd.org and www.apache.org. I have done this with FreeBSD 3.4 and 4.0, and Apache 1.3.9, and I do not see why a newer version of either would be any different. FreeBSD is quite efficient and requires little hardware to run. I have set one of these mail servers up on a Pentimum 133 Mhz with 40 MB of RAM and more than 300 mail accounts.

The most important aspect of a mail server is hard-disk space. With the low cost of IDE, this is definitely not a problem. If you already have a FreeBSD box set up, maybe even a Web server, then this can be easily added to it with little impact to the machine except for the hard disk, which depends on the number of users and what they are emailing. Adding this does not lower the security of the box. The CGI script can only change things in the specified group that it uses, and the accounts it adds cannot login via telnet or ftp because the shell points to no login.

On a running FreeBSD system, you need to make a change to /etc/group and add the group popuser. If you would like to make it another group ID, make sure to change line 8 in the mail_admin script (Listing 1) accordingly. This separate group is set up so that the mail_admin script can only change users in this group. (All listings for this article are available at: http://www.sysadminmag.com.)

Install Apache by downloading the source and running configure, make, and make install. Once installed, the server will be at /usr/local/apache. You should be able to execute /usr/local/apache/bin/apachectl start, and be able to see Apache’s welcome screen from a browser. If you cannot, please refer to the FAQ and man pages from Apache. When compiling Apache from the sources, make sure you do the entire process as root because if you do not, Apache’s config file will point to port 8080, not 80 (this is a common problem). After you have tested to make sure that the server is working, it is a good idea to create a new index.html with your information in it, so users do not stumble upon it and send mail to maintainers at apache.org. If you are not comfortable with installing Apache from these sources, then you can use FreeBSD’s package system to install. However, some directories change by doing this. The important ones (for this article) are:

config files (httpd.conf) in: /etc/apache

Executables in: /usr/local/bin or /usr/local/sbin

Web root directory at: /usr/local/www

For large packages (like Apache), I usually install from source because it provides greater control over what options and modules are linked in. I also like the fact it puts everything under /usr/local/apache, which to me simplifies housekeeping.

Make a directory under Apache’s root called “mail_admin” and copy the mail_admin script into this directory. Next, the SUID bit is to be set. Because this script will change users and passwords, it must therefore have root privileges. This is accomplished by issuing chmod 4555 on the script. At this point, you have the script installed and must now secure it to keep people from making unsanctioned changes to the mail server’s user accounts. In /usr/local/apache/conf/httpd.conf, add a directory container like:

<Directory /usr/local/apache/mail_admin/>
        AuthType Basic
        AuthUserFile /usr/local/apache  \
          /conf/mail_admin.pw
        AuthName mail_admin
        require valid-user
</Directory>

ScriptAlias /mail_admin/ "/usr/   \
   local/apache/mail_admin/"

/usr/local/apache/bin/htpasswd \
   -c mail_admin.pw postmaster

The mail server can now receive mail for any users you add through the CGI script. You must let the users pick up their mail by adding popper. Install popper from the ports collection. Next, edit /etc/inetd.conf and uncomment or add the following line:

pop3   stream  tcp   nowait  root   \
   /usr/local/libexec/popper  popper

As with any project like this, first and foremost in a sys admin’s mind should be security. One concern is that these scripts use the set UID bit to assume root privileges. This is necessary for modifying user accounts.

Perl automatically enables a set of special security checks, called taint mode, when it detects its program running with differing real and effective user or group IDs. These checks keep the risks to a minimum and prohibit the writing of unsecure code. Another concern is that you want to control who runs the mail_admin scripts. At the time of this writing, there are no known bugs that will allow you to circumvent Apache’s authorization. If the server is behind a firewall, then make sure that port 80 is not allowed to the mailserver. Another option is to employ TCP wrappers to restrict which IPs connect to the server on that port, and have inetd start the Apache server. The Apache group frowns on this for performance reasons, but for the mail_admin scripts there should be no problem. One final thought on security, please realize that information is being sent in plain text on the wire. Packet sniffers and other tools will be able to see the information you are passing back and forth. Thus, it is a bad idea to administer this on the Internet. If you put SSL on the server, this will encrypt the transactions. For the truly paranoid, simply allow connections only from localhost, and put the box right next to the person charged with administrating the user accounts.

I chose this setup because I considered it to be the best option for what I needed. A perk is that there are no license hoops to jump through, which will save in cost and aggravation. Also, with the onslaught of email viruses, Sendmail rule changes are quite painless to apply. And if you (like me) are not a wizard at Sendmail rule sets, the fixes for these are posted quickly to several sites on the Internet. Because you are not burdened with administering the mail server, maybe you can learn to write rule sets too.

About the Author

John C. Place has been a Systems Administrator/Programmer for more than 8 years working in QNX, FreeBSD, Solaris, SCO, Linux, and NT. He believes in keeping it simple and using the right tool for the right job. His weapon of choice is FreeBSD for stability and flexibility. He can be contacted at: jcplace@attglobal.net.