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 <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' (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.


