If your provider stores your mail for you until you fetch it, and you do not want to use your mailer to download the mail, you need a program that retrieves the mail from your provider’s computer. There are a lot of programs for doing this; we will discuss fetchmail here briefly because it is both robust and flexible and can handle both POP3 and IMAP.

You can get fetchmail from your friendly Linux archive; chances are that your distribution carries it, too. If you download a source distribution of fetchmail, unpack, build, and install it according to the installation instructions. At the time of this writing, the current version was 6.2.5. The official home page for fetchmail is http://www.catb.org/~esr/fetchmail/.

You can control fetchmail’s behavior via both command-line options and a configuration file. It is a good idea to first try to fetch your mail by passing the necessary information on the command line, and when this works, to write the configuration file.

As an example, let’s assume that my provider is running the POP3 protocol, that my username there is joeuser, and that my password is secret. The hostname of the machine where the POP3 server is running is mail.isp.com. I can then retrieve my mail with the following command:

    fetchmail --protocol POP3 --username joeuser mail.isp.com

fetchmail then asks me for my password and, after I specify it correctly, retrieves the mail waiting for me and passes it on to my MTA for further delivery. This assumes that an SMTP server is running on port 25 of my machine, but this should be the case if I have set up my MTA correctly.

While you are experimenting with fetchmail , it might be a good idea to also specify the option --keep. This prevents fetchmail from deleting the messages from your POP3 account. Normally, all messages are deleted from your provider’s hard disk once they are safely stored on your own machine. This is a good thing because most providers limit the amount of mail you can store on their machines before retrieving them, and if you don’t delete the messages after fetching them, you might reach this limit quite quickly. On the other hand, while testing, it is a good idea to be on the safe side and use --keep so as not to lose any mail.

With the aforementioned options to fetchmail, you should be able to get your mail in most cases. For example, if your provider uses the newer IMAP protocol, simply specify IMAP in the command line instead of POP3. If your provider has some unusual setup, you might need one of the other options that the fetchmail(1) manual page tells you about.

Once you are satisfied with the download process, you can write a fetchmail configuration file in order not to have to enter all the options each time you use the command. This configuration file is called .fetchmailrc and should reside in your home directory. Once you are done editing it, make sure it has the permission value 0600 so that nobody except yourself can read it because this file might contain your password:

          chmod 0600 ~/.fetchmailrc

The full syntax of the configuration file is detailed in the fetchmail manpage, but in general you need only very simple lines that start with poll. To specify the same data as on the command line in the previous example, but this time include the password, put the following line into your configuration file:

          poll mail.isp.com with proto pop3 username joeuser password secret

Now you can run fetchmail without any parameters. Because fetchmail already knows about your password from the configuration file, it will not prompt you for it this time. If you want to play it safe while testing, add the word keep to the poll line.

Using fetchmail with a configuration file has one additional advantage: you can fetch mail from as many mailboxes as you want. Just add more poll lines to your .fetchmailrc file, and fetchmail happily retrieves your mail from one server after the other.

When and how you run fetchmail depends on your connection to the Internet. If you have a permanent connection or a cheap, flat rate, you might want to have fetchmail invoked by cron at a suitable interval (such as once an hour). However, if your Internet connection is nonpermanent (dial-up) and costly, you might want to choose to run fetchmail by hand whenever you actually want to fetch and read your mail so as to minimize your Internet connection time. Finally, if you are using PPP for dialing in to your Internet service provider, you might want to invoke fetchmail from the ip-up script, which is invoked as soon as an Internet connection is made. With this setup, when you browse a web page and your computer dials up your provider, your mail is fetched automatically.

So what happens to your email messages once fetchmail has pulled them from your account? We have said previously that it passes them on to your MTA. Your MTA then usually puts the messages into a so-called local spool file, often /var/spool/mail/<username>. You can then set up your MUA to pull in the messages from this spool file. Each MUA should have such a setting; in KMail, for example, you create a “local receiving account.”