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