Email is still the dominant form of communication over the Internet. It is fast, free, and very easy to use. However, much of what goes on behind the scenes is extremely complicated and would appear scary to anyone who does not know much about how email is handled. Fedora comes equipped with a number of powerful applications to help you build anything from a small email server, right through to large servers handling thousands of messages.
This chapter will show you how to configure Fedora to act as an email server. We will look at the options available in Fedora, as well as take a look at the pros and cons of each one. You will also learn how mail is handled in Linux, and to a lesser extent, UNIX.
Email is transmitted as plain text across networks around the world using the SMTP protocol (Simple Mail Transfer Protocol). As the name implies, the protocol itself is fairly basic, and it has been extended to add further authentication and error reporting/messaging in order to satisfy the growing demands of modern email. Mail transfer agents, or MTAs, work in the background transferring email from server to server allowing emails to be sent all over the world. You might have come across such MTA software such as Sendmail, Postfix, Fetchmail, Exim, or Qmail.
SMTP allows each computer that the email passes through to forward it in the right direction to the final destination. When you consider that there are millions of email servers across the world, you have to marvel at how simple it all seems.
Here is a simplified example of how email is successfully processed and sent to its destination:
[email protected]composes and sends an email message to[email protected].The MTA at
hudson.orgreceivesandrew’s email message and queues it for delivery behind any other messages that are also waiting to go out.The MTA at
hudson.orgcontacts the MTA athudzilla.orgon port 25. Afterhudzilla.orgacknowledges the connection, the MTA athudson.orgsends the mail message. Afterhudzilla.orgaccepts and acknowledges receipt of the message, the connection is closed.The MTA at
hudzilla.orgplaces the mail message intopaul’s incoming mailbox;paulis notified that he has new mail the next time he logs on.
Of course, several things can go wrong during this process. Here are a few examples:
What if
pauldoes not exist athudzilla.org? In this case, the MTA athudzilla.orgrejects the email and notifies the MTA athudson.orgof what the problem is. The MTA athudson.orgthen generates an email message and sends it to[email protected], informing him that nopaulexists athudzilla.org(or perhaps just silently discards the message and gives the sender no indication of the problem, depending on how the email server is configured).What happens if
hudzilla.orgdoesn’t respond tohudson.org’s connection attempts? (Perhaps the server is down for maintenance.) The MTA athudson.orgnotifies the sender that the initial delivery attempt has failed. Further attempts will be made at intervals decided by the server administrator until the deadline is reached, and the sender will be notified that the mail is undeliverable.
There are several MTAs that are available for Fedora, each with pros and cons to being used. Normally they are hidden under the skin of Fedora, silently moving mail between servers all over the world with need for little or no maintenance. Some MTAs are extremely powerful, and are able to cope with hundreds of thousands of messages each day, whereas others are more geared toward smaller installations. Other MTAs are perhaps not as powerful, but are packed full with features. In the next section, we will take a look at some of the more popular MTAs available for Fedora.
The overwhelming majority of emails transmitted over the Internet today is handled by Sendmail, which just so happens to be the default MTA supplied with Fedora. It is extremely popular across the Linux/UNIX/BSD world and is very well supported. There is a commercial version available, which has a GUI interface for ease of configuration.
As well as being popular, Sendmail is particularly powerful compared to some of the other MTAs. However, it is not without its downsides and other MTAs can handle more email per second in a larger environment. The other issue with Sendmail is that it can be extremely complicated to set it up exactly as you want it. Thankfully there are a few books available specifically for Sendmail, but the most popular one has more than a thousand pages, reflecting the complex nature of Sendmail configuration.
Thankfully the default configuration for Sendmail works fine for most basic installations out of the box, making further configurations unnecessary. Even if you want to use it as a basic email server, you have to do only some minor tweaks. The level of complexity associated with Sendmail often leads to system administrators replacing it with one of the other alternatives that is easier to configure. We will take a look at some basic Sendmail configuration later on in this chapter in the section titled “Basic Sendmail Configuration and Operation.”
Postfix has its origins as the IBM Secure Mailer, but was released to the community by IBM. Compared to Sendmail it is much easier to administer, and has a number of speed advantages. Postfix offers a pain-free replacement for Sendmail, and you are able to literally replace Sendmail with Postfix without the system breaking a sweat. In fact, applications that rely on Sendmail will automatically use Postfix instead and carry on working correctly. This is due to Postfix using a Sendmail-wrapper, which deceives other programs into thinking that Postfix is Sendmail. This wrapper, or more correctly, interface, makes switching to Postfix extremely easy.
Caution
Fedora provides Postfix version 2.2, which uses a slightly different configuration than the earlier version. If you are upgrading Postfix from an earlier Fedora or Red Hat version, check your configuration files.
Fedora also now compiles Postfix and Sendmail against version 2 of the Cyrus SASL library (an authentication library). The Release Notes contain detailed information on file location and option changes that affect you if you use these libraries.
For enhanced security, many Postfix processes used to use the chroot facility (which restricts access to only specific parts of the file system) for improved security, and there are no setuid components in Postfix. With the current release of Fedora, a chroot configuration is no longer used and is, in fact, discouraged by the Postfix author. You can manually reconfigure Postfix to a chroot configuration, but that is no longer supported by Fedora.
If you are starting from scratch, Postfix is considered a better choice than Sendmail.
Qmail is a direct competitor to Postfix but is not provided with Fedora. Postfix is designed to be easier to use than Sendmail, as well as faster and more secure. However, Qmail isn’t a drop-in replacement for Sendmail, so migrating an existing Sendmail installation to Qmail is not quite as simple as migrating from Sendmail to Postfix. Qmail is relatively easy to administer, and it integrates with a number of software add-ons, including web mail systems and POP3 servers. Qmail is available from http://www.qmail.org/.
Exim is yet another MTA, and it is available at http://www.exim.org/. Exim is considered faster and more secure than Sendmail or Postfix, but is much different to configure than either of those. Exim and Qmail use the maildir format rather than mbox, so both are considered “NFS safe” (see the following sidebar).
Other MTAs are available for use with Fedora, but those discussed in the preceding sections are the most popular. Which one should you choose? That depends on what you need to do. Sendmail’s main strengths are that it is considered the standard and it can do things that many other MTAs cannot. However, if ease of use or speed is a concern to you, you might want to consider replacing Sendmail with Postfix, Exim, or Qmail. Because Sendmail is the default MTA included with Fedora, it is covered in more detail in the following section.
SMTP is a server-to-server protocol that was designed to deliver mail to systems that are always connected to the Internet. Dial-up systems connect only at the user’s command; they connect for specific operations, and are frequently disconnected. To accommodate this difference, many mail systems also include a mail delivery agent, or MDA. The MDA transfers mail to systems without permanent Internet connections. An MDA is similar to an MTA (see the following note), but does not handle deliveries between systems and does not provide an interface to the user.
Note
Procmail and Spamassassin are examples of MTAs; both provide filtering services to the MTA while they store messages locally and then make them available to the MUA or email client for reading by the user.
The MDA uses the POP3 or IMAP protocols for this process. In a manner similar to a post office box at the post office, POP3 and IMAP implement a “store and forward” process that alleviates the need to maintain a local mail server if all you want to do is read your mail. For example, dial-up Internet users can intermittently connect to their ISP’s mail server to retrieve mail using Fetchmail—the MDA provided by Fedora (see the section “Using Fetchmail to Retrieve Mail,” later in this chapter).
The mail user agent, or MUA, is another necessary part of the email system. The MUA is a mail client, or mail reader, that allows the user to read and compose email and provides the user interface. (It is the email application itself that most users are familiar with as “email.”) Some popular UNIX command-line MUAs are elm, pine, and mutt. Fedora also provides modern GUI MUAs: Evolution, Thunderbird, Mozilla Mail, Balsa, Sylpheed, and KMail. For comparison, common non-UNIX MUAs are Microsoft Outlook, Outlook Express, Pegasus, Eudora, and Netscape Messenger.
The Microsoft Windows and Macintosh MUAs often include some MTA functionality; UNIX does not. For example, Microsoft Outlook can connect to your Internet provider’s mail server to send messages. On the other hand, UNIX MUAs generally rely on an external MTA such as Sendmail. This might seem like a needlessly complicated way to do things, and it is if used to connect a single user to her ISP. For any other situation, however, using an external MTA allows you much greater flexibility because you can use any number of external programs to handle and process your email functions and customize the service. Having the process handled by different applications gives you great control over how you provide email service to users on your network, as well as to individual and SOHO users.
Use Evolution to read and compose mail
Use Sendmail to send your mail
Use
xbiffto notify you when you have new mailUse Fetchmail to retrieve your mail from a remote mail server
Use Procmail to automatically sort your incoming mail based on sender, subject, or many other variables
Use Spamassassin to eliminate the unwanted messages before you read them
Because Sendmail is the Fedora default client (and the mostly widely used client), the following sections provide a brief explanation and examples for configuring and operating your email system. As mentioned earlier, however, Sendmail is an extremely complex program with a very convoluted configuration. As such, this chapter only covers some of the basics. For more information on Sendmail, as well as other MTAs, see the “Reference” section at the end of this chapter.
Sendmail configuration is handled by files in the /etc/mail directory with much of the configuration being handled by the file sendmail.cf. The actual syntax of the configuration file, sendmail.cf, is cryptic (see the following example). In an attempt to make it easier to configure Sendmail, the sendmail.mc file was created. The following example belies that goal, however. The sendmail.mc file must be processed with the m4 macro processor to create the sendmail.cf file; the needs of that processor account for the unusual syntax of the file. You will learn how to use it later, and we will look at a Perl script that automates and simplifies the entire process. First, let us examine some basic configuration you might want to do with Sendmail.
Note
sendmail.cf has some strange syntax because of the requirements of the m4 macro processor. You do not need to understand the details of m4 here, but note the quoting system. The starting quote is a backtick (`), and the ending quote is simply a single quote ('). Also, the dnl sequence means to “delete to new line” and causes anything from the sequence up to and including the newline character to be deleted in the output.
Here’s a look at an excerpt from the sendmail.cf file:
CP.
# "Smart" relay host (may be null)
DS
# operators that cannot be in local usernames (i.e., network indicators)
CO @ % !
# a class with just dot (for identifying canonical names)
C..
# a class with just a left bracket (for identifying domain literals)
C[[
# access_db acceptance class
C{Accept}OK RELAY
C{ResOk}OKR
# Hosts for which relaying is permitted ($=R)
FR-o /etc/mail/relay-domains
And here’s a quote from the sendmail.mc file for comparison:
dnl define(`SMART_HOST',`smtp.your.provider') define(`confDEF_USER_ID',``8:12'')dnl undefine(`UUCP_RELAY')dnl undefine(`BITNET_RELAY')dnl dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl
You can see why the file is described as cryptic.
Complicated email server setup is outside the scope of this book; for more information on this topic, we suggest Sendmail, 3rd Edition by Costales and Allman, a 1,200-page comprehensive tome on Sendmail configuration. However, the following five sections address some commonly used advanced options.
Sometimes you might want to have Sendmail masquerade as a host other than the actual hostname of your system. Such a situation could occur if you have a dial-up connection to the Internet and your ISP handles all your mail for you. In this case, you want Sendmail to masquerade as the domain name of your ISP. For example
MASQUERADE_AS(`samplenet.org')dnl
If you do not have a full-time connection to the Internet, you probably want to have Sendmail send your messages to your ISP’s mail server and let it handle delivery for you. Without a full-time Internet connection, you could find it difficult to deliver messages to some locations (such as some underdeveloped areas of the world where email services are unreliable and sporadic). In those situations, you can configure Sendmail to function as a smart host by passing email on to another sender rather than attempting to deliver the email directly. You can use a line such as the following in the sendmail.mc file to enable a smart host:
define(`SMART_HOST', `smtp.samplenet.org')
This line causes Sendmail to pass any mail it receives to the server smtp.samplenet.org rather than attempt to deliver it directly. Smart hosting will not work for you if your ISP, like many others, blocks any mail relaying. Some ISPs block relaying because it is frequently used to disseminate spam.
As mentioned earlier, Sendmail typically attempts to deliver messages as soon as it receives them, and again at regular intervals after that. If you have only periodic connections to the Internet, as with a dial-up connection, you likely would prefer that Sendmail hold all messages in the queue and attempt to deliver them at specific time intervals or at your prompt. You can configure Sendmail to do so by adding the following line to sendmail.mc:
define(`confDELIVERY_MODE', `d')dnl
This line causes Sendmail to attempt mail delivery only at regularly scheduled queue processing intervals (by default, somewhere between 20 and 30 minutes).
However, this delay time might not be sufficient if you are offline for longer periods of time. In those situations, you can invoke Sendmail with no queue processing time. For example, by default, Sendmail might start with the following command:
# sendmail -bd -q30m
This tells Sendmail that it should process the mail queue (and attempt message delivery) every 30 minutes. You can change 30 to any other number to change the delivery interval. If you want Sendmail to wait for a specific prompt before processing the queue, you can invoke Sendmail with no queue time, like this:
# sendmail -bd -q
This command tells Sendmail to process the queue once when it is started, and again only when you manually direct it to do so. To manually tell Sendmail to process the queue, you can use a command like the following:
# sendmail -q
Tip
If you use networking over a modem, there is a configuration file for pppd called ppp.linkup, which is located in /etc/ppp. Any commands in this file are automatically run each time the PPP daemon is started. You can add the line sendmail -q to this file to have your mail queue automatically processed each time you dial up your Internet connection.
Books are available to explore the depths of Sendmail configuration, but the Sendmail Installation and Operation Guide is the canonical reference. Configuration guidance can also be found through a Google search; many people use Sendmail in many different configurations. Fortunately, Fedora has provided a default Sendmail configuration that works out of the box for a home user as long as your networking is correctly configured and you do not require an ISP-like Sendmail configuration.
After you have made all your changes to sendmail.mc, you have to rebuild the sendmail.cf file. First, back up your old file:
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.old
You must run sendmail.mc through the m4 macro processor in order to generate a useable configuration file. A command, such as the following, is used to do this:
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
This command loads the cf.m4 macro file from /usr/share/sendmail-cf/m4/cf.m4 and then uses it to process the sendmail.mc file. The output, normally sent to STDOUT, is then redirected to the file sendmail.cf, and your new configuration file is ready. You have to restart Sendmail before the changes take effect.
By default, Sendmail does not relay mail that did not originate from the local domain. This means that if a Sendmail installation running at lion.org receives mail intended for cheetah.org, and that mail did not originate from lion.org, the mail will be rejected and will not be relayed. If you want to allow selected domains to relay through you, add an entry for the domain to the file /etc/mail/relay-domains. If the file does not exist, simply create it in your favorite text editor and add a line containing the name of the domain that you want to allow to relay through you. Sendmail has to be restarted for this change to take effect.
Caution
You need a very good reason to relay mail; otherwise, do not do it. Allowing all domains to relay through you makes you a magnet for spammers who want to use your mail server to send spam. This could lead to your site being blacklisted by many other sites, which then will not accept any mail from you or your site’s users—even if the mail is legitimate!
Aliases allow you to have an infinite number of valid recipient addresses on your system, without having to worry about creating accounts or other support files for each address.
For example, most systems have postmaster defined as a valid recipient, yet do not have an actual login account named postmaster. Aliases are configured in the file /etc/aliases. Here is an example of an alias entry:
postmaster: root
This entry forwards any mail received for postmaster to the root user. By default, almost all the aliases listed in the /etc/aliases file forward to root.
Caution
Reading email as root is a security hazard; a malicious email message can exploit an email client and cause it to execute arbitrary code as the user running the client. To avoid this danger, you can forward all of root’s mail to another account and read it from there. You can choose one of two ways for doing this.
You can add an entry to the /etc/mail/aliases file that sends root’s mail to a different account. For example, root: foobar would forward all mail intended for root to the account foobar.
The other way is to create a file named .forward in root’s home directory that contains the address that the mail should forward to.
Anytime you make a change to the /etc/mail/aliases file, you have to rebuild the aliases database before that change takes effect. This is done with
# newaliases
You read earlier in this chapter that you must be careful with mail relaying to avoid becoming a spam magnet. But what do you do if you are having problems with a certain site sending you spam? You can use the /etc/mail/access file to automatically reject mail from certain sites.
You can use several rules in the access file. Table 25.1 gives a list of these rules.
Table 25.1. The Various Possible Options for Access Rules
Option | Action |
|---|---|
| Accepts mail from this site, overriding any rules that would reject mail from this site |
| Allows this domain to relay through the server |
| Rejects mail from this site and sends a canned error message |
| Simply discards any message received from the site |
| Where |
The following is an example of three rules used to control access to a Sendmail account. The first rejects messages from spam.com. The second rejects messages from lamer.com and displays an error message to that site. The third allows mail from the specific host user5.lamer.com, even though there is a rule that rejects mail from the site lamer.com. (For a more personal example of why you would bother to do this, I find that I get a lot of spam from the Hotmail domain, so I would just as soon reject it all. However, my wife uses a Hotmail account for her mail. If I did not allow her mail through, that would be a problem for me.)
spam.com REJECT lamer.com ERROR:"550 Mail from spammers is not accepted at this site." user5.lamer.com OK
Open the /etc/access file, enter the rules of your choice, and then restart Sendmail so that your changes to the access file take effect. That can be done with
# /sbin/service sendmail restart
or any of the other ways we discussed in Chapter 15, “Automating Tasks.”
Sendmail has been the de facto MTA of choice for the Internet for a long time. At one point, it was the power behind 90% of the email traffic across the world, although it has now become largely superseded by worthier programs.
One of the more popular programs that have become available is Postfix, which was developed and is exclusively maintained by Wietse Venema. Designed to be a drop-in replacement for Sendmail, Postfix allows the system administrator to literally replace Sendmail without any detriment to the system.
Postfix was designed from the ground up to retain compatibility with Sendmail but to work in a more efficient fashion. Sendmail is notoriously system intensive when handling either large volumes of mail or large numbers of clients. One command pretty much handles everything, making Sendmail something of a monolith. On the other hand, Postfix works with several individual modules all working together, using modules only when needed.
Postfix is easy to install and configure. The first thing to do is to make a backup of all your Sendmail information that you want to keep just in case. After you have done this, you need to use yum to remove Sendmail and install Postfix.
After Postfix has been successfully installed, you can begin configuring it. The scripts for Postfix are all located in /etc/postfix and include
install.cf—. The script generated when Postfix is installed. This file lists the locations Postfix uses and can be a big help when working with themain.cffile.main.cf—. The principal configuration script for Postfix. Within the remarks at the start of the script, you are advised to change only a couple of options at any time. This is sage advice, given that there are more than 300 possibilities!master.cf—. The throttle control for Postfix. This script allows you to change settings for Postfix that directly affect the speed at which it works. Unless you have a reason to tinker with this file, leave it alone. Trust me: You will know when you need to make changes.postfix-script—. The script used by Postfix as a wrapper. You cannot execute it directly; instead it is called by Postfix itself.
You can keep your original Sendmail aliases file for use with Postfix because it will not make much difference to it.
You will also require the services of system-switch-mail, which can also be installed by using yum.
After system-switch-mail has been successfully installed, switch to a root terminal and type the following:
# system-switch-mail
You are then greeted with a simple text screen asking which MTA you want to use. Select Postfix and simply press Enter. After a few seconds, a new window appears informing you that your MTA has been successfully switched. All you then need to do is ensure that Postfix is enabled in runlevel 5 by checking the service (system-config-services).
Further configuration of Postfix focuses on the main.cf file, which is extensively documented throughout the file using comments.
The beauty of Postfix is that it can be used in any situation from a single home user to a large corporation that has thousands of clients, even up to the ISP level. It can even be linked to MySQL for authentication purposes and virtual hosting.
SMTP is designed to work with systems that have a full-time connection to the Internet. What if you are on a dial-up account? What if you have another system store your email for you and then you log in to pick it up once in awhile? (Most users who are not setting up servers are in this situation.) In this case, you cannot easily receive email using SMTP, and you need to use a protocol, such as POP3 or IMAP, instead.
Note
Remember when we said that some mail clients can include some MTA functionality? Microsoft Outlook and Outlook Express can be configured to use SMTP and, if you use a dial-up connection, offer to start the connection and then use SMTP to send your mail. Therefore, a type of MTA functionality is included in those mail clients.
Unfortunately, many MUAs do not know anything about POP3 or IMAP. To eliminate that problem, you can use a program called Fetchmail to contact mail servers using POP3 or IMAP, download mail off the servers, and then inject those messages into the local MTA just as if they had come from a standard SMTP server. The following sections explain how to install, configure, and use the Fetchmail program.
Similar to other .rpm files, Fetchmail can be installed with the rpm -i command. This command installs all files to their default locations. If, for whatever reason, you need to perform a custom installation, see Chapter 7, “Managing Software,” for more information on changing the default options for rpm.
You can get the latest version of Fetchmail at http://tuxedo.org/~esr/fetchmail. It is available in both source and RPM binary formats. The version of Fedora on the CDs and DVD accompanying this book provides a reasonably current version of Fetchmail and installs useful Fetchmail documentation in the /usr/share/doc/fetchmail directory. That directory includes an FAQ, features list, and Install documentation.
After you have installed Fetchmail, you must create the file .fetchmailrc in your home directory, which provides the configuration for the Fetchmail program.
You can create and subsequently edit the .fetchmailrc file by using any text editor. The configuration file is straightforward and quite easy to create; the following sections explain the manual method for creating and editing the file. The information presented in the following sections does not discuss all the options available in the .fetchmailrc file, but covers the most common ones needed to get a basic Fetchmail installation up and running. You have to use a text editor to create the file to include entries like the ones shown as examples—modified for your personal information, of course. For advanced configuration, see the man page for Fetchmail. The man page is well written and documents all the configuration options in detail.
Caution
The .fetchmailrc file is divided into three different sections: global options, mail server options, and user options. It is very important that these sections appear in the order listed. Do not add options to the wrong section. Putting options in the wrong place is one of the most common problems that new users make with Fetchmail configuration files.
The first section of .fetchmailrc contains the global options. These options affect all the mail servers and user accounts that you list later in the configuration file. Some of these global options can be overridden with local configuration options, as you learn later in this section. Here is an example of the options that might appear in the global section of the .fetchmailrc file:
set daemon 600 set postmaster foobar set logfile ./.fetchmail.log
The first line in this example tells Fetchmail that it should start in daemon mode and check the mail servers for new mail every 600 seconds, or 10 minutes. Daemon mode means that after Fetchmail starts, it moves itself into the background and continues running. Without this line, Fetchmail would check for mail once when it started and would then terminate and never check again.
The second option tells Fetchmail to use the local account foobar as a last resort address. In other words, any email that it receives and cannot deliver to a specified account should be sent to foobar.
The third line tells Fetchmail to log its activity to the file ./.fetchmail.log. Alternatively, you can use the line set syslog—in which case, Fetchmail logs through the syslog facility.
The second section of the .fetchmailrc file contains information on each of the mail servers that should be checked for new mail. Here is an example of what the mail section might look like:
poll mail.samplenet.org proto pop3 no dns
The first line tells Fetchmail that it should check the mail server mail.samplenet.org at each poll interval that was set in the global options section (which was 600 seconds in our example). Alternatively, the first line can begin with skip. If a mail server line begins with skip, it is not polled as the poll interval, but is polled only when it is specifically specified on the Fetchmail command line.
The second line specifies the protocol that should be used when contacting the mail server. In this case, we are using the POP3 protocol. Other legal options are IMAP, APOP, and KPOP. You can also use AUTO here—in which case, Fetchmail attempts to automatically determine the correct protocol to use with the mail server.
The third line tells Fetchmail that it should not attempt to do a DNS lookup. You probably want to include this option if you are running over a dial-up connection.
The third and final section of .fetchmailrc contains information about the user account on the server specified in the previous section. Here is an example:
user foobar pass secretword fetchall flush
The first line, of course, simply specifies the username that is used to log in to the email server, and the second line specifies the password for that user. Many security conscious people cringe at the thought of putting clear-text passwords in a configuration file, and they should if it is group or world-readable. The only protection for this information is to make certain that the file is readable only by the owner; that is, with file permissions of 600.
The third line tells Fetchmail that it should fetch all messages from the server, even if they have already been read.
The fourth line tells Fetchmail that it should delete the messages from the mail server after it has completed downloading them. This is the default, so we would not really have to specify this option. If you wanted to leave the messages on the server after downloading them, use the option no flush.
The configuration options you just inserted configured the entire .fetchmailrc file to look like this:
set daemon 600 set postmaster foobar set logfile ./.fetchmail.log poll mail.samplenet.org proto pop3 no dns user foobar pass secretword fetchall flush
What this file tells Fetchmail to do is
Check the POP3 server
mail.samplenet.orgfor new mail every 600 secondsLog in using the username
foobarand the passwordsecretwordDownload all messages off the server
Delete the messages from the server after it has finished downloading them
Send any mail it receives that cannot be delivered to a local user to the account
foobar
As mentioned earlier, many more options can be included in the .fetchmailrc file than are listed here. However, these options get you up and running with a basic configuration.
For additional flexibility, you can define multiple .fetchmailrc files in order to retrieve mail from different remote mail servers while using the same Linux user account. For example, you can define settings for your most often used account and save them in the default .fetchmailrc file. Mail can then quickly be retrieved like so:
$ fetchmail -a 1 message for bball at mail.myserver.com (1108 octets). reading message 1 of 1 (1108 octets) . flushed
By using Fetchmail’s -f option, you can specify an alternative resource file and then easily retrieve mail from another server like this:
$ fetchmail -f .myothermailrc 2 messages for bball at othermail.otherserver.org (5407 octets). reading message 1 of 2 (3440 octets) ... flushed reading message 2 of 2 (1967 octets) . flushed You have new mail in /var/spool/mail/bball
By using the -d option, along with a time interval (in seconds), you can use Fetchmail in its daemon, or background mode. The command launches as a background process and retrieves mail from a designated remote server at a specified interval. For more advanced options, see the Fetchmail man page, which is very well written and documents all options in detail.
Because of the modular nature of mail handling, it is possible to use multiple applications to process mail and accomplish more than simply deliver it. Getting mail from the storage area and displaying it to the user is the purpose of the mail delivery agent (MDA). MDA functionality can be found in some of the mail clients (MUAs), which can cause some confusion to those still unfamiliar with the concept of UNIX mail. As an example, the Procmail MDA provides filtering based on rulesets; KMail and Evolution, both MUAs, provide filtering, but the MUAs pine, mutt, and Balsa do not. Some MDAs perform simple sorting, and other MDAs are designed to eliminate unwanted emails, such as spam and viruses.
You would choose an MDA based on what you want to do with your mail. We will look at five MDAs that offer functions you might find useful in your particular situation. If you have simple needs (just organizing mail by rules), one of the MUAs that offers filtering might be better for your needs. Fedora provides the Evolution MUA as the default selection (and it contains some MDA functionality as previously noted), so try that first and see whether it meets your needs. If not, investigate one of the following MDAs provided by Fedora.
Unless otherwise noted, all the MDA software is provided with the Fedora discs. Chapter 7 details the general installation of any software.
As a tool for advanced users, the Procmail application acts as a filter for email as it is retrieved from a mail server. It uses rulesets (known as recipes) as it reads each email message. No default configuration is provided; you must manually create a ~/.procmail file for each user, or each user can create her own.
There is no systemwide default configuration file. The creation of the rulesets is not trivial and requires an understanding of the use of regular expressions that is beyond the scope of this chapter. Fedora does provide three examples of the files in /usr/share/doc/procmail/examples, as well as a fully commented example in the /usr/share/doc/procmail directory, which also contains a README and FAQ. Details for the rulesets can be found in the man page for Procmail as well as the man pages for procmailrc, procmailsc, and procmailex, which contain examples of Procmail recipes.
If you have used email for any length of time, you have likely been subjected to spam—unwanted email that is sent to thousands of people at the same time. Fedora provides an MDA named Spamassassin to assist you in reducing and eliminating unwanted emails. Easily integrated with Procmail and Sendmail, it can be configured for both systemwide and individual use. It employs a combination of rulesets and blacklists (Internet domains known to mail spam).
Enabling Spamassassin is simple. You must first have installed and configured Procmail. The README file found in /usr/share/doc/spamassasin provides details on configuring the .procmail file to process mail through Spamassassin. It tags probable spam with a unique header; you can then have Procmail filter the mail in any manner you choose. One interesting use of Spamassasin is to use it to tag email received at special email accounts established solely for the purpose of attracting spam. This information is then shared with the Spamassassin site where these “spam trap”-generated hits help the authors fine-tune the rulesets.
Perhaps you do not want to read your mail in an MUA. If you use your web browser often, it might make sense to read and send your mail via a web interface, such as the one used by Hotmail or Yahoo! mail. Fedora provides Squirrelmail for just that purpose. Squirrelmail is written in the PHP 4 language and supports IMAP and SMTP with all pages rendering in HTML 4.0 without using Java. It supports MIME attachments, as well as an address book and folders for segregating email.
You must configure your web server to work with PHP 4. Detailed installation instructions can be found in /usr/share/doc/squirrelmail/INSTALL. After it is configured, point your web browser to http://www.yourdomain.com/squirellmail/ to read and send email.
Although the currently held belief is that Linux is immune to email viruses targeted at Microsoft Outlook users, it certainly makes no sense for UNIX mail servers to permit infected email to be sent through them. Although Fedora does not provide a virus scanner, one of the more popular of many such scanners is MailScanner, available from http://www.sng.ecs.soton.ac.uk/mailscanner/; a Fedora RPM package is available as well as the source code. It supports Sendmail and Exim, but not Postfix or Qmail. Searching on the terms “virus” and “email” at Freshmeat.net will turn up a surprising list of GPLed virus scanners that might serve your needs.
If you already use Hotmail or another web-based email account, the currently available MUAs are not useful to you: Formal POP3 access to a Hotmail account is not available free of charge. However, Microsoft Outlook Express can access Hotmail at no charge using a special protocol called HTTPMail. How that is done is covered in RFC-2518 as “WebDAV extensions to HTTP/1.1.” No specific solution is provided by Fedora, but the basic tools it provides are adequate when supplemented by some clever Perl programming.
Hotwayd is available from http://sourceforge.net/projects/hotwayd/ and implements this functionality, allowing you to use your favorite mail client to read mail from Hotmail.
A newer Hotmail access tool is Gotmail from http://sourceforge.net/projects/gotmail. It is a Perl script that is easy to configure. There are brief tutorials on configuring it for use with KMail and Evolution at http://www.madpenguin.org/cms/?m=show&id=437.
A similar tool exists for Yahoo! mail. FetchYahoo is available from http://fetchyahoo.twizzler.org/.
After it is implemented, you can use a regular MUA, or mail client, to access your web-based mail. None of them, however, enable you to send mail through Hotmail or Yahoo! mail.
Fedora provides an imap package that installs IMAP and POP daemons (servers) for your system. These servers facilitate receiving mail from a remote site. After it is installed, the documentation is found in /usr/share/doc/imap and the README is brief; Fedora has already done the configuration for you: You need only start the services (see Chapter 15).
Biff and its KDE cousin KOrn are small daemons that monitor your mail folder and notify you when a message has been placed there. It is common to include biff y in the .login or .profile files to automatically start it upon user login if you want to use Biff. KOrn can be started by adding the applet to the KDE taskbar.
Note
Autoresponders automatically generate replies to received messages; they are commonly used to notify others that the recipient is out of the office. Mercifully, Fedora does not include one, but you can find and install an autoresponder at Freshmeat.net. If you subscribe to a mailing list, be aware that automatic responses from your account can be very annoying to others on the list. Please unsubscribe from mail lists before you leave the office with your autoresponder activated.
One of the last areas in which a Microsoft product has yet to be usurped by open source software is a replacement for MS Exchange Server. Many businesses use MS Outlook and MS Exchange Server to access email, as well as to provide calendaring, notes, file sharing, and other collaborative functions. General industry complaints about Exchange Server center around scalability, administration (backup and restore in particular), and licensing fees.
A drop-in alternative needs to have compatibility with MS Outlook because it’s intended to replace Exchange Server in an environment in which there are Microsoft desktops in existence using Outlook. A work-alike alternative provides similar features to Exchange Server, but does not offer compatibility with the MS Outlook client itself; the latter is typical of many of the open source alternatives.
There are several drop-in alternatives, none of which is fully open source because some type of proprietary connector is needed to provide the services to MS Outlook clients (or provide Exchange services to the Linux Evolution client). For Outlook compatibility, the key seems to be the realization of a full, open implementation of MAPI, Microsoft’s Messaging Application Program Interface. That goal is going to be difficult to achieve because MAPI is a poorly documented Microsoft protocol. For Linux-only solutions, the missing ingredient for many alternatives is a useable group calendaring/scheduling system similar in function to that provided by Exchange Server/Outlook.
Of course, independent applications for these functions abound in the open source world, but one characteristic of groupware is its central administration; another is that all components can share information.
The following sections examine several of the available servers, beginning with MS Exchange Server itself and moving toward those applications that have increasing incompatibility with it. None of these servers are provided with Fedora.
Exchange Server and Outlook seem to be the industry benchmark because of their widespread deployment. They offer a proprietary server providing email, contacts, scheduling, public folders, task lists, journaling, and notes using MS Outlook as the client and MAPI as the API. If you consider what MS Exchange offers as the full set of features, no other replacement offers 100% of the features exactly as provided by MS Exchange Server—even those considered drop-in replacements. The home page for the Microsoft Exchange server is http://www.microsoft.com/exchange/.
CommuniGate Pro is a proprietary, drop-in alternative to MS Exchange Server, providing, email, webmail, LDAP directories, a web server, file server, contacts, calendaring (third-party), and a list server. The CommuniGate Pro MAPI Connector provides access to the server from MS Outlook and other MAPI-enabled clients. The home page for this server is http://www.stalker.com/.
Oracle Collaboration Suite, or OCS as it is known, is a proprietary application that supports deployment on Linux. It provides a number of services, including email (both POP and IMAP-based), file sharing, calendaring and instant messaging to name but a few. You can find it at http://www.oracle.com/collabsuite/.
The Open Xchange message server is based on Cyrus-imap and Postfix. Most of the server’s groupware features are provided by a proprietary web-based groupware server (ComFire). Open Xchange also uses Apache, OpenLDAP and Samba to provide public directories, notes, webmail, scheduler, tasks, project management, document management, forums, and bookmarks. Some compatibility with MS Outlook is provided. The home page is http://www.open-xchange.org/.
The following references are recommended reading for email configuration. Of course, not all references apply to you. Select the ones that apply to the email server that you are using.
http://www.sendmail.org/—This is the Sendmail home page. Here you can find configuration information and FAQs regarding the Sendmail MTA.
http://www.postfix.org/—This is the Postfix home page. If you are using the Postfix MTA, documentation and sample configurations can be found at this site.
http://www.qmail.org/—This is the home page for the Qmail MTA. It contains documentation and links to other resources on Qmail.
http://www.linuxgazette.com/issue35/jao.html—IMAP on Linux: A Practical Guide. The Internet Mail Access Protocol allows a user to access his email stored on a remote server rather than a local disk.
http://www.redhat.com/support/resources/faqa/RH-postfix-FAQ/book1.html—A slightly out-of-date but still very useful HOWTO about setting up Postfix in a Red Hat environment.
http://www.imap.org/about/whatisIMAP.html—A page describing what IMAP is.
http://www.rfc-editor.org/—A repository of RFCs—Request for Comments—that define the technical “rules” of modern computer usage.
http://www.procmail.org/—The Procmail homepage.
http://www.moongroup.com/docs/procmail/—The Procmail FAQ, which includes suggestions for troubleshooting problems. The page also references a page of links that, in turn, reference other link collections as well as tidbits from the Procmail mail list.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Qmail-VMailMgr-Courier-imap-HOWTO.html—If you want some help configuring a mail system based on the lesser-used applications, this HOWTO can help.
Sendmail from O’Reilly Publishing. This is the de facto standard guide for everything Sendmail. It is loaded with more than 1,000 pages, which gives you an idea of how complicated Sendmail really is.
Postfix from Sams Publishing. An excellent book that covers the Postfix MTA.
Running Qmail from Sams Publishing. This is similar to the Postfix book from Sams Publishing except that it covers the Qmail MTA.