Previous Next

Home Up


Configuring fetchmail

Contents

  1. Retrieving new mail from XMission
  2. Waking up sendmail to flush queued-up outgoing mail

Fetchmail is a program designed to retrieve mail from a mail server and inject it into the local mail system. On a RedHat box, sendmail is usually installed and running as the local mail system. Fetchmail simply retrieves your mail from mail.xmission.com via POP3 or IMAP4 and hands it off to sendmail to put into your local mailbox where it can be read using Elm, Pine, Netscape or your favorite mail program.

Retrieving mail from XMission

Configuring fetchmail for most purposes is fairly simple. It's only configuration file is .fetchmailrc in your home directory. This file needs to be readable only by you because it may contain passwords. Once created, just do a chmod go-rw .fetchmailrc to set the permissions right.

For each account and server you want to retrieve mail for, you need one entry in .fetchmailrc. There are two types of entries, distinguished by the first word in them: poll and skip. poll entries are processed every time you run fetchmail with no arguments. skip entries are processed only if you explicitly name them on the command line. The syntax of the entries is fairly simple, although there are quite a few options you can use if you feel like it. One for XMission might look like:

poll xmission-myusername via mail.xmission.com
        protocol imap
        interface ppp0/0.0.0.0/0.0.0.0
        username myusername here is myusername there
        password you-wish
        smtphost localhost
        fetchall
        expunge 5
        pass8bits
        stripcr

This entry is called xmission-myusername, and will retrieve mail from the mail.xmission.com mailserver. In actual use you should substitute your real XMission username for myusername. It uses the IMAP4 protocol, and use an ordinary password to log in to the server. The interface line says to only process this entry if the ppp0 network interface is up. This is useful for dial-in users to prevent attempting to access the server when not actually dialed in. For those with permanent connections, you don't really need this. The username line maps your username on your Linux box to your username on XMission. I would recommend that you use a local username the same as your XMission username, but it's entirely legal to say something like username albert here is tony there so mail would be retrieved for tony@xmission.com via the tony account on XMission and delivered to user albert on the Linux box. The use of here and there should make the correspondence obvious. The password line specifies the password to use to log in to the server, and for XMission should be your usual login password. You can omit this line, and fetchmail will prompt you for the password when needed. The smtphost is the machine fetchmail should hand mail to after retrieving it, in this case the Linux box itself. The remaining lines say, in order, fetch all mail regardless of whether it's been read or not, flush retrieved messages from the server after every 5th message retrieved, pass 8-bit characters through without munging them, and strip out unneeded carriage-return characters at the end of lines. Substitute your username for myusername above, put in your password if you want it or delete the password line if you want to always be prompted for it, and you should be good to go. Dial in to XMission, type fetchmail and watch the messages come in.

You can invoke fetchmail in three ways. The first is just fetchmail. This starts up fetchmail and processes every poll entry in the file. The second is fetchmail entry-names. If you specify an entry name on the command line, fetchmail will process only that entry. You can also specify several entry names, seperated by spaces, and fetchmail will process them and ignore all the others. It does not matter in this case whether the named entries are poll or skip. In fact, one of the main uses for skip entries is for rarely-used or experimental entries that should not be processed except when explicitly asked for in this way. The third way is fetchmail --daemon seconds. In this mode, fetchmail puts itself into the background and process .fetchmailrc every however many seconds you specified on the command line. This is know as daemon mode and is useful for people with permanent connections who want mail retrieved on a regular basis without having to do it by hand. You can also add this line to the top of .fetchmailrc:

set daemon seconds

This will make daemon mode the default. You can override this via --daemon 0 on the command line. When fetchmail is running in daemon mode, fetchmail --quit will cause it to exit. Just running fetchmail from the shell prompt when it's already running in daemon mode will cause it to immediately wake up and begin processing things.

A couple of comments. First, I use the IMAP4 protocol. This is, IMHO, more reliable than the older and more well-known POP3 protocol. If you want you can use POP3 by substituting pop3 for imap in the entry. Both will work, but I've had better luck with IMAP4 when it comes to recovering from errors, dropped connections and the like. Second, the fetchall option says to retrieve all messages regardless of whether they are marked as read or not. If you omit it, fetchmail will skip any messages that XMission's server says have been read already. If you only use fetchmail to retrieve your mail, this shouldn't make any difference. If you use programs like Pine or Netscape to check mail on XMission in addition to using fetchmail, leaving out the fetchall option will make fetchmail skip messages that have been read by the other programs. If you're doing that, you might also want to look into the keep/nokeep options, and decide whether you want mail that's been read kept on the server or deleted from it after fetchmail is done. If you want detailed information, man fetchmail will give you quite a bit including some examples ( once you get that far ). You can also look in the documentation directory /usr/doc/fetchmail-version. What version is may vary, mine is 5.3.1. There are some HTML files there that you can pull up in Netscape that answer a lot of questions.

The smtphost specifies what machine fetchmail will ask to deliver the mail. Normally this should be localhost. When fetchmail retrieves a message from XMission, it will connect to the SMTP port on the machine named in the smtphost entry and tell the mail server there to deliver the mail to the username specified in the here part of the username line. RedHat by default configures sendmail to properly handle this, so you shouldn't need to worry about that portion of things. RedHat also configures procmail as the default program to use to deliver mail, so you can set up a .procmailrc file on your Linux box just like you would on XMission's machines and mail retrieved by fetchmail will go through it. You will not need a .forward file.

Sending your pending mail automatically

You can also use fetchmail to trigger your pending mail. With a properly-configured sendmail setup, if you send mail when you're not connected to XMission sendmail will queue the mail up for delivery later. I have a page on how to properly configure sendmail for this. If you have a permanent connection, or if you dial in and stay connected long enough, the automatic running of the mail queue will pick things up. If you have a dial-up PPP account, though, it would be nice to have the pending mail automatically sent whenever you decide to pick up your incoming mail. You can do this with this .fetchmailrc entry:

poll outbound via localhost
        protocol etrn
        interface ppp0/0.0.0.0/0.0.0.0
        smtphost @

This entry will make fetchmail wake up sendmail on your machine and begin sending any outgoing mail. If you put this just before the xmission-myusername entry given above, fetchmail will process it first and your outgoing mail will go out at the same time that your new mail is coming in.

This poll entry works the way you probably want it to when you run fetchmail by hand: whenever you run fetchmail it will cause outgoing mail to be sent out and new mail to be pulled in. If you run fetchmail in daemon mode, you might want to make this a skip entry so that it won't be triggered every time the daemon runs. Then you can manually trigger outgoing mail by just doing fetchmail outbound whenever you connect to XMission, and let the daemon concentrate on incoming mail. If you have a permanent connection ( DSL or the like ), you don't need fetchmail to trigger outgoing mail and you should simply not use this entry at all.


Previous Next

Home Up


tknarr@silverglass.org