At worst, this is a c-client issue.  At best, this is resolved with IMP 5.

Michael,



Thanks for you reply. I agree there are two different issues, 
understand the 2nd, and have experienced it (binhex40 decoding issue). 
However, the first problem does still exist. I decided, then, to try 
changing the encoding on the client to "data only", so it appears as 
[application/octet-stream], attachments still do not show up unless 
you save the message. They do show, however, in other programs, such 
as SquirrelMail, which I set up for the time being (in which, you do 
have to use Firefox to get the BinHex attachments to decode properly 
as you were discussing).



It must be something between horde and the Quickmail IMAP server...I'm 
hoping to change over to something more current in the near future on 
our server side anyway.

It sounds like we are talking about 2 different issues here.  You seem 
to be complaining that the attachment (named 'HB_190_chart_v3.doc') is 
not appearing as an attachment at all.  However, as mentioned by Jan 
and confirmed by me, this report is bogus - the attachment shows up 
fine.



The issue is instead when a user tries to download the file.  Since it 
is encoded in binhex40, a user on any non-Mac (Windows, for example) 
that tries to download the file (using a browser other than FF 2) will 
simply download the text of the encoded file.  This is not desirable 
since most OS's do not contain a binhex decode utility.  What needs to 
be done is to provide a link for these users (doing browser/OS 
sniffing) that allows the user to download the data contained in the 
encoded data.  Since it appears there is no PHP code/library that does 
decoding of binhex data, this will need to be done via an external 
program (such as UUDeview).

Initially, I did save the message for upload from Firefox 2 (Mac). I 
just saved a version of a message also sent from a Quickmail client 
through IE7 and the attachment (.xls) also showed up when opened in 
outlook exp.



I also have SquirrelMail 1.4.13 installed, side by side with IMP, and 
it does show the binhex4 messages as attachments....



I can send an email natively from a mac client with an encoded 
attachment to one of you if you wish - to see if the attachments show 
up for you..

Actually, I can almost 100% guarantee you downloaded the message 
w/Firefox.  Because we do no conversion of binhex40 data -- it is 
passed as-is to the browser so it is the browser that is internally 
doing the conversion.  Sure enough, try downloading the attachment 
w/IE 7 and you simply get the text of the body of the message.



This is RFC 1741, btw.

Works perfectly for me in IMP 4.1 and 4.2. This is probably be a 
broken imap server or c-client library on your side.

Here's a file, sent from Quickmail Client, with the attachment encoded 
in Mac BinHex 4.0.



Thanks!

Can you upload an example message that we can test against?

When sending an attachment from Quickmail Client 3.5.3 Mac OS 10.4 
(which encodes in macbinhex40), IMP will not register an attachment 
exists. However, if message is saved to disk, and opened in a client, 
the attachment is present.



Perhaps as simple as changing something in the MIME modules?