Am 27.12.2012 10:10, schrieb A.L.E.C:
On 12/26/2012 09:38 PM, Michael Heydekamp wrote:
Our system is returning "text/x-mail" (rather than "message/rfc822", how it would be expected) when we throw the PHP function 'finfo_open' against a valid e-mail file, which has been saved locally with Roundcube, starting with a line "Return-path:". Therefore and logically Roundcube is declaring ""text/x-mail" when attaching this .eml to an e-mail, which does prevent Roundcube from handling and rendering the attchment as an e-mail.
In my opinion fileinfo result is correct. Return-path is not RFC-compliant, that's the reason why it chooses text/x-mail.
First: After some more investigation, it looks as if almost ALL messages that came in through our server do carry a header "Return-path:" (opposed to "Return-Path:"). I have no idea yet who is responsible for that (Exim, dovecot...?), but there is definitely some header munging happening somewhere. :-(
But as this is a pretty standard Debian Squeeze server, we're for sure not the only ones who will be running against this brick wall.
Second: Even if we assume that "Return-path:" is not RFC-compliant (I didn't verify that), then we will have to look for a server-side solution (outside Roundcube). Any help appreciated how to create a "fixed" magic.mgc file.
Third: It still totally escapes me where this "text/x-mail" recognition is coming from. As I said, the magic.mgc file does not contain this string at all, nor can I find this string in any other file involved in the 'finfo_open' function of PHP. I CAN find it in the source of the Linux command 'file' 5.04 (names.h in ./src), though:
static const struct { char human[48]; char mime[16]; } types[] = { { "C program", "text/x-c", }, { "C++ program", "text/x-c++" }, { "make commands", "text/x-makefile" }, { "PL/1 program", "text/x-pl1" }, { "assembler program", "text/x-asm" }, { "English", "text/plain" }, { "Pascal program", "text/x-pascal" }, { "mail", "text/x-mail" },
^^^^^^^^^^^
{ "news", "text/x-news" }, { "Java program", "text/x-java" }, { "HTML document", "text/html", }, { "BCPL program", "text/x-bcpl" }, { "M4 macro language pre-processor", "text/x-m4" }, { "PO (gettext message catalogue)", "text/x-po" }, { "cannot happen error on names.h/types", "error/x-error" }};
BUT: This is indeed the only place. And the PHP script I created for testing (see attachment to my original post), does not use the Linux 'file' command at all. So again: Does anybody have a clue where "text/x-mail" might be coming from when using the PHP function 'finfo_open'??
In 'file' 5.11 this hardwired token finding has been dropped (at least according to the CHANGELOG), but I didn't have the chance to test a compiled version yet.
So, "fixing" fileinfo is not a good way.
Well, see above. If you know how to "fix" magic.mgc (be it as a temporary solution only), your hints would be most appreciated. At least I'm a bit lost currently.
I suppose we just should support both mimetypes as message/rfc822 in Roundcube. Open a ticket.
I'd do that of course, but currently I wouldn't know how to phrase it, given the facts above. It's more a server issue rather than a Roundcube issue, as it looks for now.
There will be still a question if we should change detected mimetype of uploaded file. In my opinion we should not.
Up to you. Currently I don't have an opinion at all. ;)
Thanks for listening,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany