@@ -528,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.
@@ -1595,11 +1595,20 @@ 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.
+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.
+
Fetchmail using IMAP usually supports the proprietary NTLM mode used
with Microsoft Exchange servers. "Usually" here means that it fails on some
@@ -1719,9 +1728,6 @@ explicitly to your mailbox name.
-
But, the best option involves finding a server that runs better
-software.
-
@@ -2532,10 +2538,11 @@ the most secure schemes are tried first.
However, sometimes the server offers a secure authentication scheme
that is not properly configured, or an authentication scheme such as
-GSSAPI does requires credentials to be acquired externally. In some
-situations, fetchmail cannot know the scheme will fail without trying
-it. In most cases, fetchmail should proceed to the next authentication
-scheme automatically, but this sometimes does not work.
+GSSAPI that requires credentials to be acquired externally. In some
+situations, fetchmail cannot know that the scheme will fail beforehand,
+without trying it. In most cases, fetchmail should proceed to the next
+authentication scheme automatically, but this sometimes does not
+work.
Solution: Configure the right authentication scheme
explicitly, for instance, with --auth cram-md5 or --auth
@@ -3548,7 +3555,7 @@ oversized mails or both when a user specifies both
first message in your mailbox. This usually stems from a message like
the one shown below, which is automatically created on your server. This
message shows up if the University of Washington IMAP or PINE software
-is used on the server together with a POP2 or POP3 daemon that is not
+is used on the server together with a POP3 daemon that is not
aware of these messages, such as some versions of Qualcomm Popper
(QPOP):