Am 18.11.2012 15:36, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Even more funny: The link "Show" does not appear in all messages with image attachments which have been produced by ... tadaa ... Roundcube. The same applies to the function of displaying them in a separate browser window upon clicking on the thumbnail.
I see one of your messages to the list where all the image attachments having Content-Type: application/octet-stream instead of image/jpeg or whatever.
That's true, but that can't be the cause of the problem, IMO. Because:
This is also the reason why those attachment are not detected as images and thus no thumbnails are displayed and no inline viewing is offered.
Then you misunderstood: They ARE detected as images by Roundcube, as the thumbnails ARE being displayed (and as in 0.8.4 the images are displayed in full size below the message preview).
It's just the link "Show" that is missing if "application/octet-stream" is declared in the Content-Type: header of image attachments! Plus that clciking on the thumbnail does download the image rather than viewing it.
But if they are already detected as images apparently, why not provide the "Show" link then?
Roundcube tries to detect the mimetypes of uploaded attachment files and this again depends on your server's environment and configuration:
First, there is a mapping file in <roundcubedir>/config/mimetypes.php for simple filename extension to mimetype mapping.
The file is there, but it doesn't contain any of the typical image extensions. We just took it 'as is', means we didn't change anything and are using the default config of Roundcube. Did we do wrong...?
From my point of view, if Roundcube should really rely on a different
Content-Type for image attachments (which I doubt, see above), then the appropriate extensions and Content-Type declarations should be added to this file - but by default.
Second, check the 'mime_magic' option which should point to a valid mime description file on your server which is used by PHP fileinfo extension (http://www.php.net/manual/en/book.fileinfo.php).
And third, Roundcube tries mime_content_type() which again is a function provided by PHP.
An easy fix is to add entries for image file extensions to your local confog/mimetypes.php file. But try to fix the 'mime_magic' path first.
This I will of course check.
But again: The detection should not (und IMO does not) rely on a certain Content-Type declaration. Otherwise Roundcube wouldn't even display the thumbnails.
Plus that any change for future outgoing messages wouldn't help for already existing messages in the INBOX - which may have been produced by any MUA.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany