[imp] problem displaying attachment

Wed Feb 11 07:36:09 PST 2004

Thank Michael and Eric,

I've upgraded to CVS (10th Feb RELENG version) and the
problem remains.  The problem is also present in every
email I receive... so it is unlikely to be from a
badly formed header.  

Any ideas?

Thanks,
Leonid

Here's a sample header of an email with a known
attachment:

Envelope-to: lshapiro at candesic.com
Delivery-date: Wed, 11 Feb 2004 13:54:49 +0000
helo=kelso.kelsopr.com)
	by carbon.webfusion.co.uk with smtp (Exim 3.36 #1)
	id 1Aquov-0001cJ-00
	for lshapiro at candesic.com; Wed, 11 Feb 2004 13:54:29
+0000
Received: from Kelso_consulting-Message_Server by
kelso.kelsopr.com
	with Novell_GroupWise; Wed, 11 Feb 2004 09:52:16
+0000
Message-Id: <s029fb50.007 at kelso.kelsopr.com>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 11 Feb 2004 09:51:41 +0000
From: "Jenny Chandler" <JennyC at kelsopr.com>
To: <lshapiro at candesic.com>
Subject: Networking seminar
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_BA9BDE40.10711488"

message follows....

--- Michael M Slusarz <slusarz at bigworm.colorado.edu>
wrote:
> 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
> -- 
> IMP mailing list - Join the hunt:
> http://horde.org/bounties/#imp
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail:
imp-unsubscribe at lists.horde.org

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html