Alessio Cecchi wrote:

Why not try to understand how to fix them for help developers in resolving these problems?

That would be awesome. If someone posted a bug fix I'd try to get it released the next weekend. Unfortunately my current job includes a 3 hour per day commute, so my spare time is very limited. Recovering from what was almost a big mistake with some real estate has taken most of my time over the last year. I think I can see the light at the end of the tunnel... Still it'll be at least a month or more before I can spend any serious time with vpopmail. I do have the last 1200 messages of interest from this list to look over when I finally get started.

We could start with the report bugs not resolved that each of us has found in their configurations.

That would be helpful too. Be sure to specify what back end you are using! Actually I need to know all of the ./configure options. I'm sure most of the bugs only happen for certain combinations of options. (The ones none of the developers use.)

Lampa wrote:

> Domain quotas are other problem (ultra minor for me).

Unless someone can come up with a way to manage domain quotas that doesn't cripple a server if you enable them on an existing machine with a number of users you will never see domain quotas come back in vpopmail. So far the consensus is that it is not possible, and that you should use unix disk quotas if you must have domain quotas.

> There is not much working domain limits
> (and missing qmailadmin support for it), it lacks of documentation
> (little detailed, meaning, ...). Big problem for me is adding alias
> over vpopmaild - vpopmaild returns error but alias is created.

Which back end. It seems all the developers use cdb, which is pretty much complete and well tested. MySQL is close. PGSQL kind of works, but doesn't support many options. I think someone is running on ldap, but I'm not sure. As far as I know none of the other back ends are being used, but I do try to keep them with no compile errors. To be viable a back end will need to have someone who is responsible for the module. They should be using it and be able to understand the code, or at least provide good, reproducible bug reports. It would be best if they could take over supporting the back end code.

> There should be 3(4) user levels: System admin, QmailAdmin admin,
> System expert, (Domain admin - postmaster for each domain) - if i
> understand code

3 levels + expert mode.  Any user can be an expert.

basic user - can edit own vacation, forward and password

domain admin - can edit all users / forwards / lists in own domain. Postmaster is the default domain admin, but postmaster can create a different domain admin and that user could remove domain admin rights from postmaster, or even delete the postmaster user.

system admin - can edit all users in all domains, and create and delete domains.

The levels control what the user can access. Expert mode is designed to grant the ability to edit .qedit-* files in a text window. Even a basic user could be granted expert mode, and would be able to type anything they want into their .qmail file. Use this with care since there is no unix protection between most vpopmail users. Users without the expert bit can only edit qmail files through specific functions so vpopmail or vpopmaild can make sure they are valid.

> About problem
> i solved it look at
> (i don't
> know if it proper solution but i think yes)

I wish I was sure it was a proper fix. I'm worried that there might be something that needs to know when wait_read() has a problem, and your fix is hiding it. It should be one of the first things that goes in once I find time. I plan on going through the 1200 messages in reverse order, so the latest reports will be handled first.



Reply via email to