From 2e4e5a1af29d5ce749b90f33db8153c81c6936bf Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 26 Sep 2001 14:28:57 +0000 Subject: Added X8. svn path=/trunk/; revision=3490 --- fetchmail-FAQ.html | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file 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 @@
Back to Fetchmail Home Page To Site Map -$Date: 2001/09/26 14:11:25 $ +$Date: 2001/09/26 14:28:57 $

Frequently Asked Questions About Fetchmail

@@ -141,6 +141,7 @@ my Received headers as it should.
X5. Using POP3, retrievals seems to be fetching too much!
X6. My mail attachments are being dropped or mangled.
X7. Some mail attachments are hanging fetchmail.
+X8. A spurious ) is being appended to my messages.

Other problems:

@@ -2664,6 +2665,48 @@ packet sizes. It may also be caused by malfunctioning path-MTU discovery on the mailserver. Or, if there's a modem in the link, it may be because the attachment contains the Hayes mode escape "+++". +
+

X8. A spurious ) is being appended to my messages.

+ +

Blame it on that rancid pile of dung and offal called Microsoft +Exchange. Due to the problem described in S2, 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. + +

One piece of software that can trigger this is the Interchange mail +server, as used by, e.g., mailandnews.com. Here's what happens: + +

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" + +

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. + +

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. + +

4. Fetchmail only deals with complete lines, and can't trust the +stated message size because Microsoft Exchange fscks it up. + +

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. + +

There is no fix for this. The nuke mentioned in S2 looks more tempting all the time. +

O1. The --logfile option doesn't work if the logfile doesn't exist.

@@ -2878,7 +2921,7 @@ date from the last Received header.

Back to Fetchmail Home Page To Site Map -$Date: 2001/09/26 14:11:25 $ +$Date: 2001/09/26 14:28:57 $

Eric S. Raymond <esr@thyrsus.com>
-- cgit v1.2.3