Bugs will be fixed, provided you include enough diagnostic information
for me to go on. Send bugs to fetchmail-users.
-When reporting bugs, please include the following:
+When sending bugs or asking for help, please
- Your operating system.
@@ -519,11 +528,11 @@ paper on the Web with a search for that title.
-Fetchmail will work with any POP, IMAP, ETRN, or ODMR server
+
Fetchmail will work with any POP3, IMAP, ETRN, or ODMR server
that conforms to the relevant standards/RFCs (and even some outright
broken ones like Microsoft Exchange and Novell GroupWise). This doesn't mean it works equally
-well with all, however. POP2 servers, and POP3 servers without UIDL,
+well with all, however. POP3 servers without UIDL
limit fetchmail's capabilities in various ways described on the manual
page.
@@ -535,16 +544,7 @@ minority also feature IMAP (you can detect IMAP support by using the
utility - unfortunately it does not detect SSL-wrapped variants).
If you have the option, we recommend using or installing an
-IMAP4rev1 or UIDL- and TOP-capable POP3 server. IMAP enables some
-significant performance optimizations.
-
-Don't be fooled by NT/Exchange propaganda. M$ Exchange is just
-plain broken (see item S2) and NT cannot handle
-the sustained load of a high-volume remote mail server. Even
-Microsoft itself knows better than to try this; their own Hotmail
-service runs over Solaris! For extended discussion, see John
-Kirch's excellent white
-paper on Unix vs. NT performance.
+IMAP4rev1 or UIDL-capable POP3 server.
A decent POP3/IMAP server that has recently become popular is Dovecot.
@@ -1595,34 +1595,47 @@ 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.
+other RFC-compliant client. IMAP is alleged to work OK, though.
+
+Exchange 2003 SP2 has been observed to alter MIME boundary
+lines in multipart messages between one IMAP FETCH command and the next
+under some circumstances -- for instance, when the top-level
+Content-Transfer-Encoding is "binary" (which is commonplace with Perl's
+MIME::Lite module). This causes MUAs to not detect attachments, but
+render the whole message body as one lump of hardly legible to
+unintelligible text, rather than nicely presenting text part and
+attachments or images separately. The cause is that Exchange uses its
+own message store and needs to convert back to MIME message format
+on-the-fly, and apparently this is sometimes subject to such
+inconsistencies.
+
-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 usually supports the proprietary NTLM mode used
+with Microsoft Exchange servers. "Usually" here means that it fails on some
+servers for reasons that we haven't been able to debug yet, perhaps it's
+related to the NTLM domain.
-Fetchmail using IMAP supports the proprietary NTLM mode used
-with M$ Exchange servers. To enable this, configure fetchmail with
+
To enable this NTLM mode, 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
+
Microsoft 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
+
Fetchmail works with Microsoft 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 using one (this should not be a
problem unless the actual size of the message is above the
listener's configured length limit).
-Somewhat belatedly, I've learned that there's supposed to be a
+
ESR learned that there's supposed to be a
registry bit that can fix this breakage:
@@ -1686,7 +1699,7 @@ reported in KB Q168109)
deleted.
-The Microsoft pod-person who revealed this information to me
+
The Microsoft employee who revealed this information to ESR
admitted that he couldn't find it anywhere in their public
knowledge base.
@@ -1694,7 +1707,7 @@ knowledge base.
as its symptom a response to LOGIN that says "NO Ambiguous Alias".
Grant Edwards writes:
-This means that Exchange Server is too f*&#ing stupid to
+
This means that Exchange Server is too [...] stupid to
figure out which mailbox belongs to you. Instead of actually
keeping track of which inbox belongs to which user, it uses some
half-witted, guess-o-matic heuristic to try to guess your mailbox
@@ -1702,9 +1715,7 @@ name from your username.
In your case it doesn't work because your username maps to more
than one mailbox. For some people it doesn't work because their
-username maps to zero mailboxes. This is yet another inept, lame,
-almost criminally negligent design decision from our friends in
-Redmond.
+username maps to zero mailboxes.
You've got several options:
@@ -1715,9 +1726,7 @@ usernames and mailbox names are the same.
- Get your administrator to add an alias that maps your username
explicitly to your mailbox name.
-
-But, the best option involves finding a server that runs better
-software.
+
@@ -1728,10 +1737,7 @@ href="#S2">Microsoft Exchange