View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003135||SOGo||Web Mail||public||2015-03-17 13:36||2016-02-16 21:29|
|Platform||[Server] Linux||OS||RHEL/CentOS||OS Version||6|
|Target Version||2.3.7||Fixed in Version||2.3.9|
|Summary||0003135: Attachment size restriction|
We have a mailsize restriction on our SMTP smarthosts that are running postfix. Our SOGo cluster sends all mail to our SMTP smarthosts. To avoid problems with email incompatible email sizes we would like to have SOGo enforce a max message size.
When I tried to send an email with an attachment bigger than the max message size that is enforced on our SMTP smarthosts I got the error shown in the attached file. In this situation it would be nice to have SOGo enforce a max message size and give the user an apropriate error message.
|Steps To Reproduce|
1) Send an email with a big attachment (bigger that max allowed by SMTP smarthosts)
|Tags||No tags attached.|
sogo-cannot-send.png (95,479 bytes)
sogo-cannot-send.png (95,479 bytes)
This is still a problem for us. We have quite a lot of users and some of them try to upload big files (several hundred megs) from time to time. This is problematic for our webmail cluster because SOGo cannot enforce a max filesize for upload.
We have tested uploading a 1gb file to see what actually happens when a user tries to upload a big file. What we observed is that SOGo stores the file in memory during upload and will eventually start swapping if the file is big enough. When the upload fails the partially uploaded file is usually found in /tmp/ in a file named OGo*.tmp.
We have had problems with both excessive swapping and full disks because SOGo does not enforce a max filesize for upload. We are in need of a way to enforce a max filesize for attachment uploads in SOGo. Can you please implement such a feature?
To set the size of our webmail cluster in perspective we have 26.000 unique users daily and 46.000 unique users weekly.
Unless I misunderstand your issue, this is not a bug of SOGo. Nor a valid RFE. The max message size limits shoul dbe set in two places. (i) on the smtp server (Postfix, for example has this setting). (ii) in the web server (Apache and Nginx both have this support). In fact, it's quite bad practice to not have a request size restriction on your web server. It leaves you open to basic DDOS attacks.
I use Nginx and below are my relevant settings. Look at the send and read timeouts, and the client_max_body_size. So my web clients are allowed 90 seconds before they time out, that's feasible on anything but a really slow connection. Also, the max file upload size is 50MB. I set max to 100MB both directions on my MTA (SMTP), but less for webmail, since it's less efficient than say Thunderbird. It's importnant to note that attachments are base64 encoded (to ASCII), so they will increase in size by about 30%. So, a 10MB attached file will roughly equal a 13MB email.
It's strange, usually it's the other way around, I had to increase these. Nginx has very conservative default values for these timeouts and max body size.
forward user's IP address
Yes, we are aware that such restrictions can be set in the httpd daemon, but that gives a bad user experience. When a user selects a file to be uploaded that is too big the user should get an error from SOGo telling him/her that the file is too big. In such a case the user is given a sensible error message immediately.
If you rely on the httpd daemon to set upload restrictions the user uploads his/her file until the limit is reached. When the limit is reached the user is in effect taken away from the SOGo webmail and is given an error message that is whatever the httpd daemon gives. In our opinion this is a bad user experience. The fileupload seems to work and then fails after uploading for some time. And when it fails the user is given an error that is not a part of the SOGo UI.
Having SOGo checking the filesize against a configurable max attachment size on the selected file before upload starts will solve this problem. Giving users error messages within the SOGo UI is strongly preferable.
Yes, you are correct. And I agree, this is a plausable RFE. However, a suitable httpd deamon restriction should be made for other reason, like DOS.
I guess since all my users know we have a send size limitation, and that most other mail server receive limitations are much lower than ours, it's not a n issue for me. For anybody that does something stupid, like attach a 200MB PDF, well tough, learn the hard way. But you're right, it should have a friendly error message before it even starts to upload.
+1 for me to add this as a feature. However, it's not really high priority.
Good, then we agree. It would be nice to have an error message in SOGo for uploading files that are too big and having a limit in the httpd daemon that is there to prevent abuse.
|2015-03-17 13:36||Altibox||New Issue|
|2015-03-17 13:36||Altibox||File Added: sogo-cannot-send.png|
|2015-06-16 11:25||Altibox||Note Added: 0008648|
|2015-06-16 11:26||Altibox||Note Edited: 0008648|
|2015-06-16 17:28||ludovic||Target Version||=> 2.3.2|
|2015-09-16 19:20||ludovic||Target Version||2.3.2 => 2.3.3|
|2015-11-11 14:23||ludovic||Target Version||2.3.3 => 2.3.4|
|2015-11-19 11:36||ethoms||Note Added: 0009105|
|2015-11-19 11:48||Altibox||Note Added: 0009106|
|2015-11-19 12:49||ethoms||Note Added: 0009108|
|2015-11-19 12:53||Altibox||Note Added: 0009109|
|2015-12-16 16:08||ludovic||Target Version||2.3.4 => 2.3.5|
|2016-01-07 14:56||ludovic||Target Version||2.3.5 => 2.3.6|
|2016-01-18 18:20||ludovic||Target Version||2.3.6 => 2.3.7|
|2016-02-16 21:29||ludovic||Status||new => resolved|
|2016-02-16 21:29||ludovic||Fixed in Version||=> 2.3.9|
|2016-02-16 21:29||ludovic||Resolution||open => fixed|
|2016-02-16 21:29||ludovic||Assigned To||=> ludovic|
|2016-02-16 21:29||ludovic||Note Added: 0009555|