@MikeMcQuaid In the case of mutt, `mutt_dotlock` is separate from the main `mutt` executable specifically to reduce security implications of setgid — instead of setgid'ing the whole MUA, you have `mutt_dotlock` that's only capable of locking a file, and no more.
```
dotlock(1) User Manuals dotlock(1)
NAME
mutt_dotlock - Lock mail spool files.
SYNOPSIS
mutt_dotlock [-t|-f|-u|-d] [-p] [-r retries] file
DESCRIPTION
mutt_dotlock implements the traditional mail spool file locking method:
To lock file, a file named file.lock is created. The program operates
with group mail privileges if necessary.
OPTIONS
-t Just try. mutt_dotlock won't actually lock a file, but inform
the invoking process if it's at all possible to lock file.
-f Force the lock. If another process holds a lock on file longer
than a certain amount of time, mutt_dotlock will break that lock
by removing the lockfile.
-u Unlock. mutt_dotlock will remove file.lock.
-d Delete. mutt_dotlock will lock file, remove it if it has length
0, and afterwards remove file.lock.
-p Use privileges. If given this option, mutt_dotlock will operate
with group mail privileges when creating and deleting lock
files.
-r retries
This command line option tells mutt_dotlock to try locking
retries times before giving up or (if invoked with the -f com-
mand line option) break a lock. The default value is 5.
mutt_dotlock waits one second between successive locking
attempts.
...
```
So I would say it's foolproof enough that it's okay that people blindly run this without understanding the security implications.
More importantly, I can't in good conscience recommend running a mail program as root; much less secure than setgid'ing the locking mechanism.
So what would you recommend here? Just be vague?