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/

Reply via email to