I notice that bug 118085 was resolved WONTFIX in 2007 on the argument that, at that time, "there [we]re 709 attachments with message/rfc822 as the mimetype, which d[id]n't even put it in the top 10"; but in 5+ years many things have changed. Also, this particular MIME type is admittedly totally unimportant for Firefox, but not for Thunderbird and SeaMonkey. In particular, when doing triage work for SeaMonkey Mail and occasionally for MailNews Core or even Thunderbird, I very often find myself asking reporters to attach a copy of a problematic email message. Those .eml files are systematically detected as MIME type application/octet-stream, which is wrong. It would make my job much easier if they could be autodetected with the correct type instead: message/rfc822. Wayne: what is the Thunderbird angle on this question?
> Wayne: what is the Thunderbird angle on this question? I am not sure what you mean. But, yes, this would make triage/testing simpler
can you provide examples of attachments which were incorrectly detected? bugzilla should already be mapping .eml files to message/rfc822.
while doing some more digging, i discovered that a required package for mime type detection may be missing on the new bugzilla webheads (bug 859804). while i suspect installing this package will resolve this issue, i'd still like sample attachments to verify.
Depends on: 859804
Created attachment 735447 [details] sample .eml attachment When a "New to Bugzilla" reporter attaches an email message, I see it arrive as application/octet-stream. Now, so that it happens in controlled conditions, I'll attach one myself. I'm leaving the content-type radio button at "auto-detect".
ah, sorry, apparently the newbie reporters tried to be cleverer than Bugzilla. My bad. And yet I've seen it happen several times in succession. The only thing with which I'm not really satisfied in this respect is that message/rfc822 is not present in the dropdown widget, but neither are some more common filetypes such as application/zip or application/xhtml+xml. I suppose ten filetypes is regarded as a "reasonable" number even if more of them could be useful.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Created attachment 735452 [details] sample non-latin-alphabet email Let's try again with something not in Latin script
After reading bug 859804, maybe I "happened" to be connected (twice) to some Bugzilla server(s) which had the required package installed. Byron, feel free to REOPEN this bug if the MIME type may be detected differently depending on load-balancing server rotation.
P.S. Attachment 735452 [details] is a short spam message in Korean. There is a link in it and I don't know where it leads; if I were you, I would NOT click it!
P.P.S. I "think" that I'm currently interacting with bugzilla-zlb.vips.scl3.mozilla.com 188.8.131.52
the mimetype detection works as follows: 1. if your browser provides a mimetype which isn't application/octet-stream, that will always be used. 2. the mimetype is guessed from the file extension, using the database i reference in bug 859804. 3. if that fails, the content of the file is examined for known signatures (from the same database). as all webheads behind bugzilla-zlb are identical, it's more likely that your browser is sending bugzilla the correct mime type (ie. your o/s is configured to map .eml to the message/rfc822 mimetype). you can test this with http://drop.glob.com.au/859606/
In reply to comment #10: Yeah, this is what I got: filename: gibberish.eml browser-sent content-type: message/rfc822 extension sniffing: message/rfc822 content sniffing: text/plain using the current SeaMonkey 2.20a1 linux-x86_64 nightly on openSUSE Linux 12.1
You need to log in before you can comment on or make changes to this bug.