Merge branch 'legacy_63'

[~andy/fetchmail] / fetchmail-FAQ.html

diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html
index f556de7b8e43d68ea7e086c43457f030efea3b91..5433220e8f4b7f03f532f948182ee254d5d1890a 100644 (file)
--- 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.</p>
-
-<p>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.</p>
+other RFC-compliant client. IMAP is alleged to work OK, though.</p>
+
+<p>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.
+</p>
 
 <p>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.</li>
 </ul>
 </blockquote>
 
-<p>But, the best option involves finding a server that runs better
-software.</p>
-
 <h2><a id="S3" name="S3">S3. How can I use fetchmail with HP
 OpenMail?</a></h2>
 
@@ -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.</p>
 
+<p>If you still need to use Google's mail service, these links may help (valid as of 2011-04-13):</p>
+<ul>
+    <li><a href="http://mail.google.com/support/bin/topic.py?hl=en&amp;topic=12805">Other ways to access Gmail &gt; POP</a></li>
+    <li><a href="http://mail.google.com/support/bin/topic.py?hl=en&amp;topic=12806">Other ways to access Gmail &gt; IMAP</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=47948">Using POP on multiple clients or mobile devices</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=13291">Some [POP3] mail was not downloaded</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&amp;answer=78774">I'm having problems downloading [IMAP] mail</a></li>
+</ul>
+
 <hr/>
 <h1>How to set up well-known security and authentication
 methods</h1>
@@ -2523,10 +2538,11 @@ the most secure schemes are tried first.</p>
 
 <p>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.</p>
+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.</p>
 
 <p><strong>Solution:</strong> Configure the right authentication scheme
 explicitly, for instance, with <kbd>--auth cram-md5</kbd> or <kbd>--auth