CTS 2333 (Unix/Linux Networking) Project
Mail Service Configuration

 

Due: by the start of class on the date shown on the syllabus

Description:

In this project you will build and use a SOHO Mail server.  Your mail service will include SMTP service with the postfix MTA, POP3/ IMAP service with the Dovecot MAA, and Web mail access with the Squirrelmail MUA.  Your email service will use the Maildir mail storage system rather than the more traditional mbox format.

Actually Dovecot supports Maildir++ format, an extension that adds sub-folders and mail quota.  Most systems (MUAs and MDAs) that claim they support “Maildir” actually mean they support “Maildir++”.  (Note while the author of the format spells it with a lowercase “m” most of the world uses “Maildir” or “Maildir++”.)

A proper mail service (as with most services) generally requires a static IP setup and additional DNS records.  However you would need to learn more about networking to do this properly, so we will save this for another project.

(Time permitting, mail service configuration continues in a CTS-2311 (Unix/Linux Security) course project to add full functionality, including virus and spam scanning and authentication.)

Background:

All required background material, including resource links, lecture notes with step-by-step directions, and sample configuration files, can be found here.

Note!  Fedora may not have correct SELinux policy rules for Dovecot or other servers.  It is strongly suggested you make sure SELinux is run in permissive mode for this project.  One way to always boot up in permissive mode is to edit the file /etc/selinux/config and follow the comments to change the mode.

Squirrelmail

Squirrelmail is a collection of PHP generated HTML forms that can either directly access mailboxes (MBOX but not Maildir!), or more commonly use an MAA, typically IMAP.  Thus you will need to have your mail service (including IMAP) setup and working before you can setup Squirrelmail.

Although Squirrelmail can be configured to use IMAPS, the user enters usernames and passwords (and composed email) in HTML forms.  The resulting HTTP packet is sent in plain text form to your MAA.  This is clearly a security problem!  In this assignment we will use the same server for web-mail and the MAA, so no sensitive data is transmitted across a network.  In general, you should only configure web-mail from secure HTTPS connections.  (This will be done in a project for the Unix/Linux Security course, but you might not complete that project in time to work on this one, so there is no requirement for that.)

Requirements:

You may work individually or in groups on this project.  Each student in a group must submit an identical copy of the assignment, which must include both student names.

