Andrew Hudson - Fedora™ Unleashed, 2008 edition

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 dialup connection.

The third and final section of . fetchmailrccontains 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, is simply just 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 you do not really have to specify this option. If you want to leave the messages on the server after downloading them, use the option no flush.

The configuration options you just inserted configured the entire .fetchmailrcfile 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 seconds.

► Log in using the username foobarand the password secretword.

► Download all messages off the server.

► Delete the messages from the server after Fetchmail has finished downloading them.

► Send any mail Fetchmail receives that cannot be delivered to a local user to the account foobar.

As mentioned earlier, many more options can be included in the . fetchmailrcfile than are listed here. However, these options get you up and running with a basic configuration.

For additional flexibility, you can define multiple . fetchmailrcfiles 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 . fetchmailrcfile. Mail can then quickly be retrieved like so:

$ fetchmail -a

1 message for ahudson at mail.myserver.com (1108 octets).

reading message 1 of 1 (1108 octets) . flushed

By using Fetchmail's -foption, you can specify an alternative resource file and then easily retrieve mail from another server, as follows:

$ 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 -doption, 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 well written and documents all options in detail.

Because the .fetchmailrcfile contains your mail server password, it should be readable only by you. This means that it should be owned by you and should have permissions no greater than 600. Fetchmail complains and refuses to start if the .fetchmailrcfile has permissions greater than this.

Because of the modular nature of mail handling, it is possible to use multiple applications to process mail and accomplish more than simply delivering 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. The following sections 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 34 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 ~/.procmailfile 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/procmaildirectory, which also contains a Read Me 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 Read Me file found in /usr/share/doc/spamassasinprovides details on configuring the .procmailfile 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.