[imp] problem displaying attachment

[Michael M Slusarz]

Quoting Eric Rostetter <eric.rostetter at physics.utexas.edu>:

>> When I access the exact same message using outlook or
>> another IMAP client, the attachment are readable.
>
> Yes, most other clients will treat a (broken) message that is missing it's
> MIME-Version: header as if it was a MIME message. IMP will not.

To clarify what Eric said, it is actually the c-client library (not IMP/Horde)
that will not parse a message (as expected) if the MIME Version header is not
set.  (To be technical, it is imap_fetchstructure() that returns a single
object of type application/octet-stream - rather than an object structure that
would be expected for a correctly formatted multipart MIME message - so there
is nothing IMP can do about these messages because it is not even aware that
the message is "supposed" to contain multiple parts).

And imap_fetchstructure() is correctly parsing these messages without
MIME-Version headers because, simply put, the message is NOT a MIME message.  A
MIME message requires the MIME-Version field (RFC 2045 [4]; see also RFC 2822
[1.1]).  Other mail clients that display the MIME structure without this header
are breaking RFC's *horribly*.  And those who might whine and disagree and say
"but as a fallback a mail client should handle the message as MIME because the
basic enduser doesn't/shouldn't care about RFCs" are so clueless about the
whole concept of MIME/mail transport that I won't bother to respond to that
statement.

So, in the absence of the MIME trigger (the MIME-Version header), there is no
way of knowing for sure what the contents of the message are (see RFC 2822). 
It could be text/plain, but it could also be image/png or application/msword or
something else.  Thus, the only sane solution is to call the contents of the
message 'data' and that's it.

Then again, as Eric pointed out, it is impossible to tell for sure that this is
the problem without seeing the headers of the message.  However, just wanted to
get this explanation out in the list/archives so the next time this "problem"
comes up, we will have something to quickly point to :)

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder