I've just tested with the latest v2 release and I cannot reproduce the issue with the exact same settings you have.

Can you make sure it's not your SMTP server that is rejecting the mail?

I have checked my SMTP server, and he doesn't get any emails, while those blocks occur.
Which is what I expect SOGo to do , when the limits are reached.
Therefore, he can not reject them.

Also the problem vanished the moment I commented those settings out and restarted sogod.

As this only happens with attachments, we have also set
SOGoMailSpoolPath = "/var/sogotemp";
Attachments are stored there.
Could this cause it?

Well, can SOGo write to that directory?

It's hard for me to figure out what could be wrong.

Do you have a test system on which you can reliably reproduce the issue?

We will look at it and fix it ASAP if so.

We have the same problem with the SOGoMaximumMessageSizeLimit feature since it's introduction in the v2 seri (2.3.19)

As the users were used to have the popup with the MTA message before, we revert to the previous conf.

Hope it could help.

SOGo can write to this directory and it does.

ls -ld /var/sogotemp/

drwxr-xr-x 5466 sogo sogo 270336 Jun 16 19:20 /var/sogotemp/

Sadly I do not have a working V2 test setup right now.
Will get one working next week.

Sorry it took so long.

I have set up the Test system.
There the behavior is a tad different.
The first email can always be send.
But the second email will always trigger the block.

Will send you the access infos per private email.