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.

location ^~/SOGo
{
proxy_pass http://192.168.10.5:20000;
proxy_redirect http://192.168.10.5:20000 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 192.168.10.5;
    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;
    break;
  }

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.

https://github.com/inverse-inc/sogo/commit/32bb1456e23a32c7f45079c3985bf732dd0d276d