Re: [vchkpw] The future of valias other topics
On Mon, 8 Jan 2007, John Simpson wrote: On 2007-01-08, at 0602, [EMAIL PROTECTED] wrote: Attached is a patch for 5.4.18 to enable alias line removal from .qmail based aliases and the implementation of alias line removal using the valias command line program. Am I meant to be posting patches here (such as my previous double free problem in vpalias.c) or to another list ? vpopmail-5.4.18-valias.patch here is fine, but you should probably start a new thread instead of replying your message into the middle of an existing one. Ok, noted. I replied in the middle of the existing thread/message because of the mention of 'Complete alias handling' by Rick (not so complete without the ability to remove an alias line using vpalias.c), although I did take on board his comment about 'Full support is available in cdb and MySQL back ends', no harm intended.
Re: [vchkpw] The future of valias
Meet me on vpopmail-devel... [EMAIL PROTECTED] Subscribe on the web: http://sourceforge.net/mail/?group_id=85937 Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=34827
Re: [vchkpw] The future of valias other topics
First a quick review of the new features added to the 5.4.18 release: o The option of running a script each time a user or domain is added, deleted or modified. This can be used for sending notification messages, maintaining a list of valid users and what ever else you may need to do. See README.onchange o Complete alias handling. With this version you can add an address to an alias, delete an address from an alias, delete an entire alias, or delete all aliases from a domain. That pretty much takes care of all the possibilities for unordered aliases. Full support is available in cdb and MySQL back ends. The MySQL code can be used as a template for other back ends. Attached is a patch for 5.4.18 to enable alias line removal from .qmail based aliases and the implementation of alias line removal using the valias command line program. Am I meant to be posting patches here (such as my previous double free problem in vpalias.c) or to another list ? diff -uPr vpopmail-5.4.18.orig/configure vpopmail-5.4.18/configure --- vpopmail-5.4.18.orig/configure 2006-12-31 04:41:21.0 + +++ vpopmail-5.4.18/configure 2007-01-05 09:21:29.0 + @@ -6620,19 +6620,19 @@ 1*|y*|Y*) echo $as_me:$LINENO: result: yes 5 echo ${ECHO_T}yes 6 -if test $USE_SQL != 1 -then -{ { echo $as_me:$LINENO: error: valias option is only supported in the SQL authentication modules 5 -echo $as_me: error: valias option is only supported in the SQL authentication modules 2;} - { (exit 1); exit 1; }; } -else +#if test $USE_SQL != 1 +#then +#{ { echo $as_me:$LINENO: error: valias option is only supported in the SQL authentication modules 5 +#echo $as_me: error: valias option is only supported in the SQL authentication modules 2;} +# { (exit 1); exit 1; }; } +#else VALIAS=1 cat confdefs.h _ACEOF #define VALIAS $VALIAS _ACEOF -fi +#fi ;; *) echo $as_me:$LINENO: result: no 5 diff -uPr vpopmail-5.4.18.orig/valias.c vpopmail-5.4.18/valias.c --- vpopmail-5.4.18.orig/valias.c 2006-12-19 21:02:47.0 + +++ vpopmail-5.4.18/valias.c2007-01-05 09:21:29.0 + @@ -37,8 +37,9 @@ #define VALIAS_SELECT 0 #define VALIAS_INSERT 1 -#define VALIAS_DELETE 2 -#define VALIAS_NAMES 3 +#define VALIAS_REMOVE 2 +#define VALIAS_DELETE 3 +#define VALIAS_NAMES 4 int AliasAction; int AliasExists; @@ -116,6 +117,23 @@ } break; + case VALIAS_REMOVE: + /* check to see if it already exists */ + AliasExists = 0; + tmpalias = valias_select( Alias, Domain ); + while (tmpalias != NULL ) { + if (strcmp (tmpalias, AliasLine) == 0) AliasExists = 1; + tmpalias = valias_select_next(); + } + if (AliasExists) { + valias_remove( Alias, Domain, AliasLine ); + } else { + fprintf (stderr, Error: alias %s - %s does not exist.\n, + Email, AliasLine); + vexit(-1); + } + break; + case VALIAS_DELETE: valias_delete( Alias, Domain ); break; @@ -136,6 +154,7 @@ printf( -s ( show aliases, can use just domain )\n); printf( -d ( delete alias )\n); printf( -i alias_line (insert alias line)\n); + printf( -r alias_line (remove alias line)\n); printf(\n); printf(Example: valias -i [EMAIL PROTECTED] [EMAIL PROTECTED]); printf( (adds alias from [EMAIL PROTECTED] to [EMAIL PROTECTED]); @@ -154,7 +173,7 @@ memset(AliasLine, 0, sizeof(AliasLine)); AliasAction = VALIAS_SELECT; - while( (c=getopt(argc,argv,vnsdi:)) != -1 ) { + while( (c=getopt(argc,argv,vnsr:di:)) != -1 ) { switch(c) { case 'v': printf(version: %s\n, VERSION); @@ -165,6 +184,10 @@ case 's': AliasAction = VALIAS_SELECT; break; + case 'r': + AliasAction = VALIAS_REMOVE; + snprintf(AliasLine, sizeof(AliasLine), %s, optarg); + break; case 'd': AliasAction = VALIAS_DELETE; break; diff -uPr vpopmail-5.4.18.orig/vpalias.c vpopmail-5.4.18/vpalias.c --- vpopmail-5.4.18.orig/vpalias.c 2006-12-19 21:02:47.0 + +++ vpopmail-5.4.18/vpalias.c 2007-01-05 09:23:09.0 + @@ -1,3 +1,4 @@ +#ifndef VALIAS /* * $Id: vpalias.c,v 1.6.2.14 2006/12/19 21:02:47 rwidmer Exp $ * Copyright (C) 2000-2004 Inter7 Internet Technologies, Inc. @@ -16,8 +17,6 @@ * along with this
Re: [vchkpw] The future of valias
First here is the into to the documentation for what I have in mind for vpopmail script handling, then I'll answer points from John's email. vpopmail mail script handling. Vpopmail provides a way to manage mail scripts that allows you to choose at configure time between storing scripts in the database or in .qmail or .vpopmail files. The mail script api is available for the cdb back end, but the configure options to use a table for storage are not available. Actually, for historic reasons, there are two api's available. The first, aliases stores a list of addresses to forward messages to. You are allowed to deliver to a program, but can not depend on the order of entries in an alias. Aliases are controlled by --enable-valias which causes vpopmail to store aliases in the databases. By the time lack of support for order in aliases became a problem there were a number of people using valias in programs they have written. Rather than changing the existing api ordered mail scripts have been provided by adding a new api, mail scripts. Mail scripts are controlled by --enable-scripts which causes vpopmail to store scripts in the database. Depending on the settings of --enable-valias and --enable-scripts [1] both may be stored in the same place. If so, it is safe to edit an alias as a script, but editing a script as an alias may not retain the order of lines within the script, causing it to fail. Mail scripts allow the calling program to store or retrieve the script as a .qmail or .vpopmail file, even when configure options specify it should be in the database. [2] If a file and database entry both exist, the file is executed and the database entry is ignored. [3] Files in the domain directory are executed by qmail-local, so they don't have the overhead of executing vdelivermail. Files in user level directories are executed by vdelivermail so there isn't as much advantage to using real files there. [1] Both of the configure options probably need to be renamed to reflect that they cause their associated data to be stored in a database table. [2] This can be used if the user chooses to use files instead of the database, and for programs like vconvert and dotqmail2valias which need to access both files and the database. [3] Sometimes you may have to delete a script twice, once to delete the file, then to delete the database entry exposed when the file disappeared. Note that this provides two switches that allow the system administrator to control storage of aliases and scripts separately. It also allows the programmer to chose to use a file to store a script even when the system administrator has selected database storage. John Simpson wrote: so you're going to design this new thing which is LIKE an alias, but it supports sequencing... and it can use the same code and probably the same database tables... but it's NOT an alias, simply because you give it some other name. Yes, but it is not a _new_ thing. I want to freeze the alias interface and provide a new interface for scripts. Both can end up in either a .qmail/.vpopmail file or a database. explain to me how your scripts are any different from aliases with a sequence field, or a .qmail file. either way, the functional result is the same: a set of delivery targets, guaranteed to be processed in a certain order. The calling conventions, and the idea that having two sets of calls allows you to optimize how things are handled in the back end. For example most scripts I can think of have two or more lines, and you don't want to attempt a delivery to a partially written script. By having separate functions we can better optimize the update process for its storage method. I think most scripts will be the result of template expansion or copied out of a text area and there will be more than one line that needs to be added. For example when writing to a file the write-script function can copy an entire script with one open / close / rename. If I have to use alias calls each line added will require the file to be copied to a temp file then renamed. Aliases are an unordered collection of delivery commands that you add or remove a single entry at a time. They stay what they are in 5.4.18 for a MySQL or pgsql user. The key to an alias is that you work with it one address (line) at a time. An email coming in to an alias when you have only written two of three destination addresses isn't as much of a disaster as a script that is not completely written. A mail script is an ordered collection of delivery commands that is created or updated as a group. The key to a script is that you update the whole thing at once. I know there are multiple lines to most scripts so its handler should accept all lines before making the script available to receive mail. If you use the existing add alias call and the script receives an email when only two of three lines have been written you may have a disaster. I'm thinking a pointer to an
Re: [vchkpw] The future of valias other topics
On 2007-01-08, at 0602, [EMAIL PROTECTED] wrote: Attached is a patch for 5.4.18 to enable alias line removal from .qmail based aliases and the implementation of alias line removal using the valias command line program. Am I meant to be posting patches here (such as my previous double free problem in vpalias.c) or to another list ? vpopmail-5.4.18-valias.patch here is fine, but you should probably start a new thread instead of replying your message into the middle of an existing one. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] The future of valias other topics
[EMAIL PROTECTED] wrote: Am I meant to be posting patches here (such as my previous double free problem in vpalias.c) or to another list ? The best place for patches is the tracker on SourceForge. They don't get lost or forgotten that way. Rick
Re: [vchkpw] The future of valias other topics
[EMAIL PROTECTED] wrote: Attached is a patch for 5.4.18 to enable alias line removal from .qmail based aliases and the implementation of alias line removal using the valias command line program. How did I miss that? I would have sworn that patch was included in the last release. Oh well, thanks for catching it now. Rick
Re: [vchkpw] The future of valias
On 2007-01-08, at 1313, Rick Widmer wrote: John Simpson wrote: so you're going to design this new thing which is LIKE an alias, but it supports sequencing... and it can use the same code and probably the same database tables... but it's NOT an alias, simply because you give it some other name. Yes, but it is not a _new_ thing. I want to freeze the alias interface and provide a new interface for scripts. Both can end up in either a .qmail/.vpopmail file or a database. here's a thought: the current function names become macros which call functions with new names and new functionality. the old API is preserved, and the new functionality is available with reasonable defaults to programs whose source code calls the old function names. only two functions really need to be changed: valias_insert(alias,domain,line) valias_remove(alias,domain,line) the functions would be renamed and gain a new parameter... valias_insertseq(alias,domain,seq,line) valias_removeset(alias,domain,seq,line) and the existing function names become macros which call the new functions: #define valias_insert(a,d,l) valias_insertseq((a),(d),INT_MAX,(l)) #define valias_remove(a,d,l) valias_removeseq((a),(d),-1,(l)) valias_insertseq() would be written to treat a seq parameter beyond the end of the alias as insert after the end. the SQL versions would include logic to find the current highest sequence within the alias and replace the huge number with max plus one, so that the lines within a given alias are always maintained as 0,1,2,3,etc. with no gaps and no duplications. valias_removeseq() would treat a seq parameter lower than zero as ignore the sequence and search for the text instead. By having separate functions we can better optimize the update process for its storage method. I think most scripts will be the result of template expansion or copied out of a text area and there will be more than one line that needs to be added. For example when writing to a file the write-script function can copy an entire script with one open / close / rename. If I have to use alias calls each line added will require the file to be copied to a temp file then renamed. i see the value of the template processing stuff, it gives an administrator a way to pre-define templates for users who want spam filtered into a spam folder and things like that. it IS a good idea. however, i see this implemented as a new function call: int valias_replace ( const char *alias , const char *domain , const char **lines ) which would start by wiping the current contents of the alias (if any) and then just writing the new lines into the alias, with sequences 0,1,2,3,etc... all within a single BEGIN TRANSACTION ... COMMIT block (or simply by writing the new lines to a .new.qmail file, chmod()ing it as needed, then rename()ing it over any existing .qmail file. Aliases are an unordered collection of delivery commands that you add or remove a single entry at a time. NO. aliases are, and have always been, a layer of abstraction above .qmail files, and are therefore ORDERED collections of delivery targets. They stay what they are in 5.4.18 for a MySQL or pgsql user. if current users are not expecting a specific sequence, and are used to not having any specific sequence, then how does it hurt things if suddenly they ARE sequenced? if nothing else, it's still random... it's just that it's the same random every time. besides, if every line in an alias is an email address, then the sequence (or lack thereof) doesn't matter. The key to an alias is that you work with it one address (line) at a time. An email coming in to an alias when you have only written two of three destination addresses isn't as much of a disaster as a script that is not completely written. you're thinking of the race condition where a delivery might happen while a .qmail file is halfway through being written. there are two solutions to this: - djb's solution, which is to enable the sticky bit for the home directory, which suspends all deliveries to that directory (for vpopmail, the home directory is the domain directory.) this is less than optimal, because it suspends all deliveries for the entire domain, rather than just the one alias you're updating. it also doesn't work with vdelivermail, because vdelivermail doesn't look at the sticky bit (it should.) - update the files or entries in a manner which is guaranteed to be atomic, either by using BEGIN TRANSACTION ... COMMIT, or by writing your new collection of lines to some other filename, setting its permissions, and then using rename() to give it the .qmail name which makes it live. this is better. A mail script is an ordered collection of delivery commands that is created or updated as a group. The key to a script is that you update the whole thing at once. I know there
Re: [vchkpw] The future of valias other topics
On 2007-01-05, at 1334, Rick Widmer wrote: I think the best thing to do with the localrelay patch is to put it into the contrib directory where people who need it can find it easily. The main reason I think this is because smtp after pop is obsolete. All the email clients I know of have handled smtp auth for years now, and the best thing we can do for the average user is to let smtp after pop die off. Drastic improvements in the mainstream code will send the wrong message. I wrote the paragraph above before reading the 'Further thoughts...' thread on Jan. third. If you want to do massive changes they will get added, but is it really better than recommending smtp auth for everyone and letting smtp after pop die? i think the idea of an onauth hook, similar to how onchange works, will minimize the amount of code changes needed for vpopmail, while opening the door for somebody (like joshua) to write a relay- after-pop3/imap system as external scripts if he likes, and also opening the door for others to add their own custom functionality. and it also removes any specific relay-after-pop3 functionality from vpopmail itself, while not destroying that functionality for people who may not be able to stop using it for political reasons. and it also means that vpopmail itself will never have to worry about relay-after-pop3 issues again- they can be referred to whoever wrote the external scripts that they will be using. I did not see any objections on changing to .vpopmail* files in user but not domain directories. If anyone does object, now is the time. Files in ~vppopmail/domains/user_name/ are executed by vdelivermail and will be renamed. Files in ~vpopmail/domains/ will stay .qmail and are executed by qmail-local. i agree- any files which are currently processed by qmail-local should retain the .qmail-* names, and others (i.e. the per-mailbox files) should use the .vpopmail names EXCLUSIVELY, so as to make it obvious to anybody poking through the directory structure that those files are processed by vpopmail rather than by qmail itself. 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.) Adding an order field to aliases... I think we should just say no! to ordered aliases. With 5.4.18 all the basic operations on an alias are available. We just declare that you can not count on the order of delivery of an alias, and call alias handling complete. i disagree. very strongly. I realize that sometimes order is important. I propose to provide another interface similar to aliases that are always ordered, called scripts, or more formally mail scripts. Vdelivermail already supports alias handling from a database so scripts and aliases should be able to share the same code, if not the same table. so you're going to design this new thing which is LIKE an alias, but it supports sequencing... and it can use the same code and probably the same database tables... but it's NOT an alias, simply because you give it some other name. explain to me how your scripts are any different from aliases with a sequence field, or a .qmail file. either way, the functional result is the same: a set of delivery targets, guaranteed to be processed in a certain order. seriously- i don't see any difference between what you call scripts and what vpopmail currently calls an alias, but with a sequence field attached to each line. in fact, for the cdb back-end, these are called .qmail files. the only thing missing is a way to store the sequencing in the database back ends, and the code to use and maintain those sequence fields. for vdelivermail, the only change in the code involves a single ORDER BY clause added to the proper SELECT query. and for the maintenance programs, it's one extra parameter passed to (1) the command, (2) the vpopmail.c stub function, and (3) the various back-end functions... and the extra code added to each back- end function. the hard parts are going to be coordinating the changes to all of the back-end functions at once, and then testing all of it. if somebody has the time, it won't be difficult for one person (myself, if needed) to write the changes for all of
Re: [vchkpw] The future of valias other topics
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/
Re: [vchkpw] The future of valias other topics
Tom Collins wrote: 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. I do plan a configure option. 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. I agree the benefits are small. If the configure option doesn't default to on, we should not do this at all. Its the people who won't read the configure options list who need it turned on. 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. Yes there will be a sequence field in the table. The question is how do we add the tools. Do we break the existing alias interface, or do we provide an alternate interface for when order is important, leaving all existing code intact. I'm working on a reply to John on this, but it may be a day or two...
Re: [vchkpw] The future of valias other topics
On Jan 6, 2007, at 5:15 PM, Rick Widmer wrote: Yes there will be a sequence field in the table. The question is how do we add the tools. Do we break the existing alias interface, or do we provide an alternate interface for when order is important, leaving all existing code intact. I'm working on a reply to John on this, but it may be a day or two... If the order isn't specified, it's added to the end. Create a new function in libvpopmail and new switches to the valias program to specify order. The old function just becomes a call to the new function. Include a define or configure check in QmailAdmin to see if they new API is present and, if so, show an interface to the user for it. Or, to make things easier, that QmailAdmin can require a minimum version of vpopmail. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
[vchkpw] The future of valias other topics
Sorry this took so long to get written, I've been busy at work... First a quick review of the new features added to the 5.4.18 release: o The option of running a script each time a user or domain is added, deleted or modified. This can be used for sending notification messages, maintaining a list of valid users and what ever else you may need to do. See README.onchange o .vpopmail-extension abilities just like .qmail-local. Is there anything left qmail-local does that vdelivermail does not? If there is, should we consider it a bug and match qmail-local 100%? I think vpopmail extensions should default to on, maybe even drop the ./configure option. It acts the same on existing setups and adds new functionality. Is there a good reason to be able to disable this at the ./configure level? A disable bit in gid-flags is probably a good idea so the system administrator, and domain admins can control it on individual users. o Complete alias handling. With this version you can add an address to an alias, delete an address from an alias, delete an entire alias, or delete all aliases from a domain. That pretty much takes care of all the possibilities for unordered aliases. Full support is available in cdb and MySQL back ends. The MySQL code can be used as a template for other back ends. -- Back to the future... after reviewing the threads '5.4.17 patches', '.vpopmail instead of .qmail' and '5.4.18 valias' this is what I think should happen in 5.4.19. I think the best thing to do with the localrelay patch is to put it into the contrib directory where people who need it can find it easily. The main reason I think this is because smtp after pop is obsolete. All the email clients I know of have handled smtp auth for years now, and the best thing we can do for the average user is to let smtp after pop die off. Drastic improvements in the mainstream code will send the wrong message. I wrote the paragraph above before reading the 'Further thoughts...' thread on Jan. third. If you want to do massive changes they will get added, but is it really better than recommending smtp auth for everyone and letting smtp after pop die? I did not see any objections on changing to .vpopmail* files in user but not domain directories. If anyone does object, now is the time. Files in ~vppopmail/domains/user_name/ are executed by vdelivermail and will be renamed. Files in ~vpopmail/domains/ will stay .qmail and are executed by qmail-local. Vdelivermail will look for .vpopmail files and .qmail files in the users directory. If both exist, only the .vpopmail file will be executed. If it does not check the sticky bit and defer messages like qmail-local it needs to. Editing a user .qmail file with the library should result in it being renamed to .vpopmail. If both exist, the .qmail file is ignored. UPGRADE will recommend running Jeremy's script to bulk rename the files when you install. Adding an order field to aliases... I think we should just say no! to ordered aliases. With 5.4.18 all the basic operations on an alias are available. We just declare that you can not count on the order of delivery of an alias, and call alias handling complete. I realize that sometimes order is important. I propose to provide another interface similar to aliases that are always ordered, called scripts, or more formally mail scripts. Vdelivermail already supports alias handling from a database so scripts and aliases should be able to share the same code, if not the same table. There are good arguments that scripts are best implemented as .qmail or .vpopmail files but vdelivermail already supports all the delivery methods from a database, and it will continue to do so. On the other hand, I plan to do all I can to steer people towards using files for mail scripts. Once the script functions are added I plan to add a template system that allows the system admin (or anyone with admin and expert abilities) to manage the templates. Scripts will start with a comment that identifies what kind of script they are. The comment will come from the template, or be generated the first time an existing file is created. Template system examples: Template for a blackhole, .templates/blackhole Blackhole (Name of template) A black hole deletes all messages sent to it. The description can be more than one line, and ends with a period on a line by itself. That line is not in the description or the template code that follows it: . # blackhole This creates a .qmail or .vpopmail file containing: # blackhole Template for a qmailadmin like autoresponder, .templates/autorespond
Re: [vchkpw] The future of valias other topics
On Fri, 2007-01-05 at 11:34 -0700, Rick Widmer wrote: -- Back to the future... after reviewing the threads '5.4.17 patches', '.vpopmail instead of .qmail' and '5.4.18 valias' this is what I think should happen in 5.4.19. How about removing the cdb domain check for vauth? I don't know what all utilizes the vauth function, but I happened to notice that if a domain does not exist in /var/qmail/control/aliases, a user cannot authenticate. To be more precise: I have a 'user' server which also houses the primary database. All creation/deletion of users/domains is done on that server. I have another server with an NFS export, also running IMAP, that has a copy of the required qmail files, a 5.4.17 vpopmail install on it, and a MySQL slave. If I create a domain on the 'user' server, the user cannot authenticate on the IMAP server because the domain doesn't exist in the aliases cdb file. For my purposes, the cdb check is unnecessary, and just another thing I have to replicate. Is it possible to have a configure with --skip-cdb-auth - or maybe can we put/replicate the aliases cdb into MySQL ? Just some thoughts. It 'feels' smoother to have everything replicated in MySQL, instead of having scripts run or a bunch of extra NFS mounts.. Rick
Re: [vchkpw] The future of valias other topics
Rick Romero wrote: On Fri, 2007-01-05 at 11:34 -0700, Rick Widmer wrote: -- Back to the future... after reviewing the threads '5.4.17 patches', '.vpopmail instead of .qmail' and '5.4.18 valias' this is what I think should happen in 5.4.19. How about removing the cdb domain check for vauth? I don't know what all utilizes the vauth function, but I happened to notice that if a domain does not exist in /var/qmail/control/aliases, a user cannot authenticate. To be more precise: I have a 'user' server which also houses the primary database. All creation/deletion of users/domains is done on that server. I have another server with an NFS export, also running IMAP, that has a copy of the required qmail files, a 5.4.17 vpopmail install on it, and a MySQL slave. If I create a domain on the 'user' server, the user cannot authenticate on the IMAP server because the domain doesn't exist in the aliases cdb file. For my purposes, the cdb check is unnecessary, and just another thing I have to replicate. Is it possible to have a configure with --skip-cdb-auth - or maybe can we put/replicate the aliases cdb into MySQL ? Just some thoughts. It 'feels' smoother to have everything replicated in MySQL, instead of having scripts run or a bunch of extra NFS mounts.. Rick there will always be files that must be pushed around, in a setup such as that. i think the onchange function is ideal for this. I'm interested to see as time goes on what example onchange hackery people come up with... so far, i am updating my validrcptto cdb, and (based on what operation is done i.e. add/remove domain), sending an email to admins. next i feel like i need to create a MySQL log database, where all add/delete/modify operations will be logged to...the username who initiated the change, timestamp, the actual operation etc. this will be used for billing, as well as audit trail for the gui. does anyone else have interesting onchange thoughts ? -- aichains