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 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 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 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
