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.
Ian T. Zimmerman <firstname.lastname@example.org> 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 "
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.
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.
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 <email@example.com> for it.
Some people start up and shut down fetchmail using the ppp-up and ppp-down scripts of pppd.
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:
To determine the address and netmask:
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 220.127.116.11 to 18.104.22.168. Then
would work. To range over any value of the last two octets (65536 addresses) you would use
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,
firstname.lastname@example.org REJECT cyberspammer.com REJECT 192.168.212 REJECT
would refuse mail from email@example.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
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!!!
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.