Re: Next 5.0 features
I think that vpopmail should use rcpthosts/morercpthosts, virtualdomains and assign file correct, according to qmail's philosophy. There is no reason to have an alias domain in the assign file at all. The only place the alias domain should be placed in qmail, is in the rcpthosts/morercpthosts and virtualdomains. realdomain.com and aliasdomain.com control/rcpthosts: realdomain.com aliasdomain.com control/virtualdomains: realdomain.com:realdomain.com aliasdomain.com:realdomain.com user/assign: +realdomain.com-:realdomain.com:1000:100:/home/vpopmail/domains/realdomain.c om:-:: . I have never understood why messing around with softlinks of directories and make things harder when it comes to vpopmail and aliasdomains! m2c regards -- IDG New MediaEinar Bordewich Development Manager Phone: +47 2336 1420 E-Mail: eibo(at)newmedia.no Lat: 59.91144 N Lon: 10.76097 E - Original Message - From: "Ken Jones" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 02, 2001 5:26 AM Subject: Next 5.0 features We are looking at the features to add to the vpopmail 5.0 release. Here are the current major changes we are thinking about 1. vqmail-local support. This means, a new vpopmail program that can be used to replace qmail-local for sites which are primarily running vpopmail users/domains. For large volume sites this means one less fork/exec for email deliveries. What this means: a) Kris's additions to vpopmail for qmail-local type processing. Integrating his work into the current vpopmail archecture. b) new API's to support add/del/modify of dot-qmail type files. c) modifications to each authentication module to support dot-qmail file tile processing d) backward compatibility to support standard dot-qmail file setups on current machines. 2. qmailadmin support for new vpopmail api's a) backward compatibility to read the current dot-qmail files for mailing lists, forwards, aliases and autoresponders b) support for the new vpopmail api to get/set dot-qmail information. 3. Code review for efficency These are the things that are important to me. If anyone here has things that are important to them, please speak up. Perhaps what you have to say will solve problems that other people are seeing. Ken Jones PS: I think I've got an idea for modifications to sqwebmail/courier-imap makefiles to support the ~vpopmail/etc/lib-deps and lib-inc file. I would be interested to hear real world experiences from folks who are running vpopmail(etc). Perhaps we can figure out what needs to be changed to make it a better package.
FW: Next 5.0 features
-Original Message- From: Russell "Elik" Rademacher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 11:27 AM To: Joe Modjeski Subject: RE: Next 5.0 features Know what other little feature would be great for this? The limit of email accounts per domain. So that it is more realistic to offer to the customers of which account package they want and limit the number of email accounts per domain. -- Linux Administrator Consultant Russell "Elik" Rademacher -Original Message- From: Joe Modjeski [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:15 PM To: [EMAIL PROTECTED] Subject: RE: Next 5.0 features I would be interested to hear real world experiences from folks who are running vpopmail(etc). Perhaps we can figure out what needs to be changed to make it a better package. Nobody else seemed to mention this. I would like api calls to the functions that vmoduser performs. Currently I have to make system calls from my biniaries to get the deactivate/reactivate features out of vpopmail. My idea would work something like: (some sort of info struct) vmodinfo( char *user, char *domain ); int vmodset( char *user, char *domain, (same struct as above) ); int vmodclear( char *user, char *domain ); Also from most of the requests for qmailadmin. It seems that the project needs to branch from just qmailadmin to qmailadminadmin. This would be pretty cool. I do like the vpopmail API calls rather than just a webbased utility. The web is good for my customers but I want the control at the command line. Joe Modjeski [EMAIL PROTECTED]
Re: FW: Next 5.0 features
-BEGIN PGP SIGNED MESSAGE- Hello Joe, Tuesday, February 06, 2001, 7:35:18 PM, you wrote: -Original Message- From: Russell "Elik" Rademacher [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 11:27 AM To: Joe Modjeski Subject: RE: Next 5.0 features Know what other little feature would be great for this? The limit of email accounts per domain. So that it is more realistic to offer to the customers of which account package they want and limit the number of email accounts per domain. You're aware of .qmailadmin-limits, aren't you? Or are you giving your customers root access so they can set their own accounts up? Best regards, Gabriel -BEGIN PGP SIGNATURE- Version: PGP 6.0.2i iQEVAwUBOoA6LcZa2WpymlDxAQGfYQgAox0mzZH97Z5Rfaimi9z8rVdu72mCCFsb wiEpVV4BlDP9tWyrzdvGAx89A29F/4TH9lqTrFdt8hzRc5FjZTRf5TlYnee9TBYW /gGkl/WEypqO4grtfYhVAWbk7UvUAI+EAQ3FOKudCZWn5uU4/C+jCLk/d0aLwVHU Q378uyZG1BTqApKHQoGzNOkR37WVS5FmZs5IyBZkmCUePxRrGFgFoolX3YC3knLT SxWWt+GuTY2KZSfq8TstN9LA5ui2FSgEjt3YBoNlCdlvvYTu74Twp1Pbvn68FVLB KDjyr5bvO96u3AZTKJTYx+YQwadeMySc1ElC99R956Ho6AR7tVD4og== =POzi -END PGP SIGNATURE-
Next 5.0 features
Not related to vpopmail but since you guys do qmailadmin as well here it goes. It would be nice for qmailadmin to report when was the last time the user visited his account so that on large systems one could delete non-active accounts. My 2 cents. Leo.
Re: Next 5.0 features
(Sorry, I continue to write to vpopmail list, abot not directly vpopmail.)
Good idea...
Also, wouldn't it be a nice feature if swebmail prints something like:
--
{Last time}
You've been logged in at: 5 Jan 2001, 20:45 (GMT+2)
From: dialup-2912.yourisp.net
--
A webmail user will be aware of strangers using her/his account.
=
= M. Guven Mucuk
= [EMAIL PROTECTED]
=
= BerkNet Internet Services
= UNIX System Administrator
=
RE: Next 5.0 features
At 2/4/01 06:10 PM, Richard Antecki wrote: Automatic creation of maildir's on receipt of email if an account exists in the authentication database. ... Wouldn't anyone else find this useful? Absolutlely!! -- Dennis Nichols [EMAIL PROTECTED]
RE: Next 5.0 features
The only thing I wish for not on the list is integrated (lightweight) filtering. The current filtering patch would be great if it worked a little better (it's got some issues, alas), but anything else like it would be great too. And of course, qmailadmin support so users can set their own filters. Ron
RE: Next 5.0 features
Something that I was wishing for a while ago... (and maybe I won't have to keep patching vpopmail every time I upgrade!!): Automatic creation of maildir's on receipt of email if an account exists in the authentication database. This enables any custom (possibly remote) administration software to administer mail accounts via a SQL database only and not have to worry about interfacing with vpopmail API's etc... Deletion is not so time critical and can be implemented by setting a flag in the user's auth entry. A cron script can be set to run periodically and delete these maildirs. The only other implication is that POP will complain that the directory doesn't exist if a user check their mail before receiving any. This can be resolved by automatically mailing a welcome message when the account is created (or by patching the POP daemon). Wouldn't anyone else find this useful? Some people were enquiring recently about PHP API support. This modification could make linking with the vpopmail API unnecessary as everything (authentication, adding/deleting accounts, adding/deleting domains??) can be done through SQL. --Richard
Re: Next 5.0 features
I recommend updating the "load_limits()" function of qmailadmin to load/maintain the "limits" from a mysql table rather than a file. Also, an interface to maintain this table would be nice. I think the same While in the limits, maybe add a domain quota to the limits table too... I'm on this too - I was looking the code to add this feature, too - I'm making the translation of qmailadmin to spanish, when I finish the translation I will send it to Inter7 Pablo Murillo [EMAIL PROTECTED] == RED NET ARGENTINA Internet Solutions == Paraguay 419 Piso 2 Of.5 (C1057AAC) - Capital Buenos Aires - Argentina Tel Fax:(011)4315-3269 http://rednet.com.ar ==
Re: Next 5.0 features
I've updated my copy of qmailadmin that loads the limits from mysql already, if interested... Thanks, Brian I recommend updating the "load_limits()" function of qmailadmin to load/maintain the "limits" from a mysql table rather than a file. Also, an interface to maintain this table would be nice. I think the same While in the limits, maybe add a domain quota to the limits table too... I'm on this too - I was looking the code to add this feature, too - I'm making the translation of qmailadmin to spanish, when I finish the translation I will send it to Inter7 Pablo Murillo [EMAIL PROTECTED] == RED NET ARGENTINA Internet Solutions == Paraguay 419 Piso 2 Of.5 (C1057AAC) - Capital Buenos Aires - Argentina Tel Fax:(011)4315-3269 http://rednet.com.ar ==
Re: Next 5.0 features
On Thu, Feb 01, 2001 at 10:26:51PM -0600, Ken Jones wrote: 3. Code review for efficency These are the things that are important to me. If anyone here ... 0. Code review for stability. Always check ALL return values to avoid incomplete creations. Make vpopmail.pm understand when to use users table, and when - vpopmail. Chrck once again quite messy code in vmysql.c. Add ability to specify SQL login/password at configure-time. Thanks for great package, wishing to kick bugs off it, Alex.
Re: Next 5.0 features
I would be interested to hear real world experiences from folks who are running vpopmail(etc). Perhaps we can figure out what needs to be changed to make it a better package. I agree that it is a wonderful package, and the only possible improvements I can think of are some general code tidying up (sometimes i get segfaults, and odd sounding error messages (like 'domain already exists' with vdeldomain)). And finally, id highly recommend putting Kris' dbfunction patch in with the package. It works perfectly, never had a problem with it, no errors, very stable.
Next 5.0 features
We are looking at the features to add to the vpopmail 5.0 release. Here are the current major changes we are thinking about 1. vqmail-local support. This means, a new vpopmail program that can be used to replace qmail-local for sites which are primarily running vpopmail users/domains. For large volume sites this means one less fork/exec for email deliveries. What this means: a) Kris's additions to vpopmail for qmail-local type processing. Integrating his work into the current vpopmail archecture. b) new API's to support add/del/modify of dot-qmail type files. c) modifications to each authentication module to support dot-qmail file tile processing d) backward compatibility to support standard dot-qmail file setups on current machines. 2. qmailadmin support for new vpopmail api's a) backward compatibility to read the current dot-qmail files for mailing lists, forwards, aliases and autoresponders b) support for the new vpopmail api to get/set dot-qmail information. 3. Code review for efficency These are the things that are important to me. If anyone here has things that are important to them, please speak up. Perhaps what you have to say will solve problems that other people are seeing. Ken Jones PS: I think I've got an idea for modifications to sqwebmail/courier-imap makefiles to support the ~vpopmail/etc/lib-deps and lib-inc file. I would be interested to hear real world experiences from folks who are running vpopmail(etc). Perhaps we can figure out what needs to be changed to make it a better package.
Re: Next 5.0 features
I would be interested to hear real world experiences from folks who are running vpopmail(etc). Perhaps we can figure out what needs to be changed to make it a better package. Overall, vpopmail is a fantastic package - the only issue I have is the way it hashes the directories i.e. /0 /1 /2 etc.. it's rather counter-intuitive and rubs me the wrong way for some reason.. :) Unfortunately, the only other idea that I have for this is to actually hash the mailbox name (or similar) into a ad87hdk style hash (which is not exactly intuitive either :) Apart from that, I love it. :) //umar.
