ble.

You will notice that if the mail already has a Delivered-To header, sendmail will not add another.  Further, editing sendmail.cf directly is not very comfortable.  Solutions for both problems can be found in Peter `Rattacresh' Backes' `hybrid' patch against sendmail.  Have a look at it, you can find it in the contrib subdirectory.

Feel free to try Martijn Lievaart's detailed recipe in the contrib subdirectory of the fetchmail source distribution, it attempts to realize multidrop mailboxes with an external script.

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.


T2. How can I use fetchmail with qmail?

Turn on the forcecr option; qmail's listener mode doesn't like header or message lines terminated with bare linefeeds.

(This information is thanks to Robert de Bath <robert@mayday.cix.co.uk>.)

If a mailhost is using the qmail package (see http://pobox.com/~djb/qmail.html) then, providing the local hosts are also using qmail, it is possible to set up one fetchmail link to be reliably collect the mail for an entire domain.

One of the basic features of qmail is the `Delivered-To:' message header. Whenever qmail delivers a message to a local mailbox it puts the username and hostname of the envelope recipient on this line. The major reason for this is to prevent mail loops.

To set up qmail to batch mail for a disconnected site the ISP-mailhost will have normally put that site in its `virtualhosts' control file so it will add a prefix to all mail addresses for this site. This results in mail sent to 'username@userhost.userdom.dom.com' having a 'Delivered-To:' line of the form:

       Delivered-To: mbox-userstr-username@userhost.userdom.dom.com

A single host maildrop will be slightly simpler:

       Delivered-To: mbox-userstr-username@userhost.dom.com

The ISP can make the 'mbox-userstr-' prefix anything they choose but a string matching the user host name is likely.

To use this line you must:

  1. Ensure the option `envelope Delivered-To:' is in the fetchmail config file.
  2. Ensure you have a localdomains containing 'userdom.dom.com' or `userhost.dom.com' respectively.

So far this reliably delivers messages to the correct machine of the local network, to deliver to the correct user the 'mbox-userstr-' prefix must be stripped off of the user name. This can be done by setting up an alias within the qmail MTA on each local machine. Simply create a dot-qmail file called '.qmail-mbox-userstr-default' in the alias directory (normally /var/qmail/alias) with the contents:

      | ../bin/qmail-inject -a -f"$SENDER" "${LOCAL#mbox-userstr-}@$HOST"

Note this does require a modern /bin/sh.

Peter Wilson adds:

``My ISP uses "alias-unzzippedcom-" as the prefix, which means that I need to name my file ".qmail-unzzippedcom-default". This is due to qmail's assumption that a message sent to user-xyz is handled by the file ~user/.qmail-xyz (or ~user/.qmail-default).''

Luca Olivetti adds:

If you aren't using qmail locally, or you don't want to set up the alias mechanism described above, you can use the option `qvirtual "mbox-userstr-"' in your fetchmail config file to strip the prefix from the local user name.


T3. How can I use fetchmail with exim?

If you have rewrite on:

There is an RFC1123 requirement that MAIL FROM and RCPT TO addresses you pass to it have to be canonical (e.g. with a fully qualified hostname part). Therefore fetchmail tries to pass fully qualified RCPT TO addresses. But exim does not by default accept `localhost' as a fully qualified domain. This can be fixed.

In exim.conf, add `localhost' to your local_domains declaration if it's not already present. For example, the author's site at thyrsus.com would have a line reading:

       local_domains = thyrsus.com:localhost

If you have rewrite off:

MAIL FROM is a potential problem if the MTAs upstream from your fetchmail don't necessarily pass canonicalized From and Return-Path addresses, and fetchmail's rewrite option is off. The specific case where this has come up involves bounce messages generated by sendmail on your mailer host, which have the (un-canonicalized) origin address MAILER-DAEMON.

The right way to fix this is to enable the rewrite option and have fetchmail canonicalize From and Return-Path addresses with the mailserver hostname before exim sees them. This option is enabled by default, so it won't be off unless you turned it off.

If you must run with rewrite off, there is a switch in exim's configuration files that allows it to accept domainless MAIL FROM addresses; you will have to flip it by putting the line

        sender_unqualified_hosts = localhost

in the main section of the exim configuration file. Note that this will result in such messages having an incorrect domain name attached to their return address (your SMTP listener's hostname rather than that of the remote mail server).


T4. How can I use fetchmail with smail?

Smail 3.2 is very nearly plug-compatible with sendmail, and may work fine out of the box.

We have one report that when processing multiple messages from a single fetchmail session, smail sometimes delivers them in an order other than received-date order. This can be annoying because it scrambles conversational threads. This is not fetchmail's problem, it is an smail `feature' and has been reported to the maintainers as a bug.

Very recent smail versions require an -smtp_hello_verify option in the smail config file. This overrides smail's check to see that the HELO address is actually that of the client machine, which is never going to be the case when fetchmail is in the picture. According to RFC1123 an SMTP listener must allow this mismatch, so smail's new behavior (introduced sometime between 3.2.0.90 and 3.2.0.95) is a bug.

You may also need to say -smtp_hello_broken_allow=127.0.0.1 in order for smail to accept the "localhost" that fetchmail normally appends to recipient addresses.


T5. How can I use fetchmail with SCO's MMDF?

MMDF itself is difficult to configure, but it turns out that connecting fetchmail to MMDF's SMTP channel isn't that hard. You can read an MMDF recipe that describes replacing a UUCP link with fetchmail feeding MMDF.


T6. How can I use fetchmail with Lotus Notes?

The Lotus Notes SMTP gateway tries to deduce when it should convert \n to \r\n, but its rules are not the intuitive and correct-for-RFC822 ones. Use `forcecr'.


T7. How can I use fetchmail with Courier IMAP?

The courier mta doesn't like RCPT addresses that look like someone@localhost. Work around this with an smtphost or smtpaddress.


T8. How can I use fetchmail with vbmailshield?

vbmailshield's SMTP interpreter is broken. It doesn't understand RSET.

As a workaround, you can set batchlimit to 1 so RSET is never used.


S1. How can I use fetchmail with qpopper?

Qualcomm's qpopper is probably the best-of-breed among POP3 servers, and is very widely deployed. Nevertheless, it has some problems which fetchmail exposes. We recommend using IMAP instead if at all possible. If you must talk to qpopper, here are some problems to be aware of:

Problems with retrieving large messages from qpopper 2.53

Tony Tang <tony@atn.com.hk> reports that there is a bad intercation between fetchmail and qpopper 2.5.3 under Red Hat Linux versions 5.0 to 5.2, kernels 2.0.34 to 2.0.35. When fetching very large messages (over 700K) from 2.5.3, fetchmail will hang with a socket error.

This is probably not a fetchmail bug, but rather a symptom of some problem in the networking stack that qpopper's transmission pattern is tickling, as fetchpop (another Linux POP client) also displays the hang but Netscape running under Win95 does not. The problem can also be banished by upgrading to qpopper 3.0b1.

Bad interaction with fetchmail 4.4.2 to 4.4.7

Versions of fetchmail from 4.4.2 through 4.4.7 had a bad interaction with Eudora qpopper versions 2.3 and later. See X5 for details. The solution is to upgrade your fetchmail.


S2. How can I use fetchmail with Microsoft Exchange?

It's been reliably reported that Exchange 2000's POP3 support is so broken that it's unusable. One symptom is that messages without a terminating newline get the POP3 message termination dot emitted -- you guessed it -- right after the last character of the message, with no terminating newline added. This will hang fetchmail or any other RFC-compliant server. IMAP is alleged to work OK, though.

Older versions of Exchange are semi-usable. They randomly drop attachments on the floor, though. Microsoft acknowledges this as a known bug and apparently has no plans to fix it.

Fetchmail using IMAP supports the proprietary NTLM mode used with M$ Exchange servers. To enable this, configure fetchmail with the --enable-NTLM option and recompile it. Specify a user option value that looks like `user@domain': the part to the left of the @ will be passed as the username and the part to the right as the NTLM domain.

M$ Exchange violates the POP3 and IMAP RFCs. Its LIST command does not reveal the real sizes of mail in the pop mailbox, but the sizes of the compressed versions in the exchange mail database (thanks to Arjan De Vet and Guido Van Rooij for alerting us to this problem).

Fetchmail works with M$ Exchange, despite this brain damage. Two features are compromised. One is that the --limit option will not work right (it will check against compressed and not actual sizes). The other is that a too-small SIZE argument may be passed to your ESMTP listener, assuming you're usi