[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cyrus-info
Subject:    Re: Excessive APPENDLIMIT response [Re: Android after Cyrus upgrade]
From:       Sebastian Hagedorn <Hagedorn () uni-koeln ! de>
Date:       2023-05-16 17:55:08
Message-ID: 19E6482B-7A1C-4CC1-B4B8-AFB29C1AD1C2 () uni-koeln ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/alternative)]


On 15 May 2023, at 2:46, ellie timoney wrote:

> 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

Thanks, that works!

Cheers,
Sebastian
-- 
   .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.13.:.
                .:.Regionales Rechenzentrum (RRZK).:.
  .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.


[Attachment #7 (text/html)]

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="plaintext" \
style="white-space: normal;"><p dir="auto">On 15 May 2023, at 2:46, ellie timoney \
wrote:</p> <blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px \
solid #777777; color: #777777;"><p dir="auto">On Fri, 12 May 2023, at 11:50 PM, \
Sebastian Hagedorn wrote:</p> <blockquote style="margin: 0 0 5px; padding-left: 5px; \
border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p \
dir="auto">On 12 May 2023, at 7:15, Vladas Palubinskas via Info wrote:</p> \
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid \
#777777; border-left-color: #BBBBBB; color: #BBBBBB;"><p dir="auto">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.</p> </blockquote><p dir="auto">I can confirm that *setting* \
maxmessagesize to something leads to the "unlimited" value in 3.6.1.</p> <p \
dir="auto">Without maxmessagesize in imapd.conf:</p> <p \
dir="auto">APPENDLIMIT=4294967295</p> <p dir="auto">With maxmessagesize: 52428800 in \
imapd.conf:</p> <p dir="auto">APPENDLIMIT=18446744071562067968</p>
</blockquote><p dir="auto">That isn't actually the "unlimited" value, which is \
weird...</p> <p dir="auto">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.</p> <p dir="auto">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.</p> <p dir="auto">This happens around line 911 of \
imap/imapd.c in service_init():</p> <p dir="auto">    maxsize = \
config_getint(IMAPOPT_MAXMESSAGESIZE) * 1024; <br>
    if (!maxsize) maxsize = UINT32_MAX;</p>
<p dir="auto">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:</p> <p dir="auto">    maxsize = \
config_getint(IMAPOPT_MAXMESSAGESIZE); <br>
    if (!maxsize) maxsize = UINT32_MAX;</p>
<p dir="auto">I'll get a proper, tested, fix for this together soon.  Tracking this \
on GitHub as <a href="https://github.com/cyrusimap/cyrus-imapd/issues/4506" \
style="color: #777777;">https://github.com/cyrusimap/cyrus-imapd/issues/4506</a></p> \
</blockquote><p dir="auto">Thanks, that works!</p> <p dir="auto">Cheers,
<br>
Sebastian
<br>
-- 
<br>
   .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.13.:.
<br>
                .:.Regionales Rechenzentrum (RRZK).:.
<br>
  .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.</p>
</div>

</div>
</body>

</html>


["smime.p7s" (smime.p7s)]

0	*H
 010
	`He0	*H
 00 	%ف0
	*H
010	UDE1+0)U
"T-Systems Enterprise Services GmbH10UT-Systems Trust \
Center1%0#UT-TeleSec GlobalRoot Class 20 160222133822Z
310222235959Z010	UDE1E0CU
<Verein zur Foerderung eines Deutschen Forschungsnetzes e. \
V.10UDFN-PKI1-0+U$DFN-Verein Certification Authority 20"0 	*H
0
`fAsMg9Z`GNWKVlUvFEc>pԫT#7(	]Ę7 \
fx J2)y T_Jx4twMYZ/l<5e \
2mZjKb84YE6Ixjm[k<q;gz6N)=Q\4 \
u9i%=+;U*^3	1FkYt0p0U0U2&JJK0U#0Y \
6y  "kaҸ,˂J0U003U ,0*0 +!,0
+!,0g0LUE0C0A ? \
=;http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl0+z0x0,+0 \
http://ocsp0336.telesec.de/ocspr0H+0<http://pki0336.telesec.de/crt/TeleSec_GlobalRoot_Class_2.cer0
 	*H
>eV-;qOں)!F.8y8tv]bL3j2,LG`Utk,ykMPf0"rM>[ϙR9.D~i;u;"lGG \
4}=wMOY>GJXoB.M<I&6,"͋xU;DRiТSW{$Jer900 \
c,=0 	*H
010	UDE1E0CU
<Verein zur Foerderung eines Deutschen Forschungsnetzes e. \
V.10UDFN-PKI1-0+U$DFN-Verein Certification Authority 20 160524113840Z
310222235959Z010	UDE1E0CU
<Verein zur Foerderung eines Deutschen Forschungsnetzes e. \
V.10UDFN-PKI1%0#UDFN-Verein Global Issuing CA0"0 	*H
0
;yGi9٢0r)_KhLk{-n:WQ6pmc \
.@уLf=di囤rh9QyӮ/]cqK9zBi@p翞MGH_e*I-?T/:W~xJA}S_ȳ*0$? \
MR 6$eǖs$hYv~ \
x<K7S:8Gmd=<ZEJʀ|LL00U00U0)U \
"0 0 +!,0
+!,0Uk:S୲2	;t0U#02&JJK0U00@ \
> <:http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl0@ > \
> <:http://cdp2.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl0+003 \
> +0'http://ocsp.pca.dfn.de/OCSP-Server/OCSP0J+0>http://cdp1.pca.dfn.d \
> e/global-root-g2-ca/pub/cacert/cacert.crt0J+0>http://cdp2.pca.dfn.de/global-root-g2-ca/pub/cacert/cacert.crt0
> 
	*H
