X-Git-Url: http://pileus.org/git/?a=blobdiff_plain;f=fetchmail-FAQ.html;h=5433220e8f4b7f03f532f948182ee254d5d1890a;hb=910d5a2f852edb8c4e54c0e875da6a90385ab790;hp=f556de7b8e43d68ea7e086c43457f030efea3b91;hpb=7db382b5b9a4fe8cdaf7b7c18a86bdb35fdf2853;p=~andy%2Ffetchmail diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html index f556de7b..5433220e 100644 --- a/fetchmail-FAQ.html +++ b/fetchmail-FAQ.html @@ -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.
-If you still need to use Google's mail service, these links may help (valid as of 2011-04-13):
+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