@@ -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.
-
@@ -2003,6 +2009,15 @@ sorts of strange effects, for instance, your sent mail may show up in
the mail that fetchmail fetches. It's best to avoid fetching mail from
Google until they are using standards-compliant software.
+If you still need to use Google's mail service, these links may help (valid as of 2011-04-13):
+
+
How to set up well-known security and authentication
methods
@@ -2523,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
@@ -3539,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):