And I'd say it wasn't possible either, if I didn't have two messages 
with two different user agents:



User-Agent: Internet Messaging Program (IMP) 3.1

User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)



Same file, different encoding.  Unless the user is using a different 
browser with each and not telling me.  That's always a possibility and 
probably a far more liklier reality than using the same browser with 
different encodings.

That difference wasn't clear to me in the description of the problem, 
but it doesn't make any sense either. We haven't changed whether or 
not we take the browser's mime type for attachments.

One question, if I may:



Why does sending the same document with the same browser work with 
Horde 2.X but not Horde 3.X?  Obviously, different MIME handling but 
why Content-Type: application/msword with one and Content-Type: 
multipart/appledouble with the other?

Found the root cause:

https://bugzilla.mozilla.org/show_bug.cgi?id=236239

bug 2052 created with the only info relevant to what IMP could 
possibly be doing wrong created. happy?

Thats my whole point for logging the bug report - IMP generated this 
badly broken message.  You can blame it on the browser or the user, 
but the User Agent ultimately responsible for generating the bad 
message out of bad data is IMP...



Change the subject to be "Prevent messages generated by IMP with 
malformed AppleDouble MIME parts [because they cause trouble]" and 
change it from a bug to an enhancement request.  I don't care about 
the display of bad MIME data, since that's what this turned out to be 
and I wouldn't expect a badly broken message to be displayed.  I do 
care (and my users care) about working around broken browsers' MIME 
types and not having IMP pass on partial AppleDouble components from 
file uploads - better to notify them their browser is hosed then to 
have them get frustrated by repeatedly sending messages with alleged 
attachments and the recipients constantly responding they didn't get 
the attachment.  I'll try and figure out how this is even possible 
from Firefox because the only place I've routinely seen AppleDouble is 
in the context of an email - never seen it in browser MIME settings.

There's no way the browser should be specifying a multipart mimetype 
for a single file upload - it makes no sense. And yes, perhaps we 
should catch and reject that, but that has nothing to do with the 
message that you attached to this ticket, or with the subject of the 
ticket - the attached message is very, very broken and there's no way 
to display anything from it.

But if I'm an application and a browser hands me some data, that by 
spec should contain two parts, and then proceeds to pass only one 
piece of data to me, shouldn't the application catch that and abort 
the process, instead of passing a malformed AppleDouble attachment?   
Relying on the browser to enforce the AppleDouble spec is not a good 
thing, IMHO.  If I could figure out how in the world the browser was 
even suggesting AppleDouble, I'd maybe be able to suggest a permanent 
solution.



FWIW, I just attached a simple Word document to an email with Firefox 
on my Powerbook and it shows up as text/richtext, leading me to 
believe that Firefox has got some serious issues with MIME types.

There is nothing we can do with this message. multipart/appledouble 
implies two parts - that's the appledouble spec - and this mesage has 
just one. No way we can get anything out of that.

Per discussion on the mailling list, here is the problem message in 
encrypted zip format.



Gives me trouble in Outlook Express under XP, although I don't know if 
OE even knows about AppleDouble.  AppleDouble MIME part also not 
decoded in Thunderbird either (doesn't even show up).