Remove some of ESR's rants against commercial software; minor formatting fixes.

svn path=/branches/BRANCH_6-3/; revision=5417

1 files changed, 41 insertions, 55 deletions

diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html
index 5abc4656..c04361ea 100644
--- a/fetchmail-FAQ.html
+++ b/fetchmail-FAQ.html
@@ -535,16 +535,7 @@ minority also feature IMAP (you can detect IMAP support by using the
 utility - unfortunately it does not detect SSL-wrapped variants).</p>
 
 <p>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.</p>
-
-<p>Don't be fooled by NT/Exchange propaganda. M$ Exchange is just
-plain broken (see item <a href="#S2">S2</a>) 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 <a href="http://unix-vs-nt.org/kirch/">white
-paper</a> on Unix vs. NT performance.</p>
+IMAP4rev1 or UIDL-capable POP3 server.</p>
 
 <p>A decent POP3/IMAP server that has recently become popular is <a
     href="http://dovecot.org/">Dovecot</a>.</p>
@@ -1601,28 +1592,32 @@ other RFC-compliant server. IMAP is alleged to work OK, though.</p>
 attachments on the floor, though.  Microsoft acknowledges this
 as a known bug and apparently has no plans to fix it.</p>
 
-<p>Fetchmail using IMAP supports the proprietary NTLM mode used
-with M$ Exchange servers. To enable this, configure fetchmail with
+<p>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.</p>
+
+<p>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.</p>
 
-<p>M$ Exchange violates the POP3 and IMAP RFCs. Its LIST command
+<p>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).</p>
 
-<p>Fetchmail works with M$ Exchange, despite this brain damage. Two
-features are compromised. One is that the --limit option will not
+<p>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).</p>
 
-<p>Somewhat belatedly, I've learned that there's supposed to be a
+<p>ESR learned that there's supposed to be a
 registry bit that can fix this breakage:</p>
 
 <pre>
@@ -1686,7 +1681,7 @@ reported in KB Q168109)</dt>
 deleted.</dd>
 </dl>
 
-<p>The Microsoft pod-person who revealed this information to me
+<p>The Microsoft employee who revealed this information to ESR
 admitted that he couldn't find it anywhere in their public
 knowledge base.</p>
 
@@ -1694,7 +1689,7 @@ knowledge base.</p>
 as its symptom a response to LOGIN that says "NO Ambiguous Alias".
 Grant Edwards writes:</p>
 
-<p>This means that Exchange Server is too f*&amp;#ing stupid to
+<blockquote><p>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 +1697,7 @@ name from your username.</p>
 
 <p>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.</p>
+username maps to zero mailboxes.</p>
 
 <p>You've got several options:</p>
 
@@ -1715,6 +1708,7 @@ usernames and mailbox names are the same.</li>
 <li>Get your administrator to add an alias that maps your username
 explicitly to your mailbox name.</li>
 </ul>
+</blockquote>
 
 <p>But, the best option involves finding a server that runs better
 software.</p>
@@ -1728,10 +1722,7 @@ href="#S2">Microsoft Exchange</a>. The message sizes it gives in
 the LIST are rounded to the nearest 1024 bytes. It also has a nasty
 habit of discarding headers it doesn't recognize, such as X- and
 Resent- headers.</p>
-
-<p>As with M$ Exchange, the only real fix for these problems is to
-get a POP (or preferably IMAP) server that isn't brain-dead.
-OpenMail's project manager claims these bugs have been fixed in
+<p>OpenMail's project manager claims these bugs have been fixed in
 6.0.</p>
 
 <p>We've had a more recent report (December 2001) that the TOP
@@ -1740,13 +1731,11 @@ on something identifying itself as "OpenMail POP3 interface".</p>
 
 <h2><a id="S4" name="S4">S4. How can I use fetchmail with Novell GroupWise?</a></h2>
 
-<p>The Novell GroupWise IMAP server would be better named
-GroupFoolish; it is (according to the designer of IMAP) unusably
-broken. Among other things, it doesn't include a required content
-length in its BODY[TEXT] response.</p>
+<p>The Novell GroupWise IMAP server is (according to the designer of
+IMAP) unusably broken. Among other things, it doesn't include a required
+content length in its BODY[TEXT] response.</p>
 
-<p>Fetchmail works around this problem, but we strongly recommend
-voting with your dollars for a server that isn't brain-dead.</p>
+<p>Fetchmail works around this problem to some extent, but no guarantees.</p>
 
 <h2><a id="S5" name="S5">S5. How can I use fetchmail with
 InterChange?</a></h2>
