I'd like to ask a question about mailboxes.

Our system is running Linux kernel 4.8.10, MTA is sendmail 8.15.2 with
procmail 3.22, all filesystems are ext3, all mailboxes are in the Berkeley format.

A user reported that he could not receive e-mails from some hosts occasionally (including the local mail server itself) for a couple of days.

The problem was reproducible. It was found that whenever the problem occurred, the sender received a bounce message from MAILER-DAEMON@<domain-name> containing lines like :

# ----- The following addresses had permanent fatal errors -----
# <user-name@domain-name>
# (reason: Can't create output)
#
# ----- Transcript of session follows -----
# procmail: Error while writing to "/home/user-name/inbox"
# 550 5.0.0 <user-name@domain-name>... Can't create output

This looks as if the user had his disk quota exceeded, but it was not the case.

In examining the user's mail folders, I found that his "inbox" had grown unhealthily large.
His account disk quota is 3.25GB. The size of his "inbox" was about 2.84GB, containing nearly 5000 messages. The total size of other files was negligible.

The problem was solved by renaming the "inbox" to something else and creating an empty one from scratch.

I guess there may be limitations on the file size or number of messages in Berkeley mailboxes.
If this is true, then what exactly are those limitations ?

#1 Postfix has mail and mailbox limits. Run and see what those are. You may have bumped up against that limit.

#2 Ext3 has limits of two kinds. The absolute limit is huge and you are nowhere near that limit. At around 5000 files the list/search functions start to cause some processes to time out finding a file or file slot. I migrated to Ext4 long ago to avoid this, but it only moves the limit up but does not change the nature of the limit.

I would not worry about the absolute limits on the file system. I would worry about the software limit settings and practical limits. It would not be unreasonable to set a process to check the mailbox size (bytes and files) and if it was over half of what would cause failure generate a warning to the user that it is time to clean up or archive mail from that mailbox.

I haven't looked at the BDB format in ages, but "2.4 GB" rings a bell: that's (2 ^ 31) - 1 = 2,147,483,647. If the position-indicator were a 32-bit signed integer, that integer would now be overflowing. Many legacy database formats, including (say) MS-Access "JET," used such conventions. At the time, it was inconceivable that a mass-storage device could ever have that much capacity.

From time to time, mailbox users need to go through their mailboxes and clean them up ... or, as you effectively did, archive them.

Hi wpeckham,

As mentioned in my original post, I'm using "sendmail", not "Postfix".

Indeed I've done the inbox size check & warning in logon script, but it is human nature to ignore the warning until they suffer from the consequences.

Hi sundialsvcs,

I'm afraid my wording may have caused your mis-understanding.
By "Berkeley" I mean the mailbox format (in which messages are delimited by lines starting with "From "), not the "Berkeley DB".

For the case I encountered, the user's huge inbox was intact, the messages therein are retrievable, but some incoming messages could not be appended to it.

Hmmm... I thought that this mailbox format also included an index that was BDB. (Or maybe it just has a "signed 32-bit integer" offset-field.)

Oh, well. One way or the other, betcha that "that magic size" probably has something to do with it.

- - -
But, even so, it does come down to this: "at least once every five years or so, clean up your mail-boxes!"