Finally, the answers were kind, I was sent no rtfm and the questions
weren't deemed off-topic, thank you very much. But, that's the way
things are, too many questions always yield few answers.
Nevertheless I think the points are important - let's take a look at
the wording in Policy 5.6 Mail transport agents
> Debian packages which process electronic mail (...)
> <em>must</em> make sure that they are compatible with the
> configuration decisions below.
> Failure to do this may result in lost mail, broken From: lines, and
> other serious brain damage!
If the Policy uses <em>must</em>, it's not up to the sysadmin
to decide. Her decisions <em>have</em> to be compatible. Period.
* Issue one: SPOOL AND MAILBOXES
Where should the real spool files be? Could /var/mail/$user be a link
to /home/$user/Mailbox?
> [Policy 5.6]
> The mail spool is /var/spool/mail (...) The mail spool is part
> of the base system
> The mail spool is 2775 mail.mail (...)
> (should be root.mail, objects Santiago Vila)
> (...)
> Mailboxes are generally 660 user.mail unless the user has chosen
> otherwise (...) Mailboxes must be writable by group mail.
> [qmail's INSTALL.vsm]
> There are two basic problems with /var/spool/mail:
> It's slow.
> It's insecure.
> [qmail's INSTALL.mbox]
> qmail-local delivers mail by default into ~user/Mailbox, rather than
> /var/spool/mail/user.
> (...)
> As root, set up a symbolic link from /var/spool/mail/user to
> ~user/Mailbox for each user. /var/spool/mail should be mode 1777,
> so users will not be able to accidentally remove these links. (...)
> If /var/spool/mail is large, you can gain extra speed by configuring
> all your mail software to look at ~user/Mailbox directly.
> (...)
> Some vendors, in a misguided attempt to solve the security problems of
> /var/spool/mail, have made all their mail software setgid mail. After
> you move the mailboxes, you can---and, for security, should---remove
> those setgid-mail bits.
** Issue two: FILE LOCKING
> [Policy 5.6]
> All Debian MUAs, MTAs, MDAs and other mailbox accessing programs (like
> IMAP daemons) have to lock the mailbox in a NFS-safe way.
> [qmail's INSTALL.maildir]
> The mbox format---the format of ~user/Mailbox, understood by BSD Mail
> and lots of other MUAs---is inherently unreliable.
> (...)
> You should switch to maildir, which works fine over NFS without any
> locking. You can safely read your mail over NFS if it's in maildir
> format.
Mbox needs procmail for dot-locking (says Phil Hands, the maintainer,
in README.Debian), Maildir doesn't.
* Issue three: ALIASES
> [Policy 5.6]
> /etc/aliases is the source file for the system mail aliases
> (e.g., postmaster, usenet, etc.)--it is the one which the
> sysadmin and postinst scripts may edit. After /etc/aliases
> is edited the program or human editing it must call newaliases.
> [qmail's INSTALL.alias]
> qmail doesn't have any built-in support for /etc/aliases. If you have a
> big /etc/aliases and you'd like to keep it, install the fastforward
> package, available separately.
Well, the aliases system in qmail is completely different. Should this
ammount to a wishlist message to the qmail-src maintainer, suggesting
a qmail -> fastforward dependancy? (this applies to sendmail to qmail
migration, but not the other way round). Should an 'addalias' script
be created which wrote both to /var/lib/qmail/alias/ and /etc/aliases?
CONCLUSIVE QUESTIONS
Is qmail an inherently non-Policy packet? Should the Policy wording
be modified? Doesn't the Policy have a bias for a sendmail-like
system? Have the security implications been considered (see Bugtraq
1999-1, discussion between Venema and Berstein)? Did I miss something?
How about an /etc/mailsystem conffile?
For instance (of course this is naïve)
mta=qmail|sendmail|smail...
mda=...
spool=
aliases=
mboxformat=mbox|mh folders|maildir...
--
jr <[EMAIL PROTECTED]>
PGP 2.6.3ia & GnuPG keys available
