> Did you actually read the change log entry?? How do you get "fail-safe > recovery method" from "vdelivermail will auto create a users directory if > thier directory value in thier authentication structure is blank. This can > be used by sql based systems, or ldap systems. > Users can be created and inserted into the database, and if their path value > is left blank, vpopmail will use the bigdir directory layout algorythm to > create a directory and update the authentication database. So, users can be > created by just adding them to the database and leaving thier directory path > blank." > > The key part, in case you missed it, is "Users can be created and inserted > into the database, and if their path value is left blank, vpopmail will use > the bigdir directory layout algorythm to create a directory and update the > authentication database. So, users can be created by just adding them to the > database and leaving thier directory path blank." > > That sure doesn't look like a "fail-safe recovery method" to me. That looks > like inserting directly into the database for user creation was specifically > designed in.
Yes, however when that was done, there was never a concept of enforcing limits back then. Justin just submitted a patch to actually enforce these limits at, yes, the API level where it belongs. This *will* break if you insert into a backing store directly. I still believe: Bypassing the supplied API is a kludge. (A raw datastore is *not* an API, you lose control over validation and many other features if you don't have a single thread of control over these. I don't believe the original author understood the implications of that statement and probably didn't do a request for comments on the list prior to that). I'll agree that qmailadmin should also have some recovery code built into it, however I still disagree that anyone should ever insert directly into a datastore. Brian
