This might not be direcrly related to your problem, but let me air
a similar procmail issue regarding dot-locking and the use of procmail
as the local delivery agent.
Consider how procmail dot-locks a mailbox - first it creates a file
with a unique name, something like /var/mail/_QVETS. Then it tries to
hardlink /var/mail/user.lock to this file. If the user.lock file already
exists (because the user is already receiving some mail), then procmail
unlinks the temporary file, sleeps for 8 seconds and tries again.
Now consider what happens if someone mailbombs a user by sending him,
for example, 1500 mails in a very short time (a regular occurence these
days, if you ask the postmasters of large mailservers).
Only one procmail process can deliver at a time, so you will have 1000
or more procmail processes going through that 8-second loop at the same
time. Creation and unlinking of files are syncronous disk operations
and with 1000 processes doing this, your /var/mail disk will have around
250 write requests going to it per second(!), which is much more then a
simple disk subsystem can handle. This results in your whole mailserver
On my servers I avoid this situation to some extent by having increased
DEFlocksleep from 8 to 90 seconds in config.h (but mostly by mounting
/var/mail as a tmpfs on solaris).