Install, configure, and test a mail service suitable for SOHO use.  Unlike some previous projects the steps will not include specific commands to run.  At this point you are expected to be able to locate relevant commands and documentation using the skills you have learned.  (But don't panic!  The resources section includes a copy of email lecture notes you can use, and the Internet resources for email setup are very good.)

Perform the following tasks and answer the following questions (optional steps appear in italics in a gray box and start with the phrase “(optional)”):

  1. Setup a Static IP and DNS configuration suitable for a mail server, if you haven't already.  Start by choosing a host name for your server in the “fake” (meaning, nobody currently has this domain) domain of gcaw.org.  Edit the HostNameList page found in our class wiki at YborStudent.hccfl.edu/UnixWiki/.  You need to add your name and chosen hostnames to the list, along with the static IP address for your host.
  2. Next, configure your host with your hostname and static IP address.  Your textbook contains the required information for this.  Here is the information needed for our classroom LAN:
    LAN Data for DTEC 461 — vlan325
    Network address: 10.142.255.0
    Mask: 255.255.255.0
    Gateway: 10.142.255.1
    Range for static use: 10.142.255.11–127
    Range for DHCP use: 10.142.255.128–254

    Remember the contents of the configuration files is documented in /usr/share/doc/initscripts*/sysconfig.txt; scroll down for the entries for “network” and “ifcfg-”.

    While your textbook contains excellent directions on how to set up your host with a static IP address, you may have a couple of additional issues to deal with.  Modern versions of Fedora don't enable the traditional “network” service by default.  Instead you may find “NetworkManager” used.  This is a replacement networking service daemon designed to handle wireless networking automatically.  Although this service uses the same configuration files, the contents can be slightly different.

    You need to see if “NetworkManager” is running.  If so, feel free to turn it off and turn on “network” legacy service instead.  Make sure the change persists across a reboot!  Otherwise, make sure your config files are correct for the newer service.

    The other issue is that the systems are configured by default to have no “eth0” NIC.  On these systems, udev and/or systemd is renaming the interface at boot time to something else.  If this is the case on your host, you will need to configure the correct NIC instead of eth0 shown in the examples.  The steps and files are all the same except for this change in the file name and in the configuration files where “eth0” is referenced.

    What changes did you make to turn off DHCP, provide a static IP address, and a hostname that works?

    Use ping to verify your hostname can be found.  (Other tools such as dig, host, or nslookup only use DNS to resolve names.  You could use “getent hosts name-or-IP” but ping is easier to remember.)

  3. What steps would be needed to configure static IP on a Debian-based system such as Ubuntu?  On Solaris 10?  On FreeBSD?  (It is okay to answer these questions by providing appropriate URLs only.)
  4. Once you turn off DHCP you will need to configure your resolver library as well.  There are several ways to make this work.  You can simply point your resolver to the instructor's host, which is running a nameserver that will know about the class gcaw.org domain.  Or you can set your caching name server to forward all requests to the instructor's host.  Add all the names found on the class wiki “HostNameList” page for our class to your /etc/hosts file.  Configure nsswitch.conf to use files before dns.  (You can set your wiki account to “watch” this page, so as other students add to the page you will be automatically notified.  You can then update your /etc/hosts file as needed.)  What is the final version of your /etc/hosts file?

    Also note you won't be configuring any MX or other email related records — you only have a singe host to use in our class and not a whole domain.  But suppose your mail server was the only one for the entire gcaw.org domain and that you had to add email related DNS records to your (primary) name server.  What DNS records should you add?

  5. Configure the Postfix MTA.
    1. This includes turning off any other MTAs (such as sendmail) configured to run at boot time, and making sure they are off now.  Then use alternatives command to switch all shared commands to your chosen MTA (if set to, say, sendmail).  If there was no alternatives system (or some equivalent) what would you do if you need to switch MTAs (or another subsystem that uses conflicting pathnames)?
    2. Make sure the required software is installed, for both the alternatives command and the Postfix MTA.  (You can install other software as needed later.)  Be sure to install the alternatives system first.  What packages are needed?  How did you determine this?
    3. Configure your firewall (and possibly TCP Wrappers) to allow incoming TCP connections on port 25, from anywhere.  What changes did you makefor this?
    4. Before editing any configuration files you need to change, make a copy of the originals.  By default, MTAs accept mail from localhost only.  Edit /etc/postfix/main.cf to accept email from other hosts (or at least the others in our class network).  Use the system default mailbox (an mbox) for now.  Check the syntax, and then start (or reload) the MTA and test the result.  What changes did you make (show diff output comparing the original and modified file(s))?  How do you check that the email service is working correctly (be specific)?
    5. Use some MUA such as mutt to send and read email to your non-root account on your host, from your host.  Then try to send and read email to your non-root account on your host, from a different host.  (You should ask a fellow student or your instructor to send you the email; note that sending email from the wireless network or other hosts not connected to the classroom LAN may not work.)  Examine the log files for any problems.  What extra steps, if any did you need to perform?  What log entries were generated, and in which log files?
    6. Verify the email aliases are setup correctly and if needed rebuild the aliases database.  (Make sure you use the correct aliases file, there may be several on the system!  Read the Postfix configuration file to see which file gets used.)  What email-related aliases should always be present?  Why is it important to set root as an alias to a real person on a server?
  6. Configure the MDA used by your MTA to deliver email to the user's home directory in “Maildir” format to “~/Maildir/”.  Now reload the mail server and test the changes.  Send email to some user and check their home directory (and the log files) to verify this works (the new mail files and folders were created).  What changes did you make?
  7. Configure MUAs to read local mail from the new Maildirs.  Not all MUAs support Maildirs (notably pine, but there is a patch if you have the source).  Configure the mutt MUA to use Maildirs.  (Sample configurations for MUAs can be found in the lecture notes found on-line in the email resources.)

    Make sure you can send and receive emails with muttWhat changes did you make to your MUA configuration?

    (Optional)  Install if necessary the mailx (formally known as nail) replacement package for mail.  (Personally I have set a shell alias for mail to mailx).  Now configure mailx MUA to use Maildirs and test the result.  Finally, repeat for any other MUAs you use including GUI MUAs.  Report any changes made.
  8. Configure IMAP and POP3 service with Dovecot.  (While Courier or Cyrus are more popular MAAs, especially with ISPs, Dovecot is very easy to install and works well.)
    1. Configure your firewall to allow incoming POP3 and IMAP TCP ports.  Beside the firewall on this host, what other changes might you need to make to allow others to read email remotely using your MAA?

      For POP3S and IMAPS (the secure versions) you must have a valid PKI certificate for your site.  (We will learn about this in CTS-2311 class.)  Dovecot includes a self-signed certificate for localhost.localdomain that will be fine for this project.  However to generate a real certificate you would need to edit the file /etc/pki/dovecot/dovecot-openssl.cnfWhat edits would you make to this file?

    2. Configure the Dovecot IMAP/POP MAA to start automatically at boot time.  Be sure to add that change (and every change, of course) to your system journal.
    3. Next, configure Dovecot to use Maildirs (since that is where Postfix is now configured to deliver email), and make any other needed changes to support local users.  (Hint: You need to set the mail_location parameter in the file 10-mail.conf.  Be sure to make a copy first of any file(s) you edit.)  Make sure it is running correctly now.  What changes did you make?  (Show diff output.)
    4. Check the log files for any problems.  You can test to see if the daemon is running by using telnet localhost pop3 (or imap). 

      To test if the secure ports are working use openssl s_client -connect localhost:pop3s, (or imaps).

    5. Configure your MUA to read your email via IMAP and make sure you can read your email.  mutt and alpine can read email from IMAP if you change the (incoming) mailbox to this URL (instead of the normal pathname): imap://userName@localhost/INBOX.  You can set this as the default by “exporting” the MAIL environment variable in a login script.  Now test by sending some mail to your account from your MUA, and try reading it using the MUA configured for IMAP.  Examine the log files to make sure there were no problems.
  9. Install the squirrelmail package.  What other packages (if any) does this require?
  10. Next, cd to the Squirrelmail directory (/usr/share/squirrelmail)  Here you will find the Squirrelmail configuration program, config/conf.pl.  Run this program (from the Squirrelmail directory), and record the choices you make.  (If you see a blank screen, it is likely the text color is the same as the background color.  Use the command “C” (and hit enter) to turn off colors.)
  11. Start your configuration by choosing the Dovecot pre-configuration.  Then browse the other menus and make any additions or changes you wish.  What changes did you make?  (As always, make sure all changes made are recorded in your system journal.)
  12. Once installed, you should test Squirrelmail.  This usually requires restarting or reloading your web server first.  Then using any web browser, view the URL of
    http://server-name/webmail/src/configtest.php

    (You can use localhost for server-name.)  That will run some tests, and at the bottom of the page will report the results, hopefully that your configuration is working.  If not, re-run the configuration program and change the incorrect setting(s).  Repeat until this works.  Don't forget to record all configuration changes as you make them!

    By default, the Apache config for Squirrelmail re-writes URLs from http:// to https://.  Since Apache may not be configured for that, nothing is listening on port 443, and you will get a “connection refused” message when you try.  You will need to comment-out these three lines in Apache's squirrelmail.conf config file, then restart Apache:

    RewriteEngine  on
    RewriteCond    %{HTTPS} !=on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
    

    To trouble-shoot any issues, look at the error_log (and possibly the ssl_error_log) file(s).

  13. Now use your Squirrelmail web MUA to read and send some email.  What is the correct URL to access Squirrelmail from your local host?  A good idea is to add a link for that to your website's home page., but this is not required.  If you do add one, verify the link you added works properly.
  14. What log file(s) does Squirrelmail use (if any)?  What change(s) (if any) did you make to ensure Squirrelmail's log file(s) are rotated regularly?
  15. Make sure your new mail services are using the proper “syslog” facilities for logging, and that you have configured “syslog” to save email related log messages in the proper log file(s).  What changes (if any) did you make for this?
  16. Verify all new log files (both email and possibly DNS) are properly rotated.  What log file(s) are used for your email service?  What log roration policy did you implement?

Hints:

To be turned in:

A copy of your project-rellated journal entries and the answers to the questions asked above.  You can send as email to (preferred).  If email is a problem for some reason (!), you may turn in a hard-copy.  In this case the pages should be readable, dated, and stapled together.  Your name should appear on the first page. 

Don't turn in your whole journal, you will need to add to it every day in class!  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).

Please see your syllabus for more information about submitting projects.