APPEND size limit

Janne Peltonen janne.peltonen at
Fri Sep 20 03:36:49 EDT 2013


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:

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:

. append INBOX {4294967296}
* BYE Fatal error: num too big

OK, so at least the IMAP protocol limit is respected (4GB > 4GB - 1B).


. append INBOX {4294967295}
+ go ahead

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

More information about the Info-cyrus mailing list