TCPIP IMAP Server

[Milan Lesnik]

Hi

We have problem when one sends mime - multipart/alternative - messages.

Our environment:

1. Openvms system, Hp/Compaq tcpip v5.3 eco 2 (latest imap server)
2. Openvms system (same as the above) pmdf v6.0-24 imap server
(http://www.process.com/techsupport/pmdf.html)
3. Horde 2.2.4, IMP 3.2.2

Our problem:

One sends multipart/alternative with attachment. If imap server is Hp/Compaq's
tcpip v 5.3 eco 2, Horde/IMP doesn't display parts of the message correctly.
One sees unnamed part and doesn't see attachment.

When we change imap server to PMDF (everything else is the same) Horde/IMP
displays parts of the message correctly (for example user can save attachment).

Here are commands from IMAP client and responses of IMAP servers:

PMDF IMAP SERVER:

. FETCH 1 (BODYSTRUCTURE FLAGS)
* 1 FETCH (BODYSTRUCTURE ((("TEXT" "PLAIN" ("CHARSET" "iso-8859-2") NIL NIL
"7BIT" 88 2 NIL NIL NIL)("TEXT" "HTML" ("CHARSET" "iso-8859-2") NIL NIL
"BASE64" 616 10 NIL NIL NIL) "ALTERNATIVE" ("BOUNDARY"
"Boundary_(ID_KUmgj5W7rD2ULVu1cumrpQ)") NIL NIL)("APPLICATION" "MSWORD"
("NAME" "x.doc") NIL NIL "BASE64" 34 NIL ("ATTACHMENT" ("FILENAME" "x.doc"))
NIL) "MIXED" ("BOUNDARY" "Boundary_(ID_VXxDtGNZuEqn6oCJM0YdgQ)") NIL NIL)
FLAGS (\Seen))
. OK FETCH completed


HP/COMPAQ IMAP SERVER:

. FETCH 1 (BODYSTRUCTURE FLAGS)
* 1 FETCH (BODYSTRUCTURE ((("TEXT" "PLAIN" ("CHARSET" "ISO-8859-2") NIL NIL
"7BIT" 90 3)("TEXT" "HTML" ("CHARSET" "ISO-8859-2") NIL NIL "BASE64" 618 11)
ALTERNATIVE)("APPLICATION" "MSWORD" ("NAME" "x.doc") NIL NIL "BASE64" 36)
MIXED) FLAGS (\Seen))
. OK Fetch completed

We think that Compaq's Imap server doesn't parse the message correctly so imap
server sends incorrect information back to the client.

Except Pine other Imap clients doesn't have this problem, but we want to
migrate to Webmail and this is the big problem (we don't have $ to pay
licenses for the working imap server).

Is it possible to get workaround in IMP (php code modification)?

Maybe new version of IMAP server?

Milan

[Hari Muzumdar]

Hello Milan,

[If the reply appears improperly formatted,
please download the attached text file
(5kB), which contains a copy of this reply].

> Is it possible to get workaround in IMP (php code modification)?

We wouldn't know. Is there a newsgroup or other support forum for IMP?


Regarding the problem itself, the following points come to light.


1. Dependence on BODYSTRUCTURE FETCH

Most of the popular IMAP clients (Outlook Express and Mozilla for
instance) do not use the BODYSTRUCTURE FETCH at all. They rely on
FETCHes of RFC822.HEADERS and RFC822 content in order to provide
their features including preview panes (which is one feature where
parsing of the bodypart boundaries may be needed).

Pine/WebMail appears to be relying a lot more on BODYSTRUCTURE than
other clients do.


2. Multipart boundary fields: Difference between PMDF and HP IMAP

Looking closely at the output of the two FETCH commands in your
query, we can see that the major difference between PMDF's and HP's
IMAP outputs is the presence/absence of the multipart boundary
fields (for both multipart/mixed bodyparts and for
multipart/alternative).


3. Extension data: Not mandatory

In the context of the IMAP4 protocol, the multipart boundary field
is part of "Multipart Extension Data", and it is not mandatory for
an IMAP Server to include this data in the output. From RFC 2060:

Extension data follows the multipart subtype.
Extension data is never returned with the BODY
fetch, but can be returned with a BODYSTRUCTURE
fetch. Extension data, if present, MUST be in the
defined order.


We have expanded/indented the output of the FETCHes below, to better
illustrate this. Please search for the text "<--".


Best Regards,
Office Server Engineering.


PMDF IMAP SERVER:
. FETCH 1 (BODYSTRUCTURE FLAGS)
* 1 FETCH (BODYSTRUCTURE
( <-- parenthesis indicating start of multipart/mixed message structure
( <-- parenthesis indicating start of multipart/alternative bodypart structure
(
"TEXT" "PLAIN"
(
"CHARSET" "iso-8859-2" <-- IMAP4 Basic Field for non-multipart bodypart
)
NIL NIL "7BIT" 88 2 NIL NIL NIL
)
(
"TEXT" "HTML"
(
"CHARSET" "iso-8859-2" <-- IMAP4 Basic Field for non-multipart bodypart
)
NIL NIL "BASE64" 616 10 NIL NIL NIL
)

"ALTERNATIVE"
(
"BOUNDARY" "Boundary_(ID_KUmgj5W7rD2ULVu1cumrpQ)" <-- IMAP4 Extension Data for
) -- multipart/alternative bodypart
NIL NIL
)
(
"APPLICATION" "MSWORD"
(
"NAME" "x.doc"
)
NIL NIL "BASE64" 34 NIL
(
"ATTACHMENT"
(
"FILENAME" "x.doc"
)
)
NIL
)
"MIXED"
(
"BOUNDARY" "Boundary_(ID_VXxDtGNZuEqn6oCJM0YdgQ)" <-- IMAP4 Extension Data for a
) -- multipart/mixed bodypart
NIL NIL
)





HP/COMPAQ IMAP SERVER:
. FETCH 1 (BODYSTRUCTURE FLAGS)
* 1 FETCH (BODYSTRUCTURE

( <-- parenthesis indicating start of multipart/mixed message structure
( <-- parenthesis indicating start of multipart/alternative bodypart structure
(
"TEXT" "PLAIN"
(
"CHARSET" "ISO-8859-2" <-- IMAP4 Basic Field for non-multipart bodypart
)
NIL NIL "7BIT" 90 3
)
(
"TEXT" "HTML"
(
"CHARSET" "ISO-8859-2" <-- IMAP4 Basic Field for non-multipart bodypart
)
NIL NIL "BASE64" 618 11
)

ALTERNATIVE
<-- IMAP4 Extension Data following a
) -- multipart/alternative is not provided

(
"APPLICATION" "MSWORD"
(
"NAME" "x.doc"
)
NIL NIL "BASE64" 36
)
MIXED
<-- IMAP4 Extension Data following a
-- multipart/mixed is not provided
)

[Milan Lesnik]

Hi

Thanks, for the very informative answer.

Milan