View Issue Details

IDProjectCategoryView StatusLast Update
0003135SOGoWeb Mailpublic2016-02-16 21:29
ReporterAltibox Assigned Toludovic  
Status resolvedResolutionfixed 
Platform[Server] LinuxOSRHEL/CentOSOS Version6
Product Version2.2.16 
Target Version2.3.7Fixed in Version2.3.9 
Summary0003135: 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)

TagsNo tags attached.




2015-03-17 13:36


sogo-cannot-send.png (95,479 bytes)   
sogo-cannot-send.png (95,479 bytes)   


2015-06-16 11:25

reporter   ~0008648

Last edited: 2015-06-16 11:26

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.



2015-11-19 11:36

reporter   ~0009105

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.

location ^~/SOGo
proxy_redirect default;

forward user's IP address

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header x-webobjects-server-protocol HTTP/1.0;
    proxy_set_header x-webobjects-remote-host;
    proxy_set_header x-webobjects-server-name $server_name;
    proxy_set_header x-webobjects-server-url $scheme://$host;
    proxy_set_header x-webobjects-server-port $server_port;
    proxy_connect_timeout 90;
    proxy_send_timeout 90;
    proxy_read_timeout 90;
    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;
    client_max_body_size 50m;
    client_body_buffer_size 128k;


2015-11-19 11:48

reporter   ~0009106

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.



2015-11-19 12:49

reporter   ~0009108

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.



2015-11-19 12:53

reporter   ~0009109

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.



2016-02-16 21:29

administrator   ~0009555

Issue History

Date Modified Username Field Change
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