On Jan 6, 2007, at 12:26 AM, John Simpson wrote:
as for making .vpopmail* files fully compatible with .qmail* files,
that could also be a good thing- however the interface (in terms of
which environment variables will be passed to scripts run from
the .vpopmail file, what values will be contained in those
variables, and how the return values will be interpreted) should be
not only documented, but made to be as compatible as possible with
what qmail-local would pass to a script in the .qmail file of a
system account mailbox. this way if somebody has to transition a
domain from being "system accounts" to being managed by vpopmail,
there should be no changes to the files or scripts (as long as they
are using the environment variables properly, as opposed to hard-
coding path names into the script- which we all know users do.)
Except they would need to rename all of the .qmail-ext files in the
user's directory to .vpopmail-ext.
i respect charles and his opinion about .qmail and .vpopmail
files... but making charles happy is not a primary goal of
vpopmail, and it's certainly not an excuse to unsafely force this
change on all of the existing vpopmail systems out there. i think
it makes more sense to explain the situation to the administrators,
provide them with a tool to manually rename the files en masse (and
identify any problem cases where both .qmail and .vpopmail files
already exist) and TELL them that it should be done- but the final
decision about whether and when to do the change should be left in
the hands of the administrator of each system.
of course i would also remove the "either/or" filename logic from
the NEXT version of vpopmail, so that if they haven't renamed the
files, they become broken and it's their own fault.
How about this -- make it a configure option. People who want to
call them .vpopmail can choose that option and run the tool to do the
conversion. People who want to continue using .qmail (like me) can
easily do so.
Seriously, I don't see any advantages for vpopmail admins to
use .vpopmail instead of .qmail, other than it makes clear which
files are parsed by .qmail-local and which are parsed by vdelivermail.
(2) change all of the database back-ends to store their aliases in
the filesystem. while this allows these users to control the
sequence in which the delivery instructions will be processed, it
TAKES AWAY their current ability to maintain the contents of their
aliases by doing SQL queries, and FORCES them to have to edit a
file on the filesystem in order to maintain their aliases.
the second option would certainly be easier to write (only one set
of maintenance functions involved.) however, if there are users who
NEED to have the alias lines stored in a database, and they are
willing to adjust their own systems to deal with a sequence field,
then there is no reason (other than time constraints) that we can't
store everything in a database.
This already exists -- no need to write it. Just compile with --
disable-valias.
i've already written pseudo-code for the framework of each
maintenance operation, the only thing preventing me from turning
that into real working code at this point is free time, and the
lack of a consensus about how it will be handled (i.e. i don't want
to write code which won't actually be used.)
if there are users out there who NEED to have the alias lines
stored in their database back-ends, we CAN make that happen.
granted, it means more coding and more testing, which means it'll
probably take a little longer to finish, but if it makes the
program usable to more people, isn't that the important thing?
I've pictured this in my head as well, and I agree with John that we
should add a sequence field to the existing table, then add the tools
to support it properly.
--
Tom Collins - [EMAIL PROTECTED]
Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/
QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
