On Mon, 2008-11-24 at 19:13 +0200, Gokdeniz Karadag wrote: > >> > fatal: main.cf configuration error: mailbox_size_limit is smaller > >> > than message_size_limit > >> > > >> > A limit of 2147483648 - 1 worked fine. > >> > > >> > There are two distinct bugs probably, one in postfix and one in > >> > dovecot. > > > > Postfix clearly is using signed 32bit integer here, which could be > > considered a bug. But why do you think there's a bug in Dovecot? Note > > that Dovecot never even sees this value. It's the kernel that enforces > > it, Dovecot simply reacts to a write() failure. > > The logs stating the "File too large" errors belong to dovecot's deliver > process. While I was searching for a solution, I read that deliver honors > mailbox_size_limit setting of postfix, I'm not sure if that is correct or not.
It's kind of correct, but not really. What happens is: 1. Postfix reads the mailbox_size_limit setting. 2. Based on the setting Postfix calls setrlimit(RLIMIT_FSIZE) function to tell kernel the maximum file size for the process and child processes. This is similar to running "ulimit -f mailbox_size_limit" on shell before running deliver. 3. Postfix executes deliver. deliver is in no way aware of the mailbox_size_limit setting or that there is any kind of a limit. It simply tries to write to a file, which fails with EFBIG. > If postfix sets file size limit with ulimit before execing deliver, OR uses a > similar process which is out of deliver's control, then there is nothing > concerning dovecot. If someone can clarify the issue I would be happy. Yes, this is the case.
signature.asc
Description: This is a digitally signed message part