@@ -1757,9 +1746,9 @@ attachments. InterChange has a bug similar to the MailMax server (<a
 it reports the message length with attachments but doesn't download
 them on TOP or RETR.</p>
 
-<p>On Jan 9 2001, the people at InfiniteMail sent me mail informing
-me that their new 3.61.08 release of InterChange fixes this
-problem. I don't have any reports one way or the other yet.</p>
+<p>On Jan 9 2001, the people at InfiniteMail sent ESR mail informing
+him that their new 3.61.08 release of InterChange fixed this
+problem.</p>
 
 <h2><a id="S6" name="S6">S6. How can I use fetchmail with MailMax?</a></h2>
 
@@ -3148,9 +3137,8 @@ mailtool's format.</p>
 <h2><a id="X7" name="X7">X7. Some mail attachments are hanging
 fetchmail.</a></h2>
 
-<p>This isn't fetchmail's problem either; fetchmail doesn't know
-anything about mail attachments and doesn't treat them any
-differently from plain message data.</p>
+<p>Fetchmail doesn't know anything about mail attachments and doesn't
+treat them any differently from plain message data.</p>
 
 <p>The most usual cause of this problem seems to be bugs in your
 network transport layer's capability to handle the very large
@@ -3171,51 +3159,49 @@ Hayes mode escape "+++".</p>
 <h2><a id="X8" name="X8">X8. A spurious ) is being appended to my
 messages.</a></h2>
 
-<p>Blame it on that rancid pile of dung and offal called Microsoft
-Exchange. Due to the problem described in <a href="#S2">S2</a>, the
-IMAP support in fetchmail cannot follow the IMAP protocol 100%.
+<p>Due to the problem described in <a href="#S2">S2</a>, the
+IMAP support in fetchmail cannot follow the IMAP protocol 100&nbsp;%.
 Most of the time it doesn't matter, but if you combine it with an
 SMTP server that behaves unusually, you'll get a spurious ) at
-message end.</p>
+the message end.</p>
 
 <p>One piece of software that can trigger this is the Interchange
 mail server, as used by, e.g., mailandnews.com. Here's what
 happens:</p>
 
-<p>1. Someone sends mail to your account. The last line of the
+<ol><li>Someone sends mail to your account. The last line of the
 message contains text. So at the SMTP level, the message ends with,
-e.g. "blahblah\r\n.\r\n"</p>
+e.g. "blahblah\r\n.\r\n"</li>
 
-<p>2. The SMTP handler sees the final "\r\n.\r\n" and recognizes
+<li>The SMTP handler sees the final "\r\n.\r\n" and recognizes
 the end of the message. However, instead of doing the normal thing,
 which is tossing out the ".\r\n" and leaving the first '\r\n' as
 part of the email body, Interchange throws out the whole
 "\r\n.\r\n", and leaves the email body without any line terminator
 at the end of it. RFC821 does not forbid this, though it probably
-should.</p>
+should.</li>
 
-<p>3. Fetchmail, or some other IMAP client, asks for the message.
+<li>Fetchmail, or some other IMAP client, asks for the message.
 IMAP returns it, but it's enclosed inside parentheses, according to
 the protocol. The message size in bytes is also present. Because
 the message doesn't end with a line terminator, the IMAP client
-sees:</p>
+sees:
 
 <pre>
-
  ....blahblah)...
 </pre>
 
-<p>where the ')' is from IMAP.</p>
+<p>where the ')' is from IMAP.</p></li>
 
-<p>4. Fetchmail only deals with complete lines, and can't trust the
-stated message size because Microsoft Exchange fscks it up.</p>
+<li>Fetchmail only deals with complete lines, and can't trust the
+stated message size because Microsoft Exchange goofs it up.</li>
 
-<p>5. As a result, fetchmail takes the final 'blahblah)' and puts
+<li>As a result, fetchmail takes the final 'blahblah)' and puts
 it at the end of the message it forwards on. If you have verbosity
-on, you'll get a message about actual != expected.</p>
+on, you'll get a message about actual != expected.</li>
+</ol>
 
-<p>There is no fix for this. The nuke mentioned in <a
-href="#S2">S2</a> looks more tempting all the time.</p>
+<p>There is no fix for this.</p>
 
 <h2><a id="X9" name="X9">X9. Missing "Content-Transfer-Encoding" header
 	with Domino IMAP</a></h2>