[Alpine-info] Displaying Message/RFC822 attachments fails with
markrcrispin at panda.com
Wed Nov 26 01:59:04 PST 2008
On Wed, 26 Nov 2008, Heikki Vesalainen / Ixonos wrote:
> I found the problem by comparing the BODYSTRUCTUREs to the results of the
> imapd that comes with alpine. The _only_ thing "wrong" with the BODYSRUCTUREs
> given by both my servers is that they are giving NIL as the
> Content-Transfer-Encoding of the MESSAGE/RFC822 (it's the first NIL on the
> third line in the example below, just before 1780).
That was one of the problems, yes.
Exchange is a hopeless case. Microsoft told me that they have no
intention of fixing the bugs in Exchange's IMAP server.
> I think alpine not tolerating the NIL is a problem in alpine.
That part of Alpine is functioning correctly. See below.
> Content-Transfer-Encoding is not always present in MIME messages (AFAIK it's
> not mandatory in MIME -- and should it be, that's besides the point since
> most MUAs seem not to give it, the world is not perfect)
It's beside the point in another way as well. MIME semantics do not
dictate IMAP semantics.
> and as far as I
> know, there is no specification that says that the IMAP server should
> translate missing Content-Transfer-Encodings to "8BIT".
Since you got this far, I'll enlighten you the rest of the way.
The IMAP specification states that the encoding is mandatory (I should
know, I wrote it). NIL is prohibited in the encoding field of an IMAP
A reasonable server implementation will send the encoding as "8BIT" if the
encapsulated message has any octets with values 0x80 or higher, and "7BIT"
-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
More information about the Alpine-info