xENU	j>xh5?k8w,> \
̨3$b6LxnPn`OR1CFubnfQB1gPI9˟ʆHK+f \
8W-L_>\)9l{F8ܰ?q3 Hc%%<z{Wn8 \
/[Kl=w3Sv&%Ao/|~`]A \
aI)ب-uJU4"00 #y}b0 	*H
010	UDE1E0CU
<Verein zur Foerderung eines Deutschen Forschungsnetzes e. \
V.10UDFN-PKI1%0#UDFN-Verein Global Issuing CA0 200910135209Z
230910135209Z0z10	UDE10UKoeln10U
Universitaet zu Koeln10URRZK, Abteilung Netze10USebastian \
Hagedorn0"0 	*H
0
-|f
T	ǔ%wwLWc&G1M[ezե
fC+`%,^Œ谘g֜9D_BtNlҰIu.^ E7rFH6`WTdQ
V1wy!Bxo?&*m xB2С=uU \
(:hB)w^	QӗbC,yܜ7S . HN0J0>U \
7050 +!,0+!,0+!,0	U00U0 \
U%0++0U5.RpD6dNtF0U#0k:S୲2	;t0 \
U0Hagedorn@uni-koeln.de0U00? = \
;9http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl0? = \
;9http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl0+003+ \
0'http://ocsp.pca.dfn.de/OCSP-Server/OCSP0I+0=http://cdp1.pca.dfn.de/dfn \
-ca-global-g2/pub/cacert/cacert.crt0I+0=http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.crt0
 	*H
wurYuF$12(Zf~Rx8&fKoQ`PToVa|zzNjo'K-ox \
_8Nڍk*6>h|BVruQd}UFYM-D5n-[ޱ|#yN{-e똊r&"1<( \
eAyT^./EfT~~-;Q \
8]WSW7UpaTJZO1R0N0010	UDE1E0CU  <Verein zur \
Foerderung eines Deutschen Forschungsnetzes e. \
V.10UDFN-PKI1%0#UDFN-Verein Global Issuing CA#y}b0 \
	`He 0	*H 	1	*H
0/	*H
	1" `I)cXCLKP'`3]J`"*_oG08	*H
	1+0)0	`He0
*H
0*H
0
	*H
QNԈJ 	>5_gO5 \
u}jn,7́[MI㏶#R$<܄oa`0`,8gDkJ \
}M9I~"b'~3Cn5wVg \
fr"EB<(M}	Ũ:'F:.O?3n#mٷ \
7@+rlMoPҏ^t4ެMoQAhF_



This is a multi-part message in MIME format...

------------=_1684259722-776615-1--


[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic