On Fri, 12 May 2023, at 11:50 PM, Sebastian Hagedorn wrote:
On 12 May 2023, at 7:15, Vladas Palubinskas via Info wrote:
Thank you for the very clear explanation, but then I do not quite catch why the reverse happened: why FairEmail got my limit backwards — why maxmessagesize: 2097152 in imapd.conf acted as refused infinity, and almost infinite maxmessagesize: false accepted as a reasonable default value.
I can confirm that setting maxmessagesize to something leads to the "unlimited" value in 3.6.1.
Without maxmessagesize in imapd.conf:
APPENDLIMIT=4294967295
With maxmessagesize: 52428800 in imapd.conf:
APPENDLIMIT=18446744071562067968
That isn't actually the "unlimited" value, which is weird...
Ahh... in 3.6 (and probably earlier), maxmessagesize is interpreted as bytes by LMTP, but as kilobytes by APPEND. Which means your "maxmessagesize: 52428800" is ~50MB by LMTP, but ~50GB by APPEND. I think this bug has existed for a while, and the new APPENDLIMIT output is just making it visible now.
When APPEND misinterprets it as kilobytes, it multiplies it by 1024 to "convert it" to bytes. It does that multiplication in 32 bits, which overflows to negative probably, but then stores the result in a size_t, which treats it as a massive positive value.
This happens around line 911 of imap/imapd.c in service_init():
maxsize = config_getint(IMAPOPT_MAXMESSAGESIZE) * 1024;
if (!maxsize) maxsize = UINT32_MAX;
Without actually having tested anything yet, I think if you just remove that * 1024 and recompile/reinstall/restart, it'll start behaving. That is, make these lines say:
maxsize = config_getint(IMAPOPT_MAXMESSAGESIZE);
if (!maxsize) maxsize = UINT32_MAX;
I'll get a proper, tested, fix for this together soon. Tracking this on GitHub as https://github.com/cyrusimap/cyrus-imapd/issues/4506
Cheers,
ellie
