A few years back I talked to several people/sites that were maintaining thier email systems with pre-existing systems. They wanted to switch over to vpopmail. A very clean and simple way for them to add users was to insert a user record into the mysql database, then have vpopmail create the users directory and update the database when mail arrived or they popped in. Seemed like a very nice way to integrate backend systems with vpopmail.
So we intentionally put in code to vdelivermail and vchkpw to automatically create the users directory if their pw_dir field was blank. The only dependency in this case is granting insert access to the mysql database for the existing system. Usually they were already using mysql, so this was not a problem. The other way would be to have the backend systems exec a shell on the email system to run the vadduser program, or link in the vpopmail API. This method has many more dependencies. Here is a example of a discussion I've had with back office people 1) Without direct insert support Ken: You'll need to do this and that and the other thing... BackOffice Guy: Wow, I'm not sure if we can do that. I'll have to get with the developers and the security guys and ask my manager...etc. 2) With direct insert support Ken: just insert these fields in the database (pointing at field list) BackOffice Guy: Great! That looks easy. Hence was born support for linking back office systems to vpopmail via the mysql database. Ken On Tuesday 25 March 2003 11:09 am, Dave Weiner wrote: > Brian Kolaci wrote: > > Yes, however when that was done, there was never a > > concept of enforcing limits back then. Justin just submitted > > Again, I think you're wrong. As early as 4.1 there was quotas of some > sort. I believe the limits you're refering to those that are specified in > the .qmailadmin-limits file, which are a function of qmailadmin to limit > how many accounts, etc, a postmaster can create. > > > 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. > > Exactly what limits are you refering to? > > > 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). > > Ken, as the original author, could you please enlighten us with your though > process instead of us guessing? > > > 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. > > I strongly disagree, and I'm doing it for a email service I run for a > non-profit. The potential user enters the username they want, I check to > make sure there is no other user or alias with that name, I "reserve" that > username for 30 min, get the credit card number from them, processes it, > and if the charge goes through, I insert a record with the username, > domain, crypted and clear text password and quota. The account is now > available for immediate use. So explain to me exactly what validation and > other features I've lost control over? > > > Brian > > Dave
