[#6141] application/mac binhex40 attachments don't show
| Summary | application/mac binhex40 attachments don't show |
| Queue | IMP |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Assigned |
| Priority | 1. Low |
| Owners | Horde Developers, Michael Slusarz <slusarz (at) horde (dot) org> |
| Requester | d_clark (at) osba-ohio (dot) org |
| Created | 01/23/2008 (110 days ago) |
| Due | |
| Updated | 01/30/2008 (103 days ago) |
| Assigned | 01/30/2008 (103 days ago) |
| Resolved | |
| Attachments | HB 190 Chart.eml  Screenshots.zip |
| Milestone | |
| Patch |
New Attachment: Screenshots.zip
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.
>> 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..
>
> 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).
State ⇒ Assigned
Type ⇒ Enhancement
> 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..
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..
>> 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.
>
> 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.
State ⇒ Accepted
Assigned to
Assigned to Michael Slusarz
> 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.
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.New Attachment: HB 190 Chart.eml
> Can you upload an example message that we can test against?
Here's a file, sent from Quickmail Client, with the attachment encoded in Mac BinHex 4.0.
Thanks!
State ⇒ Feedback
Can you upload an example message that we can test against?Queue ⇒ IMP
Summary ⇒ application/mac binhex40 attachments don't show
Type ⇒ Bug
Priority ⇒ 1. Low
State ⇒ Unconfirmed
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?