Today I noticed a bunch of errors in the dovecot log stating “[Dovecot] – Inotify instance limit for user exceeded, disabling”. Apparently Inotify is used to notify
the client immediately after new message has been received. This typically happens after the IMAP client uses the IDLE command.

The solution:

[root@SERVER ~]# cat /proc/sys/fs/inotify/max_user_instances
128
[root@SERVER ~]# echo "256" > /proc/sys/fs/inotify/max_user_instances
[root@SERVER ~]#

Dovecot shouldn’t need to be restarted, but you can choose to do so…. or can you?

On servers where a catchall has been setup using the qmailadmin web interface, it is possible for postmasters to delete an email account that was setup as a catchall account (in this case; johnsmith@example.com). When this occurs, the .qmail-default file is not updated. Assuming said catchall was already designated prior to removal, mail is accepted for any-random-user@example.com and messages are deferred when delivery to /home/vpopmail/domains/P/earthwire.com/johnsmith is attempted. This can cause the qmail queue to grow over time when you have many users with this scenario.

A problem /home/vpopmail/domains/P/example.com/.qmail-default file:

| /home/vpopmail/bin/vdelivermail '' /home/vpopmail/domains/P/earthwire.com/johnsmith

What a nonexistent qmail user directory deferral looks like;

/var/log/qmail/current:
@400000004b72cd931e35f0ac delivery 5362496: deferral: client_connect:_connect_failed:_2/user_does_not_exist,_but_will_deliver_to_/home/vpopmail/domains/P/example.com/johnsmith//can_not_open_new_email_file_errno=2_file=/home/vpopmail/domains/P/example.com/johnsmith/Maildir/tmp/1265814921.29239.qmailserver.maildomain.com,S=3149/system_error/

A quick solution(s):

OR