Mike - st257 writes:
On Fri, Dec 9, 2016 at 12:51 PM, Gordon Messmer <<URL:mailto:gordon.mess...@gmail.com>gordon.mess...@gmail.com> wrote:On 12/09/2016 07:55 AM, Mike - st257 wrote: > I don't yet have an answer why that file was present (doesn't exist in > my mailbox on that system), but moving it aside resolves the present > mail delivery problem. That file's presence indicates that a Maildir++ has a quota, and is used to track the quota and usage. Periodically, a maildir reader must crawl the entire maildir to re-calculate usage, which could explain the timeout if an uncached read of all of the directories for that Maildir take a *really* long time. (Agreed.)The user's mailbox is large enough (my opinion, at a few Gigabytes) that crawling the entire maildir will take an extremely long time.
You should look into exactly how messages get ultimately delivered to the maildir.
Although maildrop may be used to filter/sort through incoming mail, it is possible that something else actually delivers the mail to the mailbox.
maildrop creates that actual filenames for each message with the size of the message encoded into it. This will skip the stat call when scanning the mailbox.
This will also explain why the calculated quota is off.If you don't need mailbox quotas, you can simply get rid of the whole thing, as you did. But if you do install mailbox quotas, you need to use maildrop, or the deliverquota helper to deliver messages to a quota-enforced mailbox.
pgpPtYT3SwwE9.pgp
Description: PGP signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
