just updating README.debian, while it helps, doesn't fix the underlying problem that there is no system wide (or actually user controlled) policy for these things.
One attempt to resolve this is at: http://www.magma.com.ni/~jorge/proposal/delivery_1.html Unfortunately, this proposal requires a lot of code changes beyond just paths. You need an /etc/alternatives like mechanism. I have a fairly simple one that almost works /etc/skel/.mailconf/inbox -> /var/spool/mail/$USER # oops, most systems don't support substitution, need to # handle it when copying /etc/skel. /etc/skel/.mailconf/folders -> ../mail /etc/skel/.mailconf/sent-mail -> folders/sent-mail /etc/skel/.mailconf/spam -> folders/spam /etc/skel/.mailconf/interrupted -> folders/interrupted /etc/skel/.mailconf/postponed -> folders/postponed-msgs /etc/skel/.mailconf/drafts -> folders/postponed-msgs /etc/skel/.mailconf/saved-messages -> folders/saved-messages /etc/skel/.pine-interrupted-mail -> .mailconf/interrupted And you need a utility to populate these in existing user's home directories. Then, every program can be pre-configured with paths to ~/.mailconf/ Another alternative is to link every mail program with libmailconf (which needs to be permissively licensed) and replace fixed strings with function calls. Then you can have /etc/mail/mail.conf and ~/.mailconf files. However, this requires significantly more code changes and complicates things if a user wants to change a file configuration in the programs preferences. Really, the programs should have a choice: [X] System standard location [ ] Custom location: _______________ Or use $mailconf_inbox substitution. There is still the issue of mbox vs maildir. Many programs will autodetect for existing files but not new ones. And most of the GUI mail programs are HORRIBLY non-standards compliant when it comes to /var/spool/mail/. They treat it like a POP3 account and suck it dry which makes them incompatible with all non-gui applications. And there is the issue of spam filters. libmailconf could tell a program whether spam filtering is already part of the delivery mechanism. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]