It seems that I have to make /var/mail world-writeable in order that procmail can correctly deliver the mails of users.

Procmail is called via the users' .forward file, and presently only delivers a mail if the users mailbox is not empty. Otherwise it complains of a lock failure and does not create the user's mailbox file (thus the mail is lost).

The present permissions of /var/mail are:
drwxrwxr-x root mail /var/mail

What is your opinion about this? Is there a better workaround?

Maybe look here?

That FAQ suggests to set the sticky bit on the word-writeable mail directory. (Although there are no procmailrcs in the home directories; does it mean that procmail gets rid of sgid mail if ANY program is called from /etc/procmailrc?)
I also put up this question at the procmail mailing list, where I was advised to check and set the setuid root permission of procmail. (I wonder if setuid root would work at all, since as procmail gets rid of the sgid mail permissions, it might more happily get rid of the root permissions as soon as the time comes).
Provided that the latter also works, which solution would you choose? (Well... I suppose you would choose none of the two. But say... if you
were threatened with death to choose one?)
I myself have to use such solutions because I do not have full control over the whole mail system; I must respect that sendmail (suid root) belongs to the competence of our so-called system administrator. (Two years were not enough for him to set up a working mail filter to protect 50 users sitting behind unpatched Outlook Expre$$es...)

LOL. If I was threatened with death I most certainly wouldn't think of prcmail's sgid behaviour first.

AFAIK "the time comes" when a ~/.forward and/or ~/.procmailrc are availabe: if ~/.procmailrc or ~/.forward are available, and the permissions are 0600 for rc (and mailbox) and 704 for forward, then change uid and drop sgid to owner's uid and gid. Commands from /etc/procmailrc use /etc/procmailrc's stated shell (of the user delivering to) and with DROPPRIVS=YES privs will be dropped to that of the user. At least that's what Ive tested (delivering to users mboxes tho, not /var/(spool/)mail, and with procmail defined as the MTA's LDA).

I think sgid mail and 1777 /var/mail are good but since a 0755 procmail will be dropping privs to user I'm not sure why they would suggest needing setuid root. I'm against setuid root binaries unless there's no proven workable alternative with lower privs, but then again I'm sure I'm forgetting something crucial about dotlocks or flocks but I ain't no procmail guru, ok? Could you post their reply in full?

Btw, if you say you're losing mail I would first get rid of ~/.forwards, and define a global failure rule in /etc/procmailrc that would drop to a default mbox or back into the queue. Yes, you *can* have if-else rules with procmail.

Btw2, did you define LOGVERBOSE=ALL to get a grip on the cause of not locking?

HTH somehow.

Strange, but suid root worked.
From a certain point of view it was better at the beginning:
Then things did not work, but I knew why.
Now that procmail runs as suid root things work but I do not know why...

P.S.
I cannot avoid the users' .forward files, since they are the only way I can use to call procmail. As I mentioned before, I am not allowed to edit sendmail.cf, where mail is defined as the only LDA (our system administrator preferred that).
I prefer the suid root solution because it is the same method that our system administrator choosed for sendmail; thus I cannot be accused of doing something worse (e.g. disclosing the privacy of the mailboxes of users).