Inbox.lock theory... perhaps

[GTFO]

I've got a user whose inbox is being locked randomly, messages go to the queue....etc..etc.

Anyway, not found a solution yet, but I think I found something that might be of interest to others. When grep "inbox lock" /var/log/exim_mainlog on some of my other servers, I found that their were a few accounts that had substantial numbers of these locked inboxes. The only common denominator(s) amongst the were one of the following.

1. The catch all is directed to that mail account

2. multiple e-mail addresses are forwarding to that account

3. mail account receives thousands of messages in a day

One instance specifically, I found a user who has 4 mail forwards created going to the catch all mail account, whilst the catch all mail account is their main user.

Anyway,... Whats the possibility that these messages are fighting either with each other, or with the user when they attempt to connect to the mail server to download their mail ?

(half baked idea im sure, but the results im seeing breath some life into it)

[GTFO]

Looking further into this, im inclined to believe that cppop is fighting with exim for lock file privellages. If you've a user having this problem, try this

1. grep their e-mail address in the /var/log/maillog file .
2. grep "lock file" /var/log/exim_mainlog >> somefile
3. grep their e-mail address in "somefile" and in the output, you might find what I found.

I was able to locate every time stamp where this lockfile stuck issue happened, and they perfectly timed (correct for 3-4 seconds) with the users cppop connections.

Exim vs. Cppop perhaps ?

[chirpy]

Please don't cross-post. You have replies in the thread you replied to:
inbox.lock problem