Check the manual page; you'll probably find that by moving one or more options closer to the `poll' keyword you can eliminate the problem.

Yes, I know these ordering restrictions are hard to understand. Unfortunately, they're necessary in order to allow the `defaults' feature to work.


C1. Why do I need a .fetchmailrc when running as root on my own machine?

Ian T. Zimmerman <itz@rahul.net> asked:

On the machine where I'm the only real user, I run fetchmail as root from a cron job, like this:

    fetchmail -u "itz" -p POP3 -s bolero.rahul.net

This used to work as is (with no .fetchmailrc file in root's home directory) with the last version I had (1.7 or 1.8, I don't remember). But with 2.0, it RECPs all mail to the local root user, unless I create a .fetchmailrc in root's home directory containing:

     skip bolero.rahul.net proto POP3
          user itz is itz

It won't work if the second line is just "user itz". This is silly.

It seems fetchmail decides to RECP the `default local user' (i.e. the uid running fetchmail) unless there are local aliases, and the `default' aliases (itz->itz) don't count. They should.

Answer:

No they shouldn't. I thought about this for a while, and I don't much like the conclusion I reached, but it's unavoidable. The problem is that fetchmail has no way to know, in general, that a local user `itz' actually exists.

"Ah!" you say, "Why doesn't it check the password file to see if the remote name matches a local one?" Well, there are two reasons.

One: it's not always possible. Suppose you have an SMTP host declared that's not the machine fetchmail is running on? You lose.

Two: How do you know server itz and SMTP-host itz are the same person? They might not be, and fetchmail shouldn't assume they are unless local-itz can explicitly produce credentials to prove it (that is, the server-itz password in local-itz's .fetchmailrc file.).

Once you start running down possible failure modes and thinking about ways to tinker with the mapping rules, you'll quickly find that all the alternatives to the present default are worse or unacceptably more complicated or both.


C2. How can I arrange for a fetchmail daemon to get killed when I log out?

The easiest way to dispatch fetchmail on logout (which will work reliably only if you have just one login going at any time) is to arrange for the command `fetchmail -q' to be called on logout. Under bash, you can arrange this by putting `fetchmail -q' in the file `~/.bash_logout'. Most csh variants execute `~/.logout' on logout. For other shells, consult your shell manual page.

Automatic startup/shutdown of fetchmail is a little harder to arrange if you may have multiple login sessions going. In the contrib subdirectory of the fetchmail distribution there is some shell code you can add to your .bash_login and .bash_logout profiles that will accomplish this. Thank James Laferriere <babydr@nwrain.net> for it.

Some people start up and shut down fetchmail using the ppp-up and ppp-down scripts of pppd.


C3. How do I know what interface and address to use with --interface?

This depends a lot on your local networking configuration (and right now you can't use it at all except under Linux and the newer BSDs). However, here are some important rules of thumb that can help. If they don't work, ask your local sysop or your Internet provider.

First, you may not need to use --interface at all. If your machine only ever does SLIP or PPP to one provider, it's almost certainly by a point to point modem connection to your provider's local subnet that's pretty secure against snooping (unless someone can tap your phone or the provider's local subnet!). Under these circumstances, specifying an interface address is fairly pointless.

What the option is really for is sites that use more than one provider. Under these circumstances, typically one of your provider IP addresses is your mailserver (reachable fairly securely via the modem and provider's subnet) but the others might ship your packets (including your password) over unknown portions of the general Internet that could be vulnerable to snooping. What you'll use --interface for is to make sure your password only goes over the one secure link.

To determine the device:

  1. If you're using a SLIP link, the correct device is probably sl0.
  2. If you're using a PPP link, the correct device is probably ppp0.
  3. If you're using a direct connection over a local network such as an ethernet, use the command `netstat -r' to look at your routing table. Try to match your mailserver name to a destination entry; if you don't see it in the first column, use the `default' entry. The device name will be in the rightmost column.

To determine the address and netmask:

  1. If you're talking to slirp, the correct address is probably 10.0.2.15, with no netmask specified. (It's possible to configure slirp to present other addresses, but that's the default.)
  2. If you have a static IP address, run `ifconfig <device>', where <device> is whichever one you've determined. Use the IP address given after "inet addr:". That is the IP address for your end of the link, and is what you need. You won't need to specify a netmask.
  3. If you have a dynamic IP address, your connection IP will vary randomly over some given range (that is, some number of the least significant bits change from connection to connection). You need to declare an address with the variable bits zero and a complementary netmask that sets the range.

To illustrate the rule for dynamic IP addresses, let's suppose you're hooked up via SLIP and your IP provider tells you that the dynamic address pool is 255 addresses ranging from 205.164.136.1 to 205.164.136.255. Then

    interface "sl0/205.164.136.0/255.255.255.0"

would work. To range over any value of the last two octets (65536 addresses) you would use

    interface "sl0/205.164.0.0/255.255.0.0"

C4. How can I set up support for sendmail's anti-spam features?

This answer covers versions of sendmail from 8.9.3-20 (the version installed in Red Hat 6.2) upwards. If you have an older version, upgrade to sendmail 8.9.

Stock sendmails can now do anti-spam exclusions based on a database of filter rules. The human-readable form of the database is at /etc/mail/access. The database itself is at /etc/mail/access.db.

The table itself uses email addresses, domain names, and network numbers as keys. For example,

spammer@aol.com         REJECT
cyberspammer.com        REJECT
192.168.212             REJECT

would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), and any host on the 192.168.212.* network. (This feature can be used to do other things as well; see the sendmail documentation for details)

To actually set up the database, run

makemap hash deny <deny

in /etc/mail.

To test, send a message to your mailing address from that host and then pop off the message with fetchmail, using the -v argument. You can monitor the SMTP transaction, and when the FROM address is parsed, if sendmail sees that it is an address in spamlist, fetchmail will flush and delete it.

Under no circumstances put your mailhost or any host you accept mail from using fetchmail into your reject file. You will lose mail if you do this!!!


C5. How can I poll some of my mailboxes more/less often than others?

Use the interval keyword on the ones that should be checked less often. For example, if you do a poll every 5 minutes, and want to poll some mailboxes every 5 minutes and some every 30 minutes, use something like this:

poll mainsite.example.com  proto pop3 user ....
poll secondary.example.com proto pop3 interval 6 user ...

Then secondary.example.com will be polled every 6th time that mainsite.example.com is polled, which with a polling interval of every 5 minutes means that secondary.example.com will be polled every 30 minutes.


Fetchmail works OK