Hi! I recently ran into a problem: my Cyrus server that had been running with lots of free memory suddenly committed 3GB of memory at once - which drove the server way over its core size. Result: thousands of Cyrus processes waiting for their turn and a complete loss of responsiveness. Trying to find out what could have caused this, I considered the possibility that a user would've tried to send a message with a size of 3 GB. This would fail because our outgoing SMTP servers have a limit of 50 MB message size. But the mail client could still try to APPEND the message to a folder via IMAP. And the message would go to core first, wouldn't it? Trying to find out whether there was any limit to APPEND in Cyrus other than the protocol defined 4GB - 1B, I found this discussion on imap-protocol: http://mailman2.u.washington.edu/pipermail/imap-protocol/2005-November/000085.html Apparently, the thread ended with no decision to add any MAXAPPEND capabilities. But there was also this comment from Ken Murchison: "Cyrus has a limit of somewhere around 102MB, just as a design decision (so I'm told)." But the discussion was from the year 2005 and things may well have changed. I didn't find anything in the changelogs. So I tried with imtest: --clip-- . append INBOX {4294967296} * BYE Fatal error: num too big --clip-- OK, so at least the IMAP protocol limit is respected (4GB > 4GB - 1B). But: --clip-- . append INBOX {4294967295} + go ahead --clip-- Of course, I didn't follow that with 4GB - 1B of data. (Didn't want to break my system again in case Cyrus would've tried to read all of that in core.) But now I'd like to ask someone who knows: 1) Is the 102MB message size limit disappeared altogether, or is Cyrus just saying it will accept a message of 4GB - 1B? 2) If Cyrus no longer limits the message size by default (except the protocol limit), is there any way to explicitely define a limit that would result to a NO response to a client? I didn't find anything in man imapd.conf (other than the LMTP maxmessagesize setting, which obviously wouldn't apply here). 3) If not, would Cyrus break horribly if I were to add a system limit to the core size of Cyrus processes? Thanks for any answers! Janne Peltonen University of Helsinki ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
