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]

Reply via email to