Menu
▾
▴
qmailadmin-devel — List to discuss future development of QmailAdmin
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(121) |
Aug
(31) |
Sep
(65) |
Oct
(9) |
Nov
(23) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(33) |
Feb
(19) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(7) |
Nov
(8) |
Dec
(3) |
| 2005 |
Jan
(20) |
Feb
|
Mar
(5) |
Apr
|
May
(3) |
Jun
(3) |
Jul
(8) |
Aug
(6) |
Sep
(3) |
Oct
(3) |
Nov
(3) |
Dec
(3) |
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(4) |
May
(7) |
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(7) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2008 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Jeff H. <jef...@ma...> - 2003-07-17 18:10:03
|
Bill Shupp wrote: >> In the current state of vpopmail, emails would still be required in >> the valias, not /Maildir/'s or we get the same problem. > > I thought there was already a patch for this? Aren't we talking about > vdelivermail's inability to check for a .qmail file in the user's > directory when the Maildir path goes all the way to /Maildir/? As far as I know, there is not a patch for this. There is a patch to read the user's .qmail file if a /Maildir/ is specified in the catchall. Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Bill S. <hos...@sh...> - 2003-07-17 17:13:04
|
On Thursday, July 17, 2003, at 10:07 AM, Jeff Hedlund wrote: > Bill Shupp wrote: >>> I guess a configuration directive would tell qmailadmin which method >>> to use for writing them (.qmail file or valias) >> Well, the vpopmail library should determine which kind to use, rather >> than a configuration directive. However, for legacy support, or >> mixed environment support, I think that qmailadmin should default to >> valiases if the library is compiled with valias support, but also be >> aware of .qmail files if they exist. > > I agree with that. Although it might be nice to have a configuration > directive overriding using valias, though that could be a lower > priority. I'm not sure how this would be useful. Why would anyone want qmailadmin to *not* be in sync with vdelivermail for alias/valias processing? Seems like adding such a directive would just open the door for problems. > And another thing to be aware of, is that .qmail files will override > what's in the valias. So there should probably be a warning if > qmailadmin detects the same alias for in a .qmail file and in the > valias table. Agreed. It would also be good to make sure the documentation stresses the need to convert existing .qmail files to valiases with vcalias so that such inconsistencies are minimized. Bill |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 17:11:19
|
Bill Shupp wrote: >> It was removed for a couple of reasons (but not due to a vdelivermail >> shortcoming). Aliases and forwards are pretty much the same thing, so >> it makes it easier to understand for users of the system to add/edit >> forwards and aliases in the exact same way. > > Well, they may "seem" the same to users. But to qmail, they are > different: one requires the message to go back through the queue for > remote delivery, the other does not. This distinction is really only > that relevant for large scale installations where such an implementation > might cause a performance hit. But for the end-user, if I have an alias for an account, I would expect it to be process my forward or vacation rules (or the recently added spam rules). Delivering via /Maildir/ will always skip that, so I don't see a use for putting a /Maildir/ in a .qmail file as far as qmailadmin is concerned. Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Bill S. <hos...@sh...> - 2003-07-17 17:08:21
|
On Thursday, July 17, 2003, at 10:02 AM, Jeff Hedlund wrote: > Bill Shupp wrote: >>> So, for users who don't have valiases, they'll take the performance >>> hit of having a lot of .qmail-user files, in addition to having >>> messages re-queued for delivery. >> Well you will then have the overhead of another SQL query. Not sure >> which is more of a hit.. lots of files, or the query. Probably about >> the same. But the lack of reprocessing through the queue is >> definitely good. > > Actually, looking at the vdelivermail code it looks like valiases are > processed almost exactly the same as .qmail files. > > If there is a Maildir value in the valias, it skips the user's .qmail > file as well. > > If there is an email address in the valias, it gets re-injected into > the queue. Right... I was not referring to processing of the .qmail command, I was referring to the difference in disk access speed (looking for .qmail-user, and then reading it) and an SQL query. vdelivermail will process them exactly the same, as the valias contents would not differ from what's in .qmail file. > In the current state of vpopmail, emails would still be required in > the valias, not /Maildir/'s or we get the same problem. I thought there was already a patch for this? Aren't we talking about vdelivermail's inability to check for a .qmail file in the user's directory when the Maildir path goes all the way to /Maildir/? Bill |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 17:07:24
|
Bill Shupp wrote: >> I guess a configuration directive would tell qmailadmin which method >> to use for writing them (.qmail file or valias) > > Well, the vpopmail library should determine which kind to use, rather > than a configuration directive. However, for legacy support, or mixed > environment support, I think that qmailadmin should default to valiases > if the library is compiled with valias support, but also be aware of > .qmail files if they exist. I agree with that. Although it might be nice to have a configuration directive overriding using valias, though that could be a lower priority. And another thing to be aware of, is that .qmail files will override what's in the valias. So there should probably be a warning if qmailadmin detects the same alias for in a .qmail file and in the valias table. Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 17:02:49
|
Bill Shupp wrote: >> So, for users who don't have valiases, they'll take the performance >> hit of having a lot of .qmail-user files, in addition to having >> messages re-queued for delivery. > > Well you will then have the overhead of another SQL query. Not sure > which is more of a hit.. lots of files, or the query. Probably about > the same. But the lack of reprocessing through the queue is definitely > good. Actually, looking at the vdelivermail code it looks like valiases are processed almost exactly the same as .qmail files. If there is a Maildir value in the valias, it skips the user's .qmail file as well. If there is an email address in the valias, it gets re-injected into the queue. >> If we add valias support to qmailadmin, the valias can continue to >> refer to the Maildir (or even just the pop/imap username?) for >> delivery (and vdelivermail can be smart enough to process the .qmail >> file for that user).j In the current state of vpopmail, emails would still be required in the valias, not /Maildir/'s or we get the same problem. Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:50:46
|
On Thursday, July 17, 2003, at 09:47 AM, Jeff Hedlund wrote: > I guess a configuration directive would tell qmailadmin which method > to use for writing them (.qmail file or valias) Well, the vpopmail library should determine which kind to use, rather than a configuration directive. However, for legacy support, or mixed environment support, I think that qmailadmin should default to valiases if the library is compiled with valias support, but also be aware of .qmail files if they exist. Regards, Bill |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:48:01
|
On Thursday, July 17, 2003, at 09:41 AM, Tom Collins wrote: > So, for users who don't have valiases, they'll take the performance > hit of having a lot of .qmail-user files, in addition to having > messages re-queued for delivery. Well you will then have the overhead of another SQL query. Not sure which is more of a hit.. lots of files, or the query. Probably about the same. But the lack of reprocessing through the queue is definitely good. > If we add valias support to qmailadmin, the valias can continue to > refer to the Maildir (or even just the pop/imap username?) for > delivery (and vdelivermail can be smart enough to process the .qmail > file for that user).j Exactly. Regards, Bill |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 16:47:25
|
Tom Collins wrote: > I can look into adding it, I didn't know much about it until now. > > I assume it's a setup where all of the aliases are replaced by entries > in a MySQL table. If that's the case, it shouldn't be too hard to roll > that into QmailAdmin. > > Could you have a setup with a mix of .qmail-alias files and valias > tables? Maybe different configurations for different domains? Or even > a domain with some of each? Yes, I think you could have a mix. I think that qmailadmin would need to be able to read both kinds. I guess a configuration directive would tell qmailadmin which method to use for writing them (.qmail file or valias) Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Tom C. <to...@to...> - 2003-07-17 16:41:54
|
On Thursday, July 17, 2003, at 09:34 AM, Bill Shupp wrote: >> The other reason is that aliases were written to the file using the >> /Maildir/. When a .qmail file has a /Maildir/ in the file, it is >> delivered directly to the /Maildir/ (this is how qmail works). Since >> it is delivered directly, it bypasses the user's .qmail file. The >> .qmail file should not be bypassed for 'aliases' since it could >> contain forwarding rules, spam rules, filtering rules, etc. > > Right... while this is solved using valiases (mentioned in my last > message), it would not be relevant to cdb users, as qmail-local would > still be responsible for local delivery. So, for users who don't have valiases, they'll take the performance hit of having a lot of .qmail-user files, in addition to having messages re-queued for delivery. If we add valias support to qmailadmin, the valias can continue to refer to the Maildir (or even just the pop/imap username?) for delivery (and vdelivermail can be smart enough to process the .qmail file for that user). -- Tom Collins to...@to... http://sniffter.com/ - info on the Sniffter hand-held Network Tester |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:41:19
|
On Thursday, July 17, 2003, at 09:37 AM, Tom Collins wrote: > On Thursday, July 17, 2003, at 09:27 AM, Bill Shupp wrote: >> Incidentally, this all would have an affect on valias support in >> qmailadmin. Has there been any talk or progress regarding valias >> support? > > I can look into adding it, I didn't know much about it until now. > > I assume it's a setup where all of the aliases are replaced by entries > in a MySQL table. If that's the case, it shouldn't be too hard to > roll that into QmailAdmin. More specifically, it is where ALL .qmail contents, except for .qmail-default, are stored in an SQL table, "valiases" I think. > Could you have a setup with a mix of .qmail-alias files and valias > tables? Maybe different configurations for different domains? Or > even a domain with some of each? It will work, but from an administration standpoint, it's better to stick to one or the other. That's why the vcalias program was created.. to aid in converting to valiases (.qmail files are NOT deleted, so that that you can review the conversion first, then delete them yourself manually). Regards, Bill |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:37:46
|
On Thursday, July 17, 2003, at 09:22 AM, Edward McLain wrote: > Hello all. I just wanted to kind of through my $.02 in here. I work > for > an ISP as the network admin, blah blah blah, but I wrote a complete > frontend in PHP for qmail/vpopmail that we use on an everyday basis. > We, > however, are the only ones that use this frontend. All of our > customers > use QmailAdmin, for obvious reasons. The one thing that gets me is > that > in my php frontend I use the valias table for vpopmail, mostly because > I > haven't wanted to write something that rips through .qmail files, but > QmailAdmin is unable to see these aliases/forwards. How hard would it > actually be to put support for the valias table into QmailAdmin? or is > this more of waiting for the vpopmail guys to get support into the > vpopmail lib? I really think all this .qmail processing that is being discussed really should be done through some kind of valias processing structure that accommodates both cdb (.qmail) and sql (no .qmail) environments. That's what the valias binary does. Once that's in place, all the same logic would apply. But it seems like the sooner it is moved to that structure, the better if there is any plan to support valiases. Regards, Bill |
|
From: Tom C. <to...@to...> - 2003-07-17 16:37:10
|
On Thursday, July 17, 2003, at 09:27 AM, Bill Shupp wrote: > Incidentally, this all would have an affect on valias support in > qmailadmin. Has there been any talk or progress regarding valias > support? I can look into adding it, I didn't know much about it until now. I assume it's a setup where all of the aliases are replaced by entries in a MySQL table. If that's the case, it shouldn't be too hard to roll that into QmailAdmin. Could you have a setup with a mix of .qmail-alias files and valias tables? Maybe different configurations for different domains? Or even a domain with some of each? -- Tom Collins to...@to... http://sniffter.com/ - info on the Sniffter hand-held Network Tester |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:34:58
|
On Thursday, July 17, 2003, at 09:20 AM, Jeff Hedlund wrote: > Bill Shupp wrote: >> I may have missed this discussion recently, but why are aliases being >> abandoned? It used to come up once in a while back when I was more >> active with qmailadmin, but it was always rejected. I have always >> felt it's less elegant to push a message back through the queue. Is >> it because of vdelivermail shortcomings? > > It was removed for a couple of reasons (but not due to a vdelivermail > shortcoming). Aliases and forwards are pretty much the same thing, so > it makes it easier to understand for users of the system to add/edit > forwards and aliases in the exact same way. Well, they may "seem" the same to users. But to qmail, they are different: one requires the message to go back through the queue for remote delivery, the other does not. This distinction is really only that relevant for large scale installations where such an implementation might cause a performance hit. > The other reason is that aliases were written to the file using the > /Maildir/. When a .qmail file has a /Maildir/ in the file, it is > delivered directly to the /Maildir/ (this is how qmail works). Since > it is delivered directly, it bypasses the user's .qmail file. The > .qmail file should not be bypassed for 'aliases' since it could > contain forwarding rules, spam rules, filtering rules, etc. Right... while this is solved using valiases (mentioned in my last message), it would not be relevant to cdb users, as qmail-local would still be responsible for local delivery. Regards, Bill |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 16:34:39
|
Tom Collins wrote: >> Ken has been busy recently. 5.3.21 is not available anywhere at this >> point, it needs to be put together. I'm going to scrape together what >> patches are out there and try to help Ken get a release out. > > I still have copies of the messages I sent to Ken, along with other > patches that I want to include in vpopmail. If it's OK with you, I'll > put together a 5.3.21 release today (in the next few hours) and run it > by you guys before it goes out. I'll at least email the CHANGELOG > entries for that release. Sounds awesome! Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:27:23
|
On Thursday, July 17, 2003, at 09:14 AM, Benjamin Tomhave wrote: > Hi Bill, > >> I think this could be done very easily with a shell script. I >> personally don't think it really belongs in the qmailadmin binary. >> Rather, maybe have it mentioned in the UPGRADE document. >> > I think it could be done, too, though it would probably be less > elegant than > through something like PERL or Python, unless there's a magical way to > consistently and generically parse text that would work better than > using > grep and cut and sed. I did it with a shell script on my own system a > month > or two ago (now discarded -- sorry), but I'm guessing there are enough > variances out there to require a lengthier script that is extensible > and > flexible. For what it's worth.... Hmm.. perhaps less elegant. But I don't see what variances would necessitate something very lengthy or extensible. If you use maildir_to_email() from vqmaillocal.c as an example, it's a very simple design: 1. get list of domain paths with vdominfo -d 2. get list of .qmail-* files (not .qmail-default) for each domain 3. look for lines that start and end with "/" 4. convert those paths to email addresses using the logic of the above mentioned function: start from the end and work backwards, with "/" as the delimiter. It's easy to get the actual address that way. sed will do that just fine. You could also su to the user first so that ownership stays the same in the context where multiple /etc/passwd users are used for different domains. >> I may have missed this discussion recently, but why are aliases being >> abandoned? It used to come up once in a while back when I was more >> active with qmailadmin, but it was always rejected. I have always >> felt >> it's less elegant to push a message back through the queue. Is it >> because of vdelivermail shortcomings? >> > The biggest problem is with spam filtering, actually. If you're using > something like maildrop to direct mail to SpamAssassin, incorporating > users' > preferences and then possibly filtering that mail into a Spam folder, > if you > us an alias, the message never gets filtered. This is because qmail-local would not process a user's .qmail file, correct? Isn't this part of the reason valiases were created? It not only stores all this info in a database, but also ensures that qmail-local hands off the message to vdelivermail for any extra processing. Incidentally, this all would have an affect on valias support in qmailadmin. Has there been any talk or progress regarding valias support? Regards, Bill |
|
From: Tom C. <to...@to...> - 2003-07-17 16:27:12
|
On Thursday, July 17, 2003, at 09:20 AM, Jeff Hedlund wrote: >> What's the holdup on Ken's end? Is 5.3.21 available anywhere where >> someone else can take the ball? > > Ken has been busy recently. 5.3.21 is not available anywhere at this > point, it needs to be put together. I'm going to scrape together what > patches are out there and try to help Ken get a release out. Jeff, I still have copies of the messages I sent to Ken, along with other patches that I want to include in vpopmail. If it's OK with you, I'll put together a 5.3.21 release today (in the next few hours) and run it by you guys before it goes out. I'll at least email the CHANGELOG entries for that release. -- Tom Collins to...@to... http://sniffter.com/ - info on the Sniffter hand-held Network Tester |
|
From: Edward M. <ed...@hi...> - 2003-07-17 16:23:06
|
Hello all. I just wanted to kind of through my $.02 in here. I work for an ISP as the network admin, blah blah blah, but I wrote a complete frontend in PHP for qmail/vpopmail that we use on an everyday basis. We, however, are the only ones that use this frontend. All of our customers use QmailAdmin, for obvious reasons. The one thing that gets me is that in my php frontend I use the valias table for vpopmail, mostly because I haven't wanted to write something that rips through .qmail files, but QmailAdmin is unable to see these aliases/forwards. How hard would it actually be to put support for the valias table into QmailAdmin? or is this more of waiting for the vpopmail guys to get support into the vpopmail lib? -- Thanks, Ed McLain > On Thursday, July 17, 2003, at 07:56 AM, Jeff Hedlund wrote: > >> I'm still thinking about #1. I had a thought about maybe >> incorporating that fix into qmailadmin -- since the forward list >> already goes through the list, it could flag those with the old alias >> style and add a new link to fix old alias style if any are present. >> (maybe a link on the bottom of the "View Forwards" screen called "Fix >> Forwards" or something). >> >> Or maybe a script external to qmailadmin is more appropriate. I was >> just thinking of qmailadmin since most of the code is already there. > > I think this could be done very easily with a shell script. I > personally don't think it really belongs in the qmailadmin binary. > Rather, maybe have it mentioned in the UPGRADE document. > > I may have missed this discussion recently, but why are aliases being > abandoned? It used to come up once in a while back when I was more > active with qmailadmin, but it was always rejected. I have always felt > it's less elegant to push a message back through the queue. Is it > because of vdelivermail shortcomings? > >> I'd really like to wait for the stable version of vpopmail so we can >> make a requirement for the next stable QA. >> >> In fact, I think if we release a stable QA -- it will require a >> non-stable vpopmail cycle (5.3.20), and that's not a good idea... ? > > I agree. This would be very confusing for people. > > What's the holdup on Ken's end? Is 5.3.21 available anywhere where > someone else can take the ball? > > Regards, > > Bill Shupp > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > qmailadmin-devel mailing list > qma...@li... > https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel > |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 16:20:03
|
Bill Shupp wrote: > I may have missed this discussion recently, but why are aliases being > abandoned? It used to come up once in a while back when I was more > active with qmailadmin, but it was always rejected. I have always felt > it's less elegant to push a message back through the queue. Is it > because of vdelivermail shortcomings? It was removed for a couple of reasons (but not due to a vdelivermail shortcoming). Aliases and forwards are pretty much the same thing, so it makes it easier to understand for users of the system to add/edit forwards and aliases in the exact same way. The other reason is that aliases were written to the file using the /Maildir/. When a .qmail file has a /Maildir/ in the file, it is delivered directly to the /Maildir/ (this is how qmail works). Since it is delivered directly, it bypasses the user's .qmail file. The .qmail file should not be bypassed for 'aliases' since it could contain forwarding rules, spam rules, filtering rules, etc. Side note: This is unrelated to the catchall not processing the .qmail file when set to a maildir. That is a special case of using the Maildir and is fixed in the upcoming version of vpopmail. >> In fact, I think if we release a stable QA -- it will require a >> non-stable vpopmail cycle (5.3.20), and that's not a good idea... ? > > I agree. This would be very confusing for people. Yeah, and stable software relying on unstable software? That means it's not really stable, right? :) > What's the holdup on Ken's end? Is 5.3.21 available anywhere where > someone else can take the ball? Ken has been busy recently. 5.3.21 is not available anywhere at this point, it needs to be put together. I'm going to scrape together what patches are out there and try to help Ken get a release out. Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Benjamin T. <bto...@so...> - 2003-07-17 16:15:08
|
Hi Bill, > I think this could be done very easily with a shell script. I > personally don't think it really belongs in the qmailadmin binary. > Rather, maybe have it mentioned in the UPGRADE document. > I think it could be done, too, though it would probably be less elegant than through something like PERL or Python, unless there's a magical way to consistently and generically parse text that would work better than using grep and cut and sed. I did it with a shell script on my own system a month or two ago (now discarded -- sorry), but I'm guessing there are enough variances out there to require a lengthier script that is extensible and flexible. For what it's worth.... > I may have missed this discussion recently, but why are aliases being > abandoned? It used to come up once in a while back when I was more > active with qmailadmin, but it was always rejected. I have always felt > it's less elegant to push a message back through the queue. Is it > because of vdelivermail shortcomings? > The biggest problem is with spam filtering, actually. If you're using something like maildrop to direct mail to SpamAssassin, incorporating users' preferences and then possibly filtering that mail into a Spam folder, if you us an alias, the message never gets filtered. Thus, if aliases go away and only forwards exist, all messages delivery to a filtered domain will always get scanned. Because aliases directly wrote to file instead of injecting for final delivery, there didn't appear to be any way to workaround short of the change that's been made. cheers, -ben |
|
From: Bill S. <hos...@sh...> - 2003-07-17 16:05:06
|
On Thursday, July 17, 2003, at 07:56 AM, Jeff Hedlund wrote: > I'm still thinking about #1. I had a thought about maybe > incorporating that fix into qmailadmin -- since the forward list > already goes through the list, it could flag those with the old alias > style and add a new link to fix old alias style if any are present. > (maybe a link on the bottom of the "View Forwards" screen called "Fix > Forwards" or something). > > Or maybe a script external to qmailadmin is more appropriate. I was > just thinking of qmailadmin since most of the code is already there. I think this could be done very easily with a shell script. I personally don't think it really belongs in the qmailadmin binary. Rather, maybe have it mentioned in the UPGRADE document. I may have missed this discussion recently, but why are aliases being abandoned? It used to come up once in a while back when I was more active with qmailadmin, but it was always rejected. I have always felt it's less elegant to push a message back through the queue. Is it because of vdelivermail shortcomings? > I'd really like to wait for the stable version of vpopmail so we can > make a requirement for the next stable QA. > > In fact, I think if we release a stable QA -- it will require a > non-stable vpopmail cycle (5.3.20), and that's not a good idea... ? I agree. This would be very confusing for people. What's the holdup on Ken's end? Is 5.3.21 available anywhere where someone else can take the ball? Regards, Bill Shupp |
|
From: Jeff H. <jef...@ma...> - 2003-07-17 14:56:38
|
Tom Collins wrote: > Ken has dropped the ball on the vpopmail 5.3.21 release, and it may > soon end up on SourceForge as well. > > https://sourceforge.net/tracker/ > ?func=detail&atid=200001&aid=761548&group_id=1 Any idea how long this will take? > I'd like to see two more things get into QmailAdmin before it's > declared stable: > > 1) A tool to go through all .qmail-user files in all domains and > convert aliases to forwards (i.e., Maildir delivery to &us...@do... > format). > > 2) (minor) A compile option to hide the MySQL options on add/modify > mailing list. > > Number 2 is not difficult at all, and can be accomplished with a new > ##t tag and a configure option. I plan on adding it in the next few days. > > Does anyone want to tackle number 1? Do you think a Perl script is > appropriate, or would it have to be a compiled C program? I can > probably whip up some Perl in a few hours to get the job done, but C > could take 2-3 times as long. I'm still thinking about #1. I had a thought about maybe incorporating that fix into qmailadmin -- since the forward list already goes through the list, it could flag those with the old alias style and add a new link to fix old alias style if any are present. (maybe a link on the bottom of the "View Forwards" screen called "Fix Forwards" or something). Or maybe a script external to qmailadmin is more appropriate. I was just thinking of qmailadmin since most of the code is already there. > Is there anything else that should go on this list? Counting of > forwards was broken in 1.0.24, but I already have a fix in 1.0.25. I'd like to see the page navigation go in (I know it's not done yet). But we may have some time while awaiting vpopmail release. > Should we set up CVS on SourceForge? If someone can give me simple > directions, I'd be willing to push my current in-progress work up to > CVS on a regular basis, and could accept patches posted to the > repository as well. I definitely think CVS should go in. "simple directions" are a little difficult, as CVS is not simple :). I can point to some documentation though, that may help out: Official CVS Manual: Version Management with CVS by Per Cederqvist et al http://www.cvshome.org/docs/manual/ CVS Best Practices by Vivek Venugopalan http://www.magic-cauldron.com/cm/cvs-bestpractices/index-cvs-bestpractices.html CVS Quick Reference Card by Andrew Ford (a good 2 page quick ref) http://www.refcards.com/about/cvs.html I don't know if I have the permissions, but if I do, I can get the repository setup if you'd like. And while we're discussing CVS, I'd like to point out the method that the mozilla project uses. Before being committed to CVS, patches are first reviewed by one or more people. Once accepted by one or more people, it gets approval for adding to CVS. This really helps keep the tree fairly stable. If we could setup a management structure like that, I think we'd be better off. Ideas? > I think that all of the other feature requests can wait for the next > development cycle, which I plan on opening up as soon as QA is stable. > I'm even willing to declare 1.0.25 (or maybe 1.0.26) stable and open up > 1.1 before vpopmail is stable. We can continue to patch the 1.0 series > with bugfixes, while adding new features and rewriting parts of 1.1. I'd really like to wait for the stable version of vpopmail so we can make a requirement for the next stable QA. In fact, I think if we release a stable QA -- it will require a non-stable vpopmail cycle (5.3.20), and that's not a good idea... ? Jeff -- /\ /\ .. .. .. jef...@ma... / \/ \ a t r i x . . . . . . . (770) 794-7233 s o f t w a r e i n c .. .. .. http://www.matrixsi.com |
|
From: Benjamin T. <bto...@so...> - 2003-07-17 13:47:03
|
> Ken has dropped the ball on the vpopmail 5.3.21 release, and it may > soon end up on SourceForge as well. > Sorry to hear this, though it doesn't surprise me given the current economy. > 1) A tool to go through all .qmail-user files in all domains and > convert aliases to forwards (i.e., Maildir delivery to &us...@do... > format). > > Does anyone want to tackle number 1? Do you think a Perl script is > appropriate, or would it have to be a compiled C program? I can > probably whip up some Perl in a few hours to get the job done, but C > could take 2-3 times as long. > This should be a relatively easy script to write. I was going to suggest a shell script alternative, but I think the parsing will be complicated enough (from a generic standpoint) that PERL probably would be better. Unfortunately, I don't know PERL. From a high-level, all that should occur is this: -command invoked with the domain in question (use vdominfo -d domain.com to get the full path) -from a shell script standpoint, do a "grep Maildir .qmail*" from the domain's base directory -- does this need to be recursive, too, for some reason? would aliases have been created in users' directories? -for each file that has Maildir in it, take the field directly proceeding /Maildir and the field following domain/ (or whatever the common root is -- this might need to be parsed for commonality from the first line) -with the two fields determined, they should be easily reformatted into &us...@do... format > Is there anything else that should go on this list? Counting of > forwards was broken in 1.0.24, but I already have a fix in 1.0.25. > After this release tree is completed, I like to see a new branch started (perhaps with a new/modified name?) that a) ports over the compiled CGI to PHP, b) integrated vqadmin functions, and c) provides the ability to make authenticated curl-type calls with commandline parms that would work better with automated, self-provisioning systems (since I don't like relying on ssh-keyed CLI methods right now). Putting this all into PHP would go a long way toward solving some of my integration problems which thus far have been worked around with iframes, but really, that's not a full-blown solution. > Should we set up CVS on SourceForge? If someone can give me simple > directions, I'd be willing to push my current in-progress work up to > CVS on a regular basis, and could accept patches posted to the > repository as well. > I'm not a developer, so I can't speak to this, but CVS seems to be the thing to do, and so it probably wouldn't be a bad idea. > I think that all of the other feature requests can wait for the next > development cycle, which I plan on opening up as soon as QA is stable. > I'm even willing to declare 1.0.25 (or maybe 1.0.26) stable and open up > 1.1 before vpopmail is stable. We can continue to patch the 1.0 series > with bugfixes, while adding new features and rewriting parts of 1.1. > Yes, this makes sense, it's time to close out features for this release tree and start looking ahead to the next version. |
|
From: Tom C. <to...@to...> - 2003-07-17 05:27:27
|
Forgetting the fact that the current versions rely on development releases of vpopmail, I think we should discuss all outstanding issues that prevent us from calling QmailAdmin stable. Ken has dropped the ball on the vpopmail 5.3.21 release, and it may soon end up on SourceForge as well. https://sourceforge.net/tracker/ ?func=detail&atid=200001&aid=761548&group_id=1 I'd like to see two more things get into QmailAdmin before it's declared stable: 1) A tool to go through all .qmail-user files in all domains and convert aliases to forwards (i.e., Maildir delivery to &us...@do... format). 2) (minor) A compile option to hide the MySQL options on add/modify mailing list. Number 2 is not difficult at all, and can be accomplished with a new ##t tag and a configure option. I plan on adding it in the next few days. Does anyone want to tackle number 1? Do you think a Perl script is appropriate, or would it have to be a compiled C program? I can probably whip up some Perl in a few hours to get the job done, but C could take 2-3 times as long. Is there anything else that should go on this list? Counting of forwards was broken in 1.0.24, but I already have a fix in 1.0.25. Should we set up CVS on SourceForge? If someone can give me simple directions, I'd be willing to push my current in-progress work up to CVS on a regular basis, and could accept patches posted to the repository as well. I think that all of the other feature requests can wait for the next development cycle, which I plan on opening up as soon as QA is stable. I'm even willing to declare 1.0.25 (or maybe 1.0.26) stable and open up 1.1 before vpopmail is stable. We can continue to patch the 1.0 series with bugfixes, while adding new features and rewriting parts of 1.1. -- Tom Collins to...@to... http://sniffter.com/ - info on the Sniffter hand-held Network Tester |
|
From: Tom C. <to...@to...> - 2003-07-16 15:46:05
|
More cleanup as we get closer to a stable release.
Functional changes: works with non-idx version of ezmlm again, updated
Japanese translation.
Changes since 1.0.23:
Michael Bowe
+ Remove reference to "Aliases" in del_forward.html.
Yuu Andou
+ updated Japanese translation
Tom Collins
+ Converted tabs to spaces in .html files to make editing easier.
+ Fixed mailinglist.c to work with non-idx build of ezmlm again.
+ Cleaned up ezmlm_make in mailinglist.c. Limit SQL options to 64
characters each to prevent buffer overflow in args to ezmlm-make.
+ Changes to mod_user.html to make it more readable and easier to
follow, especially with non-English translations.
+ Configure process searches for 'true' binary in /bin, /usr/bin
and /usr/local/bin. Added -enable-true-bin option to override.
(QmailAdmin uses 'true' for blackhole accounts until vpopmail
supports "#" in .qmail accounts.)
+ Various changes to configure.in (displays more information in
"current settings" at end of configure process).
+ Removed add_alias.html, del_alias_confirm.html, & show_alias.html
+ Change display of forwards for program delivery ("|") and
blackhole/delete ("#"). Now displays in italics, shows "deleted"
for blackhole and program name (without path) including command-
line parameters for program delivery.
+ Cleanup Makefile.am to fix make dist and make distcheck.
--
Tom Collins
to...@to...
http://sniffter.com/ - info on the Sniffter hand-held Network Tester
|
13 messages has been excluded from this view by a project administrator.
