From 7cce928b296853f47c58b03f367ef0834a42b5a9 Mon Sep 17 00:00:00 2001 From: Matthias Andree Date: Thu, 17 Aug 2006 21:38:15 +0000 Subject: Reviewed FAQ sections R7ff, H and D. svn path=/branches/BRANCH_6-3/; revision=4901 --- fetchmail-FAQ.html | 89 ++++++++++++++++++++++-------------------------------- 1 file changed, 36 insertions(+), 53 deletions(-) (limited to 'fetchmail-FAQ.html') diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html index fb9bdc09..6273730c 100644 --- a/fetchmail-FAQ.html +++ b/fetchmail-FAQ.html @@ -180,7 +180,7 @@ an OS upgrade
R8. Fetchmail is timing out after fetching certain messages but before deleting them
R9. Fetchmail is timing out during message fetches
-R10. Fetchmail is dying with SIGPIPE.
+R10. Fetchmail is dying with SIGPIPE.
R11. My server is hanging or emitting errors on CAPA.
R12. Fetchmail isn't working and reports getaddrinfo errors.
@@ -2391,22 +2391,16 @@ fetches

This is probably a general networking issue. Sending a "RETR" command will cause the server to start sending large amounts of data, which means large packets. If your networking layer has a -packet-fragmentation problem, that's where you'll see it.

+packet-fragmentation problem or improper firewall settings break Path +MTU discovery (when for instance all ICMP traffic is blocked), that's +where you'll see it.

-

R10. Fetchmail is dying with -SIGPIPE.

+

R10. Fetchmail is dying with + SIGPIPE.

-

This probably means you have an mda option. Your -MDA is croaking while being passed a message. Best fix is to remove -the mda option and pass mail to your port 25 SMTP -listener.

- -

If for some reason you are invoking sendmail via the -mda option (rather than delivering to port 25 via smtp), -don't forget to include the -i switch. Otherwise you will -occasionally get mysterious delivery failures with a SIGPIPE as the -sendmail instance dies. The problem is messages with a single dot -at start of a text line.

+

Fetchmail 6.3.5 and newer block SIGPIPE, and many older versions have + already handled this signal, so you shouldn't be seeing SIGPIPE +at all.

R11. My server is hanging or emitting errors on CAPA.

@@ -2542,29 +2536,18 @@ dropped connection.

One POP3 daemon used in the Berkeley Unix world that reports itself as POP3 version 1.004 actually throws the queue away. 1.005 fixed that. If you're running this one, upgrade immediately. (It -also truncates long lines at column 1024)

+also truncates long lines at column 1024.)

Many POP servers, if an interruption occurs, will restore the -whole mail queue after about 10 minutes. Others will restore it +whole mail queue after about 10 minutes. Better ones will restore it right away. If you have an interruption and don't see it right away, cross your fingers and wait ten minutes before retrying.

-

Some servers (such as Microsoft's NTMail) are mis-designed to -restore the entire queue, including messages you have deleted. If -you have one of these and it flakes out on you a lot, try setting a -small --fetchlimit value. This will result in more IP -connects to the server, but will mean it actually executes changes -to the queue more often.

- -

Qualcomm's qpopper, used at many BSD Unix sites, is better -behaved. If its connection is dropped, it will first execute all -DELE commands as though you had issued a QUIT (this is a technical -violation of the POP3 RFCs, but a good idea in a world of flaky -phone lines). Then it will re-queue any message that was being -downloaded at hangup time. Still, qpopper may require a noticeable -amount of time to do deletions and clean up its queue. (Fetchmail -waits a bit before retrying in order to avoid a 'lock busy' -error.)

+

Good servers are designed to restore the entire queue, including +messages you have deleted. If you have one of these and it flakes out on +you a lot, try setting a small --fetchlimit value. This +will result in more IP connects to the server, but will mean it actually +executes changes to the queue more often.

D3. Mail that was being fetched when I interrupted my fetchmail seems to have been vanished.

@@ -2586,7 +2569,7 @@ your server mailbox forever.

Workaround: add the 'fetchall' keyword to your fetch options.

-

Solution: switch to an IMAP4 +

Solution: switch to an IMAP4 server.

@@ -2595,26 +2578,21 @@ server.

multidrop mail is going to root anyway.

Somehow your fetchmail is never recognizing the hostname part of -recipient names it parses out of To/Cc/envelope-header lines as -matching the name of the mailserver machine. To check this, run +recipient names it parses out of Envelope-header lines (or these are +improperly configured) as +matching a name within the designated domains. To check this, run fetchmail in foreground with -v -v on. You will probably see a lot of messages with the format "line rejected, %s is not an alias of the mailserver" or "no address matches; forwarding to %s."

-

These errors usually indicate some kind of DNS configuration -problem either on the server or your client machine.

+

These errors usually indicate some kind of configuration +problem.

The easiest workaround is to add a 'via' option (if -necessary) and add enough aka declarations to cover all of your -mailserver's aliases, then say 'no dns'. This will -take DNS out of the picture (though it means mail may be -uncollected if it's sent to an alias of the mailserver that you -don't have listed).

- -

It would be better to fix your DNS, however. DNS problems can -hurt you in lots of ways, for example by making your machines -intermittently or permanently unreachable to the rest of the -net.

+necessary) and add enough 'aka' declarations to cover all +of your mailserver's aliases, then say 'no dns'. This will +take DNS out of the picture (though it means mail may be uncollected if +it's sent to an alias of the mailserver that you don't have listed).

Occasionally these errors indicate the sort of header-parsing problem described in M7.

@@ -2637,8 +2615,11 @@ setting up a UUCP feed.

If neither of these alternatives is available, multidrop mode may do (though you are going to get hurt by some mailing list software; see the caveats under THE USE AND ABUSE OF MULTIDROP -MAILBOXES on the man page). If you want to try it, the way to do it -is with the 'localdomains' option.

+MAILBOXES on the man page, and check what is needed at Matthias + Andree's "Requisites for working multidrop + mailboxes"). If you want to try it, the way to do it is +with the 'localdomains' option.

In general, if you use localdomains you need to make sure of two other things:

@@ -2660,9 +2641,11 @@ recipient address in the To lines).

Some ways of accumulating a whole domain's messages in a single server mailbox mean it all ends up with a single envelope address -that is useless for rerouting purposes. You may have to set +that is useless for rerouting purposes. In this particular case, sell +your ISP a clue. If that does not work, you may have to set 'no envelope' to prevent fetchmail from being -bamboozled by this.

+bamboozled by this, but a missing envelope makes multidrop routing +unreliable.

Check also answer T1 on a reliable way to do multidrop delivery if your ISP (or your mail redirection provider) @@ -2688,7 +2671,7 @@ reference to -lresolv from his link line and relinking. Apparently in some older Linux distributions the libc5 bind library version works better.

-

As of 2.2, the configure script has been hacked so the bind +

As of fetchmail 2.2, the configure script has been hacked so the bind library is linked only if it is actually needed. So under Linux it won't be, and this problem should go away.

-- cgit v1.2.3