In fact, there are 12 queries which still check for unique_id != '' (or the
similar <> ''); 10 in db.c and 2 in dbsearch.c.
Off the top of my head, I can't think of any time during the message
delivery that the unique_id field should be empty without a corresponding
indicator in the status co
> My preference is that we do this for 2.1. We still need to do some more
> bugixing in 2.0 (the Mozilla behaviour for instance) and some
> optimizations (see if we have queries that can be optimized or done
away
> with)
Along the lines of optimized queries/indexes, and while the
delivery c
Oh, that's an interesting thought. Makes a lot of sense except that it
leaves a layer of cruft in that the dbmail-adduser wrapper would have to
still use the awful command line syntax now in place :-\
dbmail-user could be one of those binaries that has different default
behaviour depending up
Ilja Booij <[EMAIL PROTECTED]> said:
> My preference is that we do this for 2.1. We still need to do some more
> bugixing in 2.0 (the Mozilla behaviour for instance) and some
> optimizations (see if we have queries that can be optimized or done away
> with)
Perhaps we should set up the
Well, I would like to see a new command 'dbmail-user' where an administrator can
add, delete, or modify the attributes (quota/aliases) of a user.
Then write a wrapper called 'dbmail-adduser' that operates the same as the
current
'dbmail-adduser' but calls the new 'dbmail-user' to do the work.
Bu
My preference is that we do this for 2.1. We still need to do some more
bugixing in 2.0 (the Mozilla behaviour for instance) and some
optimizations (see if we have queries that can be optimized or done away
with)
Changing dbmail-adduser will probably not break to much. Can't we
program it to
Hey,
So I was looking at dbmail-adduser today, trying to remember how to use the
crazy thing... and I'd like to scrap the current command line interface and
replace it with something clean and GNU-ish, using getopt, and without crazy
position dependent overloaded single characters.
Since I
