We're working and testing on this issue for days in the meantime, but to no avail. The issue is:
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.
But, ha...!
You won't probably believe it, but while typing this and after days of research in the net and just looking at the .eml again, it occurs to me, that we can "solve" the problem by changing "Return-path:" to "Return-Path:" in the first line of the .eml source file. All of a sudden the .eml file is correctly detected as "message/rfc822".
Arrgh!?
That can't be true, really, so many lost days... Just because of this "-p" vs. "-P"?!
The message that we were using for testing has apparently been composed with the Google webmailer (which does for whatever reason not set any of the several MUA headers being around, I can just assume this from other headers such as "X-Google-Sender-Auth:").
Anyway, there are still a number of questions open then:
- Our system (Debian GNU/Linux 6.0 Squeeze) is using a compiled magic file
"/usr/share/magic.mgc" with a file size of 1.830.800 Byte, which apparently supports "Return-Path:", but not "Return-path:". Is there any other magic.mgc around which does also support "Return-path:" and which is compatible with our system?
This question arises because I tried to use a magic.mgc which is bundled with the Linux command 'file' 5.11 (while the original 'file' version of Squeeze is 5.04), but we get an error if we try to open it with 'finfo_open()'. Apparently this magic.mgc does also not support "Return-path:" (because it doesn't contain that string), but this experience shows that you can't use any arbitrary magic.mgc found somewhere.
- I can find a plain (non-compiled) text file "/usr/share/mime/magic" on
our system which does apparently support both "Return-Path:" and "Return-path:", but we're getting an error when trying to load it with 'finfo_open'. This is surprising in so far as we can load another plain (also non-compiled) plain text file "/etc/apache2/magic" without a problem (but which does unfortunately also not support "Return-path:", so it doesn't really help as well, unless being edited).
Any idea why 'finfo_open' can load some plain text (non-compiled) magic files, but others not...?
- The biggest of all mysteries: Where do the declaration "text/x-mail" and
the description "ASCII mail text" in the case of "Return-path:" come from at all? These strings are not contained in any of the several (compiled or non-compiled) magic files.
Any useful hints most appreciated!
Ah, and please: Don't advise to add ".eml" to Roundcube's mimetypes.php. We're aware of that, but according to Thomas advice, this is not the right way to go.
To check the difference between the result of an .eml with "Return-Path:" and with "Return-path:", just click on the following link (it may not last forever, so don't be too surprised if it should not work years later):
http://srv217.dedi64.de/mime_test/mime_test.php
PHP test code is attached.
Thanks, cheers (and hoping for helpful hints and answers)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
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. So, "fixing" fileinfo is not a good way. I suppose we just should support both mimetypes as message/rfc822 in Roundcube. Open a ticket. There will be still a question if we should change detected mimetype of uploaded file. In my opinion we should not.
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
Am 27.12.2012 23:53, schrieb Michael Heydekamp:
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, I have the idea. It is Exim (as our MTA) that add the Return-path.
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.
And Exim is the Standard Debian MTA.
But, I have the idea. It is Exim (as our MTA) that add the Return-path.
my MTA is exim@debian/lenny via smarthost I would say that my emails are sent with Return-Path... but you are able to check yourself :-)
Andreas
Am 28.12.2012 11:12, schrieb Andreas Dick:
But, I have the idea. It is Exim (as our MTA) that add the Return-path.
my MTA is exim@debian/lenny via smarthost I would say that my emails are sent with Return-Path... but you are able to check yourself :-)
We can't check how you sent your mail, we can just see how it arrived:
Return-path: dev-bounces@lists.roundcube.net
^
So it's not that easy as you think.
Exim rewrites the header, and it does it by design (for whatever reason) to write it to "Return-path:".
See: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_...
Weird, but a fact.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 28.12.2012 19:54, schrieb Michael Heydekamp:
Am 28.12.2012 11:12, schrieb Andreas Dick:
But, I have the idea. It is Exim (as our MTA) that add the Return-path.
my MTA is exim@debian/lenny via smarthost
Don't you think that lenny is too old to be secure?
I would say that my emails are sent with Return-Path... but you are able to check yourself :-)
...
Exim rewrites the header, and it does it by design (for whatever reason) to write it to "Return-path:".
See: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_...
Weird, but a fact.
And this ist not only in the last exim-version. It is also in 4.69 (your version) and 4.72 (our version).
See:
http://www.exim.org/exim-html-4.69/doc/html/spec_html/ch-generic_options_for... and http://www.exim.org/exim-html-4.72/doc/html/spec_html/ch-generic_options_for...
Am 28.12.2012 23:51, schrieb Martin Wodrich:
Am 28.12.2012 19:54, schrieb Michael Heydekamp:
Am 28.12.2012 11:12, schrieb Andreas Dick:
But, I have the idea. It is Exim (as our MTA) that add the Return-path.
my MTA is exim@debian/lenny via smarthost
Don't you think that lenny is too old to be secure?
is this question serious?
http://www.h-online.com/open/news/item/Debian-GNU-Linux-5-0-Lenny-approaches... "Lenny" will reach its end of life (EOL) on 6 February 2012
so yes it is too insecure since many months
Am 28.12.2012 23:54, schrieb Reindl Harald:
Am 28.12.2012 23:51, schrieb Martin Wodrich:
Am 28.12.2012 19:54, schrieb Michael Heydekamp:
Am 28.12.2012 11:12, schrieb Andreas Dick:
my MTA is exim@debian/lenny via smarthost
Don't you think that lenny is too old to be secure?
is this question serious?
It's an rhetorical question. I know that Lenny is EOL since many month. All my system that runs under Linux are Debian Squeeze oder Wheezy now. And I know: When Wheezy will Release, than there is only one year to Upgrade all Squeeze-Systems to Wheezy.
Am 27.12.2012 23:53, schrieb Michael Heydekamp:
Am 27.12.2012 10:10, schrieb A.L.E.C:
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. :-(
As we know in the meantime, Exim is the guilty one. And: It's even documented! (See previous posts to this subject).
Second: Even if we assume that "Return-path:" is not RFC-compliant (I didn't verify that)
According to RFC 2821, it should indeed read "Return-Path:" (although the text itself contains a lot of matches also for "Return-path" and even "return-path", see https://www.ietf.org/rfc/rfc2821.txt).
But as Exim is widely used, we can't just ignore this behaviour, IMO. (Unbelievable that nobody else did realize this behaviour before.)
then we will have to look for a server-side solution (outside Roundcube). Any help appreciated how to create a "fixed" magic.mgc file.
Still hoping for some help and advice...
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.
And this is still unclear, too. Any clue?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Sat 29/Dec/2012 01:24:24 +0100 Michael Heydekamp wrote:
Am 27.12.2012 23:53, schrieb Michael Heydekamp:
Am 27.12.2012 10:10, schrieb A.L.E.C:
Second: Even if we assume that "Return-path:" is not RFC-compliant (I didn't verify that)
According to RFC 2821, it should indeed read "Return-Path:" (although the text itself contains a lot of matches also for "Return-path" and even "return-path", see https://www.ietf.org/rfc/rfc2821.txt).
The latest RFC specifies it in ABNF like so:
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF> http://tools.ietf.org/html/rfc5321#section-4.4
while RFC 821 used BNF:
<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> http://tools.ietf.org/html/rfc821#page-32
In either case, strings are *case insensitive* and their character set is US-ASCII.
There are several difficulties. Mail files are text files, but local storage may provide for "\n"-terminated lines while transmission requires "\r\n". "Return-Path:" needs not be the very first line, as "Delivered-To:" often happens to be inserted in front of it. Non-delivered messages, e.g. those caught in some sending queue, need not have a Return-Path at all. In general, full rfc5322- and MIME- compliance is hard --and useless-- to check.
Since mail is Roundcube's core business, I'd suggest some custom checks to determine if an attachment is a mail file or headers thereof. For example, what are the key elements for displaying it properly? Otherwise, libmagic maintainers might shred some light on the issue (are they at http://www.darwinsys.com/file/?)
Am 29.12.2012 12:29, schrieb Alessandro Vesely:
On Sat 29/Dec/2012 01:24:24 +0100 Michael Heydekamp wrote:
According to RFC 2821, it should indeed read "Return-Path:" (although the text itself contains a lot of matches also for "Return-path" and even "return-path", see https://www.ietf.org/rfc/rfc2821.txt).
[...]
In either case, strings are *case insensitive* and their character set is US-ASCII.
Oh, is this really the case? If so, then ALL headers (not only Return-Path) should be checked case-insensitive by finfo (which does currently not happen, AFAICS).
Can you point to the statement in any RFC where this is clearly stated? I couldn't find anything in 2821 and it's predecessors/successors. All statements about case (in)sensitivity refer to SMTP commands, local parts and domains only.
Happy new Year,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Mon 31/Dec/2012 12:15:24 +0100 Michael Heydekamp wrote:
Am 29.12.2012 12:29, schrieb Alessandro Vesely:
On Sat 29/Dec/2012 01:24:24 +0100 Michael Heydekamp wrote:
According to RFC 2821, it should indeed read "Return-Path:" (although the text itself contains a lot of matches also for "Return-path" and even "return-path", see https://www.ietf.org/rfc/rfc2821.txt).
[...]
In either case, strings are *case insensitive* and their character set is US-ASCII.
Oh, is this really the case? If so, then ALL headers (not only Return-Path) should be checked case-insensitive by finfo (which does currently not happen, AFAICS).
Right. I'd say case sensitivity, line terminations, and possibly regex support are required for recognizing text files. Libmagic was designed for binary ones.
Can you point to the statement in any RFC where this is clearly stated? I couldn't find anything in 2821 and it's predecessors/successors. All statements about case (in)sensitivity refer to SMTP commands, local parts and domains only.
RFC 2821 is indeed focused on SMTP. RFC 2822 does the message format, and has a corresponding statement about case sensitivity: in http://tools.ietf.org/html/rfc5322#section-1.2.2
Formally, the clear statement is part of the ABNF specification, that both specifications use. It says:
NOTE:
ABNF strings are case insensitive and the character set for these
strings is US-ASCII.
Hence:
rulename = "abc"
and:
rulename = "aBc"
will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC". http://tools.ietf.org/html/rfc5234#section-2.3
Preceding documents, such as RFC 821, RFC 822, and the MIME series of RFCs, refer to the BNF defined in RFC 822 (STD 11), which is also fairly clear, albeit it doesn't mention all possible combinations:
When matching any other syntactic unit, case is to be ignored.
For example, the field-names "From", "FROM", "from", and even
"FroM" are semantically equal and should all be treated ident-
ically.
http://tools.ietf.org/html/std11#section-3.4.7
Am 31.12.2012 15:10, schrieb Alessandro Vesely:
On Mon 31/Dec/2012 12:15:24 +0100 Michael Heydekamp wrote:
Can you point to the statement in any RFC where this is clearly stated? I couldn't find anything in 2821 and it's predecessors/successors. All statements about case (in)sensitivity refer to SMTP commands, local parts and domains only.
RFC 2821 is indeed focused on SMTP. RFC 2822 does the message format, and has a corresponding statement about case sensitivity: in http://tools.ietf.org/html/rfc5322#section-1.2.2
[...]
Thanks for clarifying! So now we know for sure that Exim's behaviour (i.e. creating a header "Return-path:") is perfectly RFC compliant.
From a practical side of view, the still open question for us is: How to
(re)build a fixed magic.mgc which does at least support "Return-Path:", "Return-path:" and "return-path:"?
Plus that finfo is apparently also able to load a plain text file instead of a compiled magic.mgc, but it doesn't load every magic text file that I can find on our server. I will have to dig a little deeper into that issue, unless somebody else can help with more specific information.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 31.12.2012 17:38, schrieb Michael Heydekamp:
From a practical side of view, the still open question for us is: How to
(re)build a fixed magic.mgc which does at least support "Return-Path:", "Return-path:" and "return-path:"?
Besides the original issue: Is it Roundcube or something else that is automatically preceding the string "From " at the beginning of a line with a quote character ">" upon sending?
In know that it must have to do with the mbox specification, but given that we have a header "Content-Length:", this shouldn't be necessary, right?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Mon 31/Dec/2012 17:38:06 +0100 Michael Heydekamp wrote:
From a practical side of view, the still open question for us is: How to (re)build a fixed magic.mgc which does at least support "Return-Path:", "Return-path:" and "return-path:"?
libmagic provides for case insensitive comparisons. For file-5.12, the latest version, there are "c" and "C" switches that make the comparison fully case insensitive. For file-5.04, the version on debian squeeze, only "c" seems to be provided, hence it would be necessary to rewrite the magic test string in all-lowercase.
BTW, that spurious text/x-mail mime type has been removed from the source in file-5.10. The resulting behavior is equivalent to using MAGIC_NO_CHECK_TOKENS. PHP doesn't define such constant, but it is defined as 0x100000 in src/magic.h. What happens if you run, say,
php -r '$f=new finfo(FILEINFO_MIME|0x100000); print $f->file("YOUR.eml")."\n";'
(Although I have file-5.04 too, on debian squeeze, I'm unable to get text/x-mail: I get text/plain for "Return-path:".)
Plus that finfo is apparently also able to load a plain text file instead of a compiled magic.mgc, but it doesn't load every magic text file that I can find on our server. I will have to dig a little deeper into that issue, unless somebody else can help with more specific information.
What PHP version does roundcube require? According to the Notes at http://php.net/manual/en/function.finfo-open.php , PHP >= 5.3.11 and
= 5.4.1 upgraded to libmagic 5. However, slight changes in the
format of the magic file are possible even between minor versions.
Alessandro,
first of all thanks a lot for your comprehensive response. I have to admit that I'm not such an expert in this area as you may believe. So some of my comments and questions may sound pretty dumb to you. Ok, here we go:
Am 03.01.2013 17:41, schrieb Alessandro Vesely:
On Mon 31/Dec/2012 17:38:06 +0100 Michael Heydekamp wrote:
From a practical side of view, the still open question for us is: How to (re)build a fixed magic.mgc which does at least support "Return-Path:", "Return-path:" and "return-path:"?
libmagic provides for case insensitive comparisons. For file-5.12, the latest version, there are "c" and "C" switches that make the comparison fully case insensitive. For file-5.04, the version on debian squeeze, only "c" seems to be provided, hence it would be necessary to rewrite the magic test string in all-lowercase.
Here's my first dumb question: What exactly is the connection between the PHP function 'finfo' and the Linux command 'file'? Does 'finfo' internally use the output of the 'file' command?
I thought 'finfo' would be a separate (PHP) function, fully independent of 'file'?!
BTW, that spurious text/x-mail mime type has been removed from the source in file-5.10.
I know, I have the sources of file-5.11 on our system as well (see my post to this list of 27.12.2012, 23:53).
But when I run a compiled file-5.11 against an .eml with "Return-path:" in the first line, it produces the same result as file-5.04: "text/x-mail" Stunning...
The resulting behavior is equivalent to using MAGIC_NO_CHECK_TOKENS. PHP doesn't define such constant, but it is defined as 0x100000 in src/magic.h. What happens if you run, say,
php -r '$f=new finfo(FILEINFO_MIME|0x100000); print $f->file("YOUR.eml")."\n";'
Although I don't understand what I'm (and this command is) exactly doing, the result is:
"text/plain"; charset=us-ascii"
So not "text/x-mail" anymore, but also still not "message/rfc822".
If I replace file-5.04 with file-5.11 and run the command above, I get the same "text/plain" result.
(Although I have file-5.04 too, on debian squeeze, I'm unable to get text/x-mail: I get text/plain for "Return-path:".)
Strange. Probably because of a different magic.mgc file...?
Plus that finfo is apparently also able to load a plain text file instead of a compiled magic.mgc, but it doesn't load every magic text file that I can find on our server. I will have to dig a little deeper into that issue, unless somebody else can help with more specific information.
What PHP version does roundcube require?
According to http://www.roundcube.net/about: PHP Version 5.2.1 or greater
According to the Notes at http://php.net/manual/en/function.finfo-open.php, PHP >= 5.3.11 and >= 5.4.1 upgraded to libmagic 5.
Well, we're running 5.3.3-7+squeeze14 with Suhosin-Patch (cli), AFAICS.
However, slight changes in the format of the magic file are possible even between minor versions.
Yeah, but I have no idea how to compile a magic.mgc at all (which text file I have to use as a basis, where to get the latest one, what exactly to do with it, etc. pp.).
But anyway, thanks again!
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Hi Michael,
On Thu 03/Jan/2013 21:01:41 +0100 Michael Heydekamp wrote:
first of all thanks a lot for your comprehensive response.
You're welcome.
I have to admit that I'm not such an expert in this area as you may believe.
Neither am I :-)
Am 03.01.2013 17:41, schrieb Alessandro Vesely:
On Mon 31/Dec/2012 17:38:06 +0100 Michael Heydekamp wrote:
From a practical side of view, the still open question for us is: How to (re)build a fixed magic.mgc which does at least support "Return-Path:", "Return-path:" and "return-path:"?
libmagic provides for case insensitive comparisons. For file-5.12, the latest version, there are "c" and "C" switches that make the comparison fully case insensitive. For file-5.04, the version on debian squeeze, only "c" seems to be provided, hence it would be necessary to rewrite the magic test string in all-lowercase.
Here's my first dumb question: What exactly is the connection between the PHP function 'finfo' and the Linux command 'file'? Does 'finfo' internally use the output of the 'file' command?
Since file-4.00 the package features libmagic, and the file command is implemented as a client of that library. PHP uses libmagic as well. See http://en.wikipedia.org/wiki/File_%28command%29
BTW, that spurious text/x-mail mime type has been removed from the source in file-5.10.
I know, I have the sources of file-5.11 on our system as well (see my post to this list of 27.12.2012, 23:53).
But when I run a compiled file-5.11 against an .eml with "Return-path:" in the first line, it produces the same result as file-5.04: "text/x-mail" Stunning...
I submitted a patch to fix that right now: http://bugs.gw.com/view.php?id=226 (I had tried before, vie email, but their mailing list seems to dislike attachments.) Maybe it will arrive with file-5.13?
The resulting behavior is equivalent to using MAGIC_NO_CHECK_TOKENS. PHP doesn't define such constant, but it is defined as 0x100000 in src/magic.h. What happens if you run, say,
php -r '$f=new finfo(FILEINFO_MIME|0x100000); print $f->file("YOUR.eml")."\n";'
Although I don't understand what I'm (and this command is) exactly doing, the result is:
"text/plain"; charset=us-ascii"
That's equivalent to issuing "file --exclude tokens". That way you rely on magic files only, smoothing the transition through file-5.10.
So not "text/x-mail" anymore, but also still not "message/rfc822".
If I replace file-5.04 with file-5.11 and run the command above, I get the same "text/plain" result.
Yes, investigating a text/plain file further, in order to determine if it is of type message/rfc822, text/rfc822-headers, or text/news would seem safer than dealing with text/x-mail.
(Although I have file-5.04 too, on debian squeeze, I'm unable to get text/x-mail: I get text/plain for "Return-path:".)
Strange. Probably because of a different magic.mgc file...?
Or just a different .eml.
Plus that finfo is apparently also able to load a plain text file instead of a compiled magic.mgc, but it doesn't load every magic text file that I can find on our server. I will have to dig a little deeper into that issue, unless somebody else can help with more specific information.
What PHP version does roundcube require?
According to http://www.roundcube.net/about: PHP Version 5.2.1 or greater
Hm... that leaves a too wide choice of magic.mgc possible formats.
According to the Notes at http://php.net/manual/en/function.finfo-open.php, PHP >= 5.3.11 and >= 5.4.1 upgraded to libmagic 5.
Well, we're running 5.3.3-7+squeeze14 with Suhosin-Patch (cli), AFAICS.
Same here. Obviously, it's easier to target a specific version, especially if recent.
However, slight changes in the format of the magic file are possible even between minor versions.
Yeah, but I have no idea how to compile a magic.mgc at all (which text file I have to use as a basis, where to get the latest one, what exactly to do with it, etc. pp.).
That should be "file -C -m magic". If you build from sources, you can just issue "make" after altering any magic/Magdir/*.
Ciao Ale
A.L.E.C wrote:
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. So, "fixing" fileinfo is not a good way.
I think fileinfo is a bit too picky about the message/rfc822 detection and maybe it's worth the effort to forward this report to them.
both mimetypes as message/rfc822 in Roundcube. Open a ticket. There will be still a question if we should change detected mimetype of uploaded file. In my opinion we should not.
The easiest way for us would be to add an alias for text/x-mail => message/rfc822 after uploaded file type detection. The more sustainable solution would be to consider both mimetypes when parsing the message structure and rendering the contents. Maybe run all message part mimetypes through rcmail_fix_mimetype()?
~Thomas
-
A.L.E.C -
Alessandro Vesely -
Andreas Dick -
Martin Wodrich -
Michael Heydekamp
-
Reindl Harald -
Thomas Bruederli