TB 1.5, 2a1; SM 1.5a-0925 When a message arrives from an Apple client with attachments, the typical format of an attached item is: multipart/appledouble 1: application/applefile 2: [actual type] When the actual type is useful (e.g. image/jpeg) there is no problem; Mozilla gets the correct part and handles is according to the type. If the actual type is generic -- application/octet-stream -- the program is supposed to restrict the options for handling it (which has recently changed, bug 315536 -- see bug 346332 for the fallout from that); currently, the behavior is to force a save-to-disk. However, what actually happens is: the "multipart/appledouble" type is used to determine whether the retrictions should be enforced, so there are no restrictions. Then when the action is saved to mimeTypes.rdf, it's saved using the "multipart/appledouble" as well. This means if a later message arrives with multipart/appledouble + application/octet-stream, that attachment will be handled with the stored action even if the actual type is something entirely different -- e.g., a PDF could be passed to an MP3 player.

Steps to repeat: 1) Open a profile in Thunderbird or Seamonkey that doesn't have a default handler for the .JPG extenstion. 1a) With Seamonkey, open the MailNews window 2) File|Open, select this attachment 3 [review]) Double-click on the message's attachment 4 [review]) Select a handling option, check "Always do this", and OK 5) View the attachment-handling settings (TB: Options|Attachments|View; SM: Preferences|Navigator|Helper Applications). Double-click the JPG entry. Actual results: 3) Shows the regular "Opening..." dialog with the "Always do this" checkbox enabled. SM also shows attachment's type as "multipart/appledouble" 5) "Download Action" window shows type "multipart/appledouble" associated with the .JPG extension. Expected results: 3) Either the current "Save" dialog that is being used in the current builds of the branch for application/octet-stream, or the orignal dialog with Save, Open enabled but "Always do this" disabled. 4) Shouldn't *be* a .JPG entry at all.

xref bug 229879

This breaks attachment handling, so it's pretty serious.