Added X8.

svn path=/trunk/; revision=3490

1 files changed, 45 insertions, 2 deletions

diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html
index 0444a6d9..0f15679f 100644
--- a/fetchmail-FAQ.html
+++ b/fetchmail-FAQ.html
@@ -10,7 +10,7 @@
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2001/09/26 14:11:25 $
+<td width="30%" align=right>$Date: 2001/09/26 14:28:57 $
 </table>
 <HR>
 <H1>Frequently Asked Questions About Fetchmail</H1>
@@ -141,6 +141,7 @@ my Received headers as it should.</a><br>
 <a href="#X5">X5. Using POP3, retrievals seems to be fetching too much!</a><br>
 <a href="#X6">X6. My mail attachments are being dropped or mangled.</a><br>
 <a href="#X7">X7. Some mail attachments are hanging fetchmail.</a><br>
+<a href="#X8">X8. A spurious ) is being appended to my messages.</a><br>
 
 <h1>Other problems:</h1>
 
@@ -2665,6 +2666,48 @@ discovery on the mailserver.  Or, if there's a modem in the link,
 it may be because the attachment contains the Hayes mode escape "+++".
 
 <hr>
+<h2><a 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%.  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>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>1.  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>2.  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>3.  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:
+ 
+ ....blahblah)...
+ 
+where the ')' is from IMAP.
+ 
+<p>4.  Fetchmail only deals with complete lines, and can't trust the
+stated message size because Microsoft Exchange fscks it up.
+
+<p>5. 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>There is no fix for this.  The nuke mentioned in <a
+href="#S2">S2</a> looks more tempting all the time.
+
+<hr>
 <h2><a name="O1">O1. The --logfile option doesn't work if the logfile doesn't exist.</a></h2>
 
 <p>This is a feature, not a bug.  It's in line with normal practice for
@@ -2878,7 +2921,7 @@ date from the last Received header.<p>
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2001/09/26 14:11:25 $
+<td width="30%" align=right>$Date: 2001/09/26 14:28:57 $
 </table>
 
 <ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@thyrsus.com&gt;</A></ADDRESS>