diff options
Diffstat (limited to 'fetchmail-FAQ.html')
| -rw-r--r-- | fetchmail-FAQ.html | 830 |
1 files changed, 830 insertions, 0 deletions
diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html new file mode 100644 index 00000000..374abbd7 --- /dev/null +++ b/fetchmail-FAQ.html @@ -0,0 +1,830 @@ +<!doctype HTML public "-//W3O//DTD W3 HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>The Fetchmail FAQ</TITLE> +<link rev=made href=mailto:esr@snark.thyrsus.com> +<meta name="description" content="Frequently asked questions about fetchmail."> +<meta name="keywords" content="fetchmail, POP, IMAP, remote mail"> +</HEAD> +<BODY> +<H1>Frequently Asked Questions About Fetchmail</H1> + +$Id: fetchmail-FAQ.html,v 1.1 1997/04/16 20:05:46 esr Exp $<p> + +(Add a link to Chris Cheyney's <em>atexit</em> patch.)<p> + +Before reporting any bug, please read <a href="#G3">G3</a> for advice +on how to include diagnostic information that will get your bug fixed +as quickly as possible. +<p> +If you have a question or answer you think ought to be added to this FAQ list, +mail it to fetchmail's maintainer, Eric S. Raymond, at +<A HREF="mailto:esr@thyrsus.com">esr@snark.thyrsus.com</A>. +<p> +There is a fetchmail-friends reflector for people who want to discuss fixes +and improvements in fetchmail. It's at +<a href="mail:fetchmail-friends@thyrsus.com">fetchmail-friends@thyrsus.com</a>; +Eric +can put you on it. +<p> +<h1>General questions:</h1> + +<a href="#G1">G1. What is fetchmail and why should I bother?</a><br> +<a href="#G2">G2. Where do I find the latest FAQ and fetchmail sources?</a><br> +<a href="#G3">G3. I think I've found a bug. Will you fix it?</a><br> +<a href="#G4">G4. I have this idea for a neat feature. Will you add it?</a><br> + +<h1>Build-time problems:</h1> + +<a href="#B1">B1. My C compiler libraries don't seem to have atexit(3).</a><br> +<a href="#B2">B2. Building fetchmail fails with compiler errors in error.c.</a><br> + +<h1>Fetchmail configuration file grammar questions:</h1> + +<a href="#F1">F1. Why does my .fetchmailrc from 2.8 or earlier no longer work?</a><br> +<a href="#F2">F2. The .fetchmailrc parser won't accept my all-numeric user name.</a><br> +<a href="#F3">F3. What does "Warning: user entry with no `user' keyword" mean?</a><br> +<a href="#F4">F4. I'm migrating from popclient. How do I need to modify my .poprc?</a><br> + +<h1>Configuration questions:</h1> + +<a href="#C1">C1. Why do I need a .fetchmailrc when running as root on my own machine?</a><br> +<a href="#C2">C2. How can I arrange for a fetchmail daemon to get killed when I log out?</a><br> +<a href="#C3">C3. How do I know what interface and address to use with --interface?</a><br> +<a href="#C4">C4. How can I get fetchmail to work with ssh?</a><br> +<a href="#C5">C5. How can I set up support for sendmail's anti-spam 571 response?</a><br> + +<h1>Runtime fatal errors:</h1> + +<a href="#R1">R1. I think I've set up fetchmail correctly, but I'm not getting any mail.</a><br> +<a href="#R2">R2. Fetchmail isn't working, and -v shows `SMTP connect failed' messages.</a><br> +<a href="#R3">R3. When I try to configure an MDA, fetchmail doesn't work.</a><br> +<a href="#R4">R4. Fetchmail dumps core in -V mode, but operates normally otherwise.</a><br> +<a href="#R5">R5. Fetchmail dumps core when I use a .netrc file but works otherwise.</a><br> +<a href="#R6">R6. Mail that was being fetched when I interrupted my fetchmail seems to have been vanished.</a></br> + +<h1>Multidrop-mode problems:</h1> + +<a href="#M1">M1. I've declared local names, but all my multidrop mail is going to root anyway.</a><br> +<a href="#M2">M2. I can't seem to get fetchmail to route to a local domain properly.</a><br> +<a href="#M3">M3. I tried to run a mailing list using multidrop, and I have a mail loop!</a><br> +<a href="#M4">M4. My multidrop fetchmail seems to be having DNS problems.</a><br> +<a href="#M5">M5. I'm seeing long DNS delays before each message is processed.</a><br> + +<h1>Mangled mail:</h1> + +<a href="#X1">X1. Why is fetched mail being logged with my name, not the real From address?</a><br> +<a href="#X2">X2. Spurious blank lines are appearing in the headers of fetched mail.</a><br> +<a href="#X3">X3. My mail client can't see a Subject line.</a><br> +<a href="#X4">X4. Messages containing "From" at start of line are being split.</a><br> + +<h1>Answers:</h1> +<hr> +<h2><a name="G1">G1. What is fetchmail and why should I bother?</a></h2> + +Fetchmail is a one-stop solution to the remote mail retrieval problem +for Unix machines, quite useful to anyone with an intermittent PPP or +SLIP connection to a remote mailserver. It can collect mail using any +variant of POP or IMAP and forwards via port 25 to the local SMTP +listener, enabling all the normal forwarding/filtering/aliasing +mechanisms that would apply to local mail or mail arriving via a +full-time TCP/IP connection.<p> + +Fetchmail is not a toy or a coder's learning exercise, but an +industrial-strength tool capable of transparently handling every +retrieval demand from those of a simple single-user ISP connection up +to mail retrieval and rerouting for an entire client domain. +Fetchmail is easy to configure, unobtrusive in operation, powerful, +feature-rich, and well documented. Extensive testing by a large, +multi-platform user community has shown that it is as near bulletproof +as the underlying protocols permit.<p> + +If you found this FAQ in the distribution, see the README for fetchmail's +full feature list.<p> + +<hr> +<h2><a name="G2">G2. Where do I find the latest FAQ and fetchmail +sources?</a></h2> + +The latest HTML faq is available alongside the latest fetchmail +sources at Eric S. Raymond's free software page: +<a href="http://www.ccil.org/~esr/esr-freeware.html"> +http://www.ccil.org/~esr/esr-freeware.html</a>. You can also find +both in the <a +href="http://sunsite.unc.edu/pub/Linux/system/mail/pop/!INDEX.html">POP +mail tools directory on Sunsite</a>.<p> + +A text dump of this FAQ is included in the fetchmail +distribution. Because it freezes at distribution release time, it may +not be completely current.<p> + +<hr> +<h2><a name="G3">G3. I think I've found a bug. Will you fix it?</a></h2> + +Yes I will, provided you include enough diagnostic information for me +to go on. When reporting bugs, please include the following: + +<ol> +<li>Your operating system and compiler version. +<li>The release and patch level of the fetchmail you are running. You can see + your patchlevel by typing `fetchmail -V'. +<li>The output of fetchmail -V (this will not reveal your password). +<li>Any command-line options you used. +</ol> + +It is helpful if you include your .fetchmailrc, but not necessary +unless your symptom seems to involve an error in configuration parsing.<p> + +A transcript of the failed session with -v on is almost always useful. +If the bug involves a core dump or hang, a gdb stack trace is good to have. +(Bear in mind that you can attach gdb to a running but hung process by +giving the process ID as a second argument.)<p> + +Best of all is a mail file which, when fetched, will reproduce the bug.<p> + +<hr> +<h2><a name="G4">G4. I have this idea for a neat feature. Will you add it?</a></h2> + +Probably not. Most of the feature suggestions I get are for ways to +set various kinds of administrative policy or add more spam filtering +(the most common one, which I used to get about four million times a week +and got <em>really</em> tired of, is for tin-like kill files).<p> + +You can do spam filtering better with procmail or mailagent on the +server side and (if you're the server sysadmin) sendmail.cf domain +exclusions. You can do other policy things better with the +<tt>mda</tt> 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.<p> + +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 many things badly. +One of my objectives is to keep fetchmail simple so it stays reliable.<p> + +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.<p> + +<hr> +<h2><a name="B1">B1. My C compiler libraries don't seem to have atexit(3).</a></h2> + +Your compiler libraries are deficient (this has been reported from a +bunch of older Solaris and SCO boxes). The <em>atexit(3)</em> +function is part of the ANSI C standard and should be there.<p> + +You may be able to find a linkable object for <em>atexit(3)</em> in your C++ +library. If not, I recommend installing the GNU C library and/or GCC +itself. You can find a copy of the GNU C library (which is fully +ANSI-compliant and supplies ANSI-compliant headers as well) at <a +href="ftp://prep.ai.mit.edu/pub/gnu/glibc-1.09.1.tar.gz">ftp://prep.ai.mit.edu/pub/gnu/glibc-1.09.1.tar.gz</a><p> + +If you are a SunOS user and cannot install glibc, Chris Cheyney <<A +HREF="mailto:cheyney@netcom.com">cheyney@netcom.com</A>> has +developed a <A +HREF="http://www.cjnetworks.com/~cheyney/me/atexit.html"> patch</A> +that adds <em>atexit</em> to the fetchmail code itself. <p> + +<hr> +<h2><a name="B2">B2. Building fetchmail fails with compiler errors in error.c</a></h2> + +We've had reports of this from under SunOS, Solaris 2.5, HP-UX and +NEXTSTEP 3.3. All but the HP-UX problem seems to have abated after +3.8. You may have to turn off HAVE_VSYSLOG manually.<p> + +<hr> +<h2><a name="F1">F1. Why does my .fetchmailrc from 2.8 or earlier no longer work?</a></h2> + +The `<tt>interface</tt>', `<tt>monitor</tt>' and +`<tt>batchlimit</tt>' options have changed.<p> + +They used to be global options with `set' syntax like the batchlimit +and logfile options. Now they're per-server options, like `protocol'.<p> + +If you had something like<p> + +<pre> + set interface = "sl0/10.0.2.15" +</pre> + +in your .fetchmailrc file, simply delete that line and insert +`interface sl0/10.0.2.15' in the server options part of your `defaults' +declaration.<p> + +Do similarly for any `<tt>monitor</tt>' or `<tt>batchlimit</tt>' options.<p> + +<hr> +<h2><a name="F2">F2. The .fetchmailrc parser won't accept my all-numeric user name.</a></h2> + +So put string quotes around it. :-)<p> + +The configuration file parser treats any all-numeric token as a +number, which will confuse it when it's expecting a name. String +quoting forces the token's class.<p> + +<hr> +<h2><a name="F3">F3. What does "Warning: user entry with no `user' keyword" mean?</a></h2> + +This warning means that you're using a .fetchmailrc that's +written in the old popclient syntax without an explicit `username' +keyword leading the first user entry attached to a server entry.<p> + +This can be triggered by having a user option such as `<tt>keep</tt>' +or `<tt>fetchall</tt>' before the first explicit username. For +example, if you write<p> + +<pre> +poll openmail protocol pop3 + keep user "Hal DeVore" there is hdevore here +</pre> + +the `<tt>keep</tt>' option will generate an entire user entry with the default +username (the name of fetchmail's invoking user).<p> + +The popclient compatibility syntax is deprecated and may be removed in +a future version. (It complicates the configuration file grammar and +confuses users.)<p> + +<hr> +<h2><a name="F4">F4. I'm migrating from popclient. How do I need to modify my .poprc?</a></h2> + +If you have been using popclient (the ancestor of this program) +at version 3.0b6 or later, start with this<p> + +<pre> +(cd ~; mv ~/.poprc ~/.fetchmailrc) +</pre> + +in order to migrate. Be aware that some of popclient's unnecessary +options have been removed (see the NOTES file in the distribution for +explanation). You can't deliver to a local mail file anymore or to +standard output any more, and using an MDA for delivery is +discouraged. If you throw those options away, fetchmail will now +forward your mail into your system's normal Internet-mail delivery +path.<p> + +Actually, using an MDA is now almost always the wrong thing; the MDA +facility has been retained only for people who can't or won't run a +sendmail-like SMTP listener on port 25. The default, SMTP forwarding +to port 25, is better for at least two major reasons. One: it feeds +retrieved POP and IMAP mail into your system's normal delivery path +along with local mail and normal Internet mail, so all your normal +filtering/aliasing/forwarding setup for local mail works. Two: +because the port 25 listener returns a positive acknowledge, fetchmail +can be sure you're not going to lose mail to a disk-full or some other +resource-exhaustion problem.<p> + +If you used to use <tt>-mda "procmail -d</tt> +<em><you></em><tt>"</tt> or something similar, forward to port +25 and do "<tt>| procmail -d</tt> <em><you></em><tt>"</tt> in +your ~/.forward file.<p> + +As long as your new .fetchmailrc file does not use the removed +`localfolder' option or `<tt>limit</tt>' (which now takes a maximum byte size +rather than a line count), a straight move or copy of your .poprc will +often work. (The new run control file syntax also has to be a little +stricter about the order of options than the old, in order to support +multiple user descriptions per server; thus you may have to rearrange +things a bit.)<p> + +Run control files in the minimal .poprc format (without the `username' +token) will trigger a warning. To eliminate this warning, add the +`<tt>username</tt>' keyword before your first user entry per server (it is +already required before second and subsequent user entries per server.<p> + +In some future version the `<tt>username</tt>' keyword will be required.<p> + +<hr> +<h2><a name="C1">C1. Why do I need a .fetchmailrc when running as root on my own machine?</a></h2> + +Ian T. Zimmerman <itz@rahul.net> asked:<p> + +On the machine where I'm the only real user, I run fetchmail as root +from a cron job, like this:<p> + +<pre> + fetchmail -u "itz" -p POP3 -s bolero.rahul.net +</pre> + +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:<p> + +<pre> + skip bolero.rahul.net proto POP3 + user itz is itz +</pre> + +It won't work if the second line is just "<tt>user itz</tt>". This is silly.<p> + +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.<p> + +Answer:<p> + +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.<p> + +"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.<p> + +One: it's not always possible. Suppose you have an SMTP host declared +that's not the machine fetchmail is running on? You lose.<p> + +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.).<p> + +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.<p> + +<hr> +<h2><a name="C2">C2. How can I arrange for a fetchmail daemon to get killed when I log out?</a></h2> + +Fetchmail versions before 2.3 actually used SIGHUP as a wakeup signal. +Newer versions use SIGUSR1 for wakeup (and SIGHUP only in +background-daemon mode) in order to avoid any potential confusion +about logout-time behavior. The right way to dispatch fetchmail on +logout is to arrange for the command `fetchmail -q' to be called on +logout.<p> + +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.<p> + +<hr> +<h2><a name="C3">C3. How do I know what interface and address to use with --interface?</a></h2> + +This depends a lot on your local networking configuration (and right +now you can't use it at all except under Linux). However, here are +some important rules of thumb that can help. If they don't work, ask +your local sysop or your Internet provider.<p> + +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.<p> + +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.<p> + +To determine the device:<p> + +<ol> +<li> If you're using a SLIP link, the correct device is probably sl0. +<li> If you're using a PPP link, the correct device is probably ppp0. +<li> 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. +</ol> + +To determine the address and netmask:<p> + +<ol> +<li> 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.) + +<li> 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. + +<li> 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. +</ol> + +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<p> + +<pre> + interface "sl0/205.164.136.0/255.255.255.0" +</pre> + +would work. To range over any value of the last two octets +(65536 addresses) you would use<p> + +<pre> + interface "sl0/205.164.0.0/255.255.0.0" +</pre> + +<hr> +<h2><a name="C4">C4. How can I get fetchmail to work with ssh?</a></h2> + +This is a lightly edited version of a recipe from Masafumi NAKANE.<p> + +1. You must have ssh (the ssh client) on the local host and sshd (ssh +server) on the remote mail server. And, you have to configure ssh so +you can login to the sshd server host without a password. (Refer to ssh +man page for several authentication methods.)<p> + +2. Add something like following to your .fetchmailrc file: <p> + +<pre> +poll localhost port 1234 with pop3: + preconnect "ssh -f -L 1234:mailhost:110 mailhost sleep 20 </dev/null >/dev/null"; +</pre> + +(Note that 1234 can be an arbitrary port number. Privileged ports can +be specified only by root.) The effect of this ssh command is to +forward connections made to localhost port 1234 (in above example) to +mailhost's 110.<p> + +This configuration will enable secure mail transfer. All the +conversation between fetchmail and remote pop server will be +encrypted.<p> + +If sshd is not running on the remote mail server, you can specify +intermediate host running it. If you do this, however, communication +between the machine running sshd and the POP server will not be encrypted. +And the preconnect line would be like this:<p> + +<pre> +preconnect "ssh -f -L 1234:mailhost:110 sshdhost sleep 20 </dev/null >/dev/null" +</pre> + +You can work this trick with IMAP too, but the port number 110 in the +above would need to become 143.<p> + +<hr> +<h2><a name="C5">C5. How can I set up support for sendmail's anti-spam 571 response?</a></h2> + +Rachel Polanskis <r.polanskis@nepean.uws.edu.au> writes:<p> + +Basically you need to use the "check_*" rules in sendmail. +These are rules introduced since version 8.8.2<p> + +The idea is to generate a list of domains and addresses that are placed into +a file - I call mine "sendmail.rej" and you place just one domain +or email address on each line. During the SMTP transaction, this file +is checked and if there is a match, the message is refused, with +a suitable "Service not available" message sent back to the sender.<p> + +With the feature enabled in fetchmail, the mail is simply deleted, +with no further processing.<p> + +The only drawback when blocking spam with fetchmail is that you +do not get the satisfaction of sending an error back to the sender.<p> + +To actually use the check_mail rules in sendmail 8.8.2 or better, +you need to know how to generate a sendmail.cf file from the m4 +config files distributed with sendmail.<p> + +The actual rules can be found at the following URLS:<p> + +<a href="http://www.informatik.uni-kiel.de/%7Eca/email/check.html"> +http://www.informatik.uni-kiel.de/%7Eca/email/check.html</a><p> + +This one is by Claus Aßman, who has documented more of sendmail then +I can digest! + +The actual setup I used though was by David Begley, who has put together +a WWW page describing how to quickly implement these rules yourself.<p> + +<a href="http://www.nepean.uws.edu.au/users/david/pe/blockmail.html"> +http://www.nepean.uws.edu.au/users/david/pe/blockmail.html</a><p> + +David's pages could be moving shortly. I will post an update if it happens.<p> + +Remember, when copying these rulesets off the web, that there are tabs +embedded in them, that may not be preserved. You <em>must</em> reintroduce +these tabs into the rules to make them work properly. <p> + +Once you have your ruleset in place, and have generated a nice sendmail.cf +file, and the list of blocked sites, try telneting to your +SMTP port to test it, and send a message with a blocked address in it.<p> + +You should see a message similar to:<p> + +<pre> + "571 unsolicited email is refused" +</pre> + +Next, if you have access to a host that you can send mail from, that +is <em>not</em> your mail host, add that host to your spamlist and +restart sendmail.<p> + +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.<p> + +Under no circumstances put your <strong>mailhost</strong> or <strong>any host +you accept mail from</strong> using fetchmail into your reject file. You +<strong>will</strong> lose mail if you do this!!!<p> + +The check_ rules work, and they work well. Coupled with fetchmail's +ability to respond to the appropriate error messages, you can be assured +of never seeing a spam from any address you put in the reject list.<p> + +The only thing that is missing, as mentioned previously, is the ability +to allow sendmail to process the message further and generate an error +message to the sender. <p> + +<hr> +<h2><a name="">R1. I think I've set up fetchmail correctly, but I'm not getting any mail.</a></h2> + +Maybe you have a .forward or alias set up that you've forgotten about. You +should probably remove it.<p> + +Or maybe you're trying to run fetchmail in multidrop mode as root +without a .fetchmailrc file. This doesn't do what you think it +should; see question <a href="#C1">C1</a>.<p> + +Or you may not be connecting to the SMTP listener. Run fetchmail -v +and see the next question.<p> + +<hr> +<h2>R2. Fetchmail isn't working, and -v shows `SMTP connect failed' messages.</a></h2> + +Fetchmail is working, but your SMTP port 25 listener is down or inaccessible. +The first thing to check is if you can telnet to port 25 and get a greeting +line from the listener. If the listener is down, bring it back up.<p> + +If the listener seems to be up when you test with telnet, it could +have had a momentary problem due to resource exhaustion (process table +full or some other problem that stopped the listener process from +forking). If your SMTP host is not `localhost' or something else in +/etc/hosts, the glitch could also have been caused by transient +nameserver failure, or the SMTP host's actually being down.<p> + +If the listener tests up, you can usually ignore the glitch (except as +a symptom of other problems) because a future fetchmail run will get +the mail through. If this is a recurring or constant failure mode, +OTOH, you may have more serious problems in your network layer which I +can't diagnose in this FAQ.<p> + +One way to work around chronic SMTP connect problems is to use --mda. +But this only attacks the symptom. You should really try to figure +out what's going on underneath before it bites you some other way. <p> + +We have one report from a Linux user of 2.1 who solved his SMTP +connection 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.<p> + +As of 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 particular cause should go away.<p> + +<hr> +<h2><a name="R3">R3. When I try to configure an MDA, fetchmail doesn't work.</a></h2> + +(I hear this one from people who have run into the blank-line problem in <a href="#X2">X2</a>.)<p> + +Try sending yourself test mail and retrieving it using the +command-line options `<tt>-k -m cat</tt>'. This will dump exactly what +fetchmail retrieves to standard output. <p> + +If the dump doesn't match what shows up in your mailbox when you +configure an MDA, your MDA is mangling the message. If it doesn't +match what you sent, then fetchmail or something on the server is +broken.<p> + +<hr> +<h2><a name="R4">R4. Fetchmail dumps core in -V mode, but operates normally otherwise.</a></h2> + +We've had this reported to us under Linux using libc-5.4.17 and gcc-2.7.2. +It does not occur with libc-5.3.12 or earlier versions.<p> + +Workaround: link with GNU malloc rather than the stock C library malloc.<p> + +We're told there is some problem with the malloc() code in that +version which makes it fragile in the presence of multiple free() +calls on the same pointer (the malloc arena gets corrupted). +Unfortunately it appears from doing gdb traces that whatever free() +calls producing the problem are being made by the C library itself, not the +fetchmail code (they're all from within fclose, and not an fclose called +by fetchmail, either).<p> + +<hr> +<h2><a name="R5">R5. Fetchmail dumps core when I use a .netrc file but works otherwise.</a></h2> + +We have a report that under Solaris 2.5, if fetchmail is compiled with -O2 +or -O3, it segfaults on startup when reading a .netrc.<p> + +You can work around this by dropping back to -O.<p> + +There may be an actual bug here that the optimizer exposes; the stack +trace says the segfault is in free() and has all the earmarks of a heap- +corruption screw. But the symptom doesn't reproduce under Linux with the +same .fetchmailrc and .netrc.<p> + +<hr> +<h2><a name="R6">R6. Mail that was being fetched when I interrupted my fetchmail seems to have been vanished.</a></h2> + +Fetchmail only sends a delete mail request to the server when either +(a) it gets a positive delivery acknowledgement from the SMTP +listener, or (b) it gets an error 571 (the spam-filter error) from the +listener. No interrupt can cause it to lose mail.<p> + +However, POP3 has a design problem in that its servers mark a message +`seen' as soon as the fetch command to get it is sent down. If for +some reason the message isn't actually delivered (you take a line hit +during the download, or your port 25 listener can't find enough free +disk space, or you interrupt the delivery in mid-message) that `seen' +message can lurk invisibly in your server mailbox forever.<p> + +Workaround: add the `<tt>fetchall</tt>' keyword to your POP3 fetch options.<p> + +Solution: switch to an IMAP server.<p> + +<hr> +<h2><a name="M1">M1. I've declared local names, but all my multidrop +mail is going to root anyway.</a></h2> + +Somehow your fetchmail is never matching the hostname part of +recipient names to the name of the mailserver machine. This probably +means it is unable to recognize hostname parts as being DNS names of +the mailserver, and may indicate some kind of DNS configuration +problem either on the server or your client machine. <p> + +The easiest workaround is to write 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 server that you don't have listed). <p> + +<hr> +<h2><a name="M2">M2. I can't seem to get fetchmail to route to a local domain properly.</a></h2> + +A lot of people want to use fetchmail as a poor man's internetwork +mail gateway, picking up mail accumulated for a whole domain in a single +server mailbox and then routing based on what's in the To/Cc/Bcc lines.<p> + +This is one of the things multidrop mode is for (though you +<em>are</em> 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 +`<tt>localdomains</tt>' option.<p> + +In general, if you use localdomains you need to make sure of two other +things: <p> + +<strong>1. You've actually set up your .fetchmailrc entry to invoke multidrop mode.</strong><p> + +Many people set a `<tt>localdomains</tt>' list and then forget that fetchmail +wants to see more than one name (or the wildcard `*') in a `<tt>here</tt>' list +before it will do multidrop routing.<p> + +<strong>2. You may have to set `no envelope'.</strong><p> + +Normally, multidrop mode tries to deduce an envelope address from a message +before parsing the To/Cc/Bcc lines (this enables it to avoid losing to mailing +list software that doesn't put a recipient addess in the To lines).<p> + +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 `<tt>no +envelope</tt>' to prevent fetchmail from being bamboozled by this.<p> + +<hr> +<h2><a name="M3">M3. I tried to run a mailing list using multidrop, and I have a mail loop!</a></h2> + +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.<p> + +If you use sendmail, you can check the list expansion with +<tt>sendmail -bv</tt>.<p> + +<hr> +<h2><a name="M4">M4. My multidrop fetchmail seems to be having DNS problems.</a></h2> + +We have one report from a Linux user (not the same one as in <a +href="#R2">R2</a>!) 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.<p> + +As of 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.<p> + +<hr> +<h2><a name="M5">M5. I'm seeing long DNS delays before each message is processed.</a></h2> + +Use the `<tt>aka</tt>' option to pre-declare as many of your +mailserver's DNS names as you can. When an address's host part +matches an aka name, no DNS lookup needs to be done to check it.<p> + +If you're sure you've pre-declared all of your mailserver's DNS dames, +you can use the `<tt>no dns</tt>' option to prevent other hostname +parts from being looked up at all.<p> + +Sometimes delays are unavoidable. Some SMTP listeners try to call DNS +on the From-address hostname as a way of checking that the address is valid.<p> + +<hr> +<h2><a name="X1">X1. Why is fetched mail being logged with my name, not the real From address?</a></h2> + +Because logging is done based on the address indicated by the sending +SMTP's MAIL FROM, and some listeners are picky about that address.<p> + +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. (RFC 1123 +says you shouldn't do this exclusion...)<p> + +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!<p> + +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.<p> + +Versions 2.1 and up try the header From address first and fall back to +the calling-user ID. So if your SMTP listener isn't picky, the log +will look right.<p> + +<hr> +<h2><a name="X2">X2. Spurious blank lines are appearing in the headers of fetched mail.</a></h2> + +What's probably happening is that the POP/IMAP daemon on your +mailserver is inserting a non-RFC822 header (like X-POP3-Rcpt:) and +something in your delivery path (most likely an old version of the +<em>deliver</em> program, which sendmail often calls to do local delivery) is +failing to recognize it as a header.<p> + +This is not fetchmail's problem. The first thing to try is installing +a current version of <em>deliver</em>. If this doesn't work, try to +figure out which other program in your mail path is inserting the +blank line and replace that. If you can't do either of these things, +pick a different MDA (such as procmail) and declare it with the +`<tt>mda</tt>' option.<p> + +<hr> +<h2><a name="X3">X3. My mail client can't see a Subject line.</a></h2> + +First, see <a href="#X2">X2</a>. This is quite probably the same +problem (X-POP3-Rcpt header or something similar being inserted by +the server and choked on by an old version of <em>deliver</em>).<p> + +The O'Reilly sendmail book does warn that IDA sendmail doesn't process +X- headers correctly. If this is your problem, all I can suggest is +replacing IDA sendmail, because it's broken and not RFC822 conformant.<p> + +<hr> +<h2>X4. Messages containing "From" at start of line are being split.</a></h2> + +If you know the messages aren't split in your server mailbox, then this +is a problem with your POP/IMAP server, your client-side SMTP listener or +your local delivery agent. Fetchmail cannot split messages.<p> + +Some POP daemons ignore Content-Length headers and split messages on +From lines. We have one report that the 2.1 version of the BSD popper +program (as distributed on Solaris 2.5 and elsewhere) is broken this way.<p> + +You can test this. Declare an mda of `cat' and send yourself one +piece of mail containing "From" at start of a line. If you see a +split message, your POP/IMAP server is at fault. Upgrade to a more +recent version.<p> + +Sendmail and other SMTP listeners don't split RFC822 messages either. +What's probably happening is either sendmail's local delivery agent or +your mail reader are not quite RFC822-conformant and are breaking +messages on what it thinks are Unix-style From headers. You can +figure out which by looking at your client-side mailbox with vi or +more. If the message is already split in your mailbox, your local +delivery agent is the problem. If it's not, your mailreader is the +problem.<p> + +If you can't replace the offending program, take a look at your +sendmail.cf file. There will likely be a line something like<p> + +<pre> +Mlocal, P=/usr/bin/procmail, F=lsDFMShP, S=10, R=20/40, A=procmail -Y -d $u +</pre> + +describing your local delivery agent. Try inserting the `E' option in the +flags part (the F= string). This will make sendmail turn each dangerous +start-of-line From into a >From, preventing programs further downstream +from acting up.<p> +<HR> +<ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></A></ADDRESS> +</BODY> +</HTML> |