(In reply to comment #22) > (In reply to comment #14) > > Actually now that I think about it, what would prevent malicious code from > > being placed into a file with a header that doesn't require RFC 2183??? > > Nothing, on your own site which would then get blacklisted as soon as the > problem is discovered. On the other hand, obeying RFC 2183 prevents you from > uploading your malicious stuff to some other site that just wants to let people > upload things. At least if said other site is a little careful. Well, then that's the point: Malicious files will be blacklisted as soon as they are discovered, so that should have no bearing on how the user wants to interact with their content. Without question, safeguards can and should be put in place, but they should not prevent a user from deliberately choosing to ignore them. There are innumerable ways in which a user could deliberately expose themselves to harm that are not barred by Firefox or any internet rules. So why is this case any different? I believe it is because the developers are misinterpreting the MIME standards. I believe most (if not all) of this behavior occurs with application/octet-stream MIME types. According to RFC 2046 (addressing security issues in MIME types), under section 4.5.1 for application/octet-stream entities: "The recommended action for an implementation that receives an 'application/octet-stream' entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process. To reduce the danger of transmitting rogue programs, it is strongly recommended that implementations NOT implement a path-search mechanism whereby an arbitrary program named in the Content-Type parameter (e.g., an 'interpreter=' parameter) is found and executed using the message body as input." A plain reading of this text reveals that it is RECOMMENDED to avoid automatically executing on undefined (/octet-stream) MIME types; it is not a strict rule to prevent such action by the user. According to RFC 2183, the purpose of the MIME framework is to provide "for the interchange of message content, but leaves presentation issues solely in the hands of mail user agent (MUA) implementors". This text suggests it is up to Mozilla to define how to handle presentation issues, and thus it is within the purview of developers to determine how Firefox handles these MIME types. I agree that the default behavior should be for increased security, but the MUA (program=Firefox) should not prevent the user from selecting another less secure behavior should they so desire. RFC 2183 does not explicitly state the MUA must disallow any potential non-secure behavior: "There are security issues involved any time users exchange data. While these are not to be minimized, neither does this memo change the status quo in that regard, except in one instance. Since this memo provides a way for the sender to suggest a filename, a receiving MUA must take care that the sender's suggested filename does not represent a hazard." The key text here is "A RECEIVING MUA MUST TAKE CARE THAT THE SENDER'S SUGGESTED FILENAME DOES NOT REPRESENT A HAZARD". Thus, it is up to the MUA (and by extension the user) to determine what is and is not a hazard. It does not require the implementor to prevent the MUA from choosing a potentially hazardous behavior. Finally, I believe most of the issue hinges on the following text from RFC 2183 section 2.2: "Bodyparts can be designated 'attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage." A close reading of this text reveals that it does not specify this behavior must be followed each time the user receives an 'attachment' MIME type. Instead, the operative words are "should" and "might". It does not REQUIRE any particular behavior, rather it SUGGESTS what should be done. Therefore, since neither RFC 2046 nor RFC 2183 require the MUA or MUA implemetor to restrict any particular behaviors with respect to application/octet-stream MIME types, the desired change for this bug is not barred under those standards. Furthermore, it is not apparent to me who enforces these standards and what the potential liability would be for non-compliance. As such, I implore the developers to provide a workaround to this UI issue.