Frequently Asked Questions About Fetchmail 1. I have this idea for a neat feature. Will you add it? 2. Why do I need a .fetchmailrc when running as root on my own machine? 3. Why is fetched mail being logged with my name, not the real From address? 4. I tried to run a mailing list using multidrop, and I have a mail loop! 5. I'm having intermittent SMTP connect errors even though my listener is up. 6. My fetchmail seems to be having DNS problems. ----------------------------------------------------------------------- 1. I have this idea for a neat feature. Will you add it? Probably not. Most of the feature suggestions I get are for ways to set various kinds of administrative policy or add spam filtering (the most common one, which I seem to get about four million times a week and am *really* tired of, is for tin-like kill files). You can do spam filtering better with procmail on the server side and (if you're the server sysadmin) sendmail.cf domain exclusions. You can do other policy things better with the MDA option and script wrappers around fetchmail. If it's a prime-time-vs.-non-prime-time issue, ask yourself whether a wrapper script called from crontab would do the job. I'm not going to do these; fetchmail's job is transport, not policy, and I refuse to change it from doing one thing well to attempting two things badly. One of my objectives is to keep fetchmail simple so it stays reliable. All that said, if you have a feature idea that really is about a transport problem that can't be handled anywhere but fetchmail, lay it on me. I'm very accommodating about good ideas. ----------------------------------------------------------------------- 2. Why do I need a .fetchmailrc when running as root on my own machine? Ian T. Zimmerman 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' (ie. 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. ----------------------------------------------------------------------- 3. Why is fetched mail being logged with my name, not the real From address? Because logging is done based on the address indicated by SMTP MAIL FROM, and some listeners are picky about that address. Some SMTP listeners get upset if you try to hand them a MAIL FROM address naming a different host than the originating site for your connection. This is a feature, not a bug -- it's supposed to help prevent people from forging mail with a bogus origin site. Since the originating site of a fetchmail delivery connection is localhost, this effectively means these picky listeners will barf on any MAIL FROM address fetchmail hands them with an @ in it! In versions up to 1.9.9 this led to pesky errors at some sites. Because of this, I hacked 2.0 to just use the calling user ID as the MAIL FROM address. Versions 2.1 and up try the header From address first and fall back to the calling-user ID. So if your server isn't picky, the log will look right. ----------------------------------------------------------------------- 4. I tried to run a mailing list using multidrop, and I have a mail loop! This isn't fetchmail's fault. Check your mailing list. If the list expansion includes yourself or anybody else at your mailserver (that is, not on the client side) you've created a mail loop. Just chop the host part off any local addresses in the list. If you use sendmail, you can check the list expansion with sendmail -bv. ----------------------------------------------------------------------- 5. I'm having intermittent SMTP connect errors even though my listener is up. We have one report from a Linux user who solved this problem by removing the reference to -lresolv from his link line and relinking. Apparently in some recent Linux distributions the libc bind library version works better. ----------------------------------------------------------------------- 6. My fetchmail seems to be having DNS problems. We have one report from a Linux user (not the same one as in #5!) who solved this problem by removing the reference to -lresolv from his link line and relinking. Again, apparently in some recent Linux distributions the libc bind library version works better. ----------------------------------------------------------------------- If you have a question you think needs to be added to this list, mail it to esr@thyrsus.com.