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
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev
