alecpl
commented
5 years ago You're right that this is most likely caused by the thumbnail generation code. There are some things to consider:
- number of attachments should be irrelevant as every image is handled by a separate http request,
- what PHP version? PHP7 should have lower memory consumption. I never saw cases where it takes hundreds of megabytes, so might be a bug somewhere,
- I think it's not really related with the attachment size (in bytes), but the resolution or format. I remember from the past some cases where very small image required a lot of memory,
- there's possibility to use Imagick instead of gd, install Imagick on the server and test with that (it can be via php extension or a standalone program, see
im_convert_path/im_identify_pathin config). - there's
image_thumbnail_size(default:240) setting, but I don't think changing the value will help in any way.
TL/DR ;) we can consider making image_thumbnail_size=0 a special setting to disable resizing.
Using roundcube 1.3.4 in a docker container as part of jeboehm's implementation of ispmail.
If I enable the inline_images option (in settings, perferences, displaying images, "Display attached images below the message") then when viewing some emails with multiple (3 or more, say) large (1.2MB plus) jpegs attached, the php-fpm process on the server blows out in memory usage - I saw it get to about 380MB before my server wedged, until oom-killer stepped in.
I found some other bugreports that seemed somewhat related but most seemed to deal with the sending side of things.
When I de-select the inline_images option the emails display fine, and the attachment viewer window works fine. Obviously that's a suitable workaround, but it would be nice to be able to display the images inline if possible.
I note that the inline_images option I think is off by default, so this is "my own fault" for turning it on :-) Near as I can tell RC is trying to scale the images to display them inline, and the memory use is perhaps related to that (GD?). If it results in lower server load, I'd be happy for it to just be sending the full-size image to my browser and letting it handle resizing (perhaps setting width/height attributes on the img tag) rather than putting that burden on the server. That wouldn't suit everyone, I guess, but whether it's a 100kb jpeg or an 80MB TIFF file, I'd rather the server just serve it and not try to pre-process a thumbnail or preview size image.
Is this a security vulnerability as well, since a malicious user could send themselves a huge image and display it inline, exhausting server memory?
Am I missing something else here that solves it, or is this just a tradeoff between user convenience and server load?
TL/DR: Perhaps make the option "Display attached images below the message" not re-scale the images (just serve them at full-size), and have an option under that for "Resize images for inline display (Warning: may result in higher server memory use)" or similar, default to off. Actually that option might be a global config rather than a user setting.