On Sat, Sep 20, 2003 at 08:58:37AM -0700, Tim Hasson wrote: > I do not use/like sqwebmail, but what you did simplifies a lot of things. > sqwebmail doesn't do much special. The only thing I like about it is it access > maildir's directly.
Same here, and it can edit maildrop filters. I have on my todo list a maildrop filter editor web page so we can replace sqwebmail functionality, or at least give users a choice. It's pretty far down on my list, though. > > I would too, and I do. The authoritative source of info is in the database, > > and when the users file gets created, the database is consulted for the > > proper value. When it's updated, a script goes back to update the users file. > > This also allows for delivery should the database go down, and is less > > database load in general. > > This is very nice. Can you elaborate more on the above? Do you mind sharing > your script(s)? I've been trying to make time to sanitize my scripts for publication, but I've just been so swamped. That's why it's taken so long to reply, and I apologize. What I basically have is wrapper around each vpopmail command. The billing system sets user preferences such as if they get spam filtering. Then the billing system inserts a task into a database that the mail cluster checks for. It picks up the tasks and runs the wrapper, which involves adding the user with the vpopmail vadduser command, then consulting the billing database for user preferences. The wrapper writes out all the default filters, and quota and spam preferences and all that fun. It's pretty simple, actually. When the spam preferences or the quota settings get changed, the billing system pushes out an update command. The mail cluster picks this up and re-writes the appropriate files. In this way, we have the authoritative source of info available for lookup by billing and tech support, yet the system still runs independantly of other systems. > Yes, I agree. My excuse here was that the second command would only be run if > the maildirsize file was not found. This still has the double exec effect on > delivery to accounts with no quota :/ Yeah, that's a nice and straightforward way of doing it, and probably works fine for low-volume systems. I'm still trying to optimize further by reducing the number of filter files maildrop needs to open, but I haven't come up with a clean way of that yet. Really though, this is all a drop in the bucket when I'm running spamc for spam filtering customers =) --Doug
