about my fix:

is nothing hiding, because after wait_read are check for returned
variable (read_size) - in main() //  Read size < 0 means timeout  --

i think that select() return that was activity on descriptor but
descriptor send eof and fgets when read oef returns NULL (eg.
terminate connection but vpopmaild is still tries reading)

I'm not sure but i think that vpopmaild is work of Bill Shupp, isn't it ?

2008/10/8 Rick Widmer <[EMAIL PROTECTED]>:
> 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 http://www.mail-archive.com/vchkpw@inter7.com/msg25601.html
>> i solved it look at
>> http://www.mail-archive.com/vchkpw@inter7.com/msg26090.html (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.
> Rick



Reply via email to