OK,
What I've done now is used a constant username for the dbmail delivery user:
#define DBMAIL_DELIVERY_USERNAME "[EMAIL PROTECTED]@__"
On delivery, dbmail looks up the user_idnr of this user, and inserts
the message in it's mailbox.
this user is added by both create tables scripts and migration scripts.
Using this scheme, we do not have to use a user_idnr of 0.
Ilja
Ilja Booij wrote:
To me, the cleanest way to solve this is by adding a boolean column to
the users table, which holds 1 if the user is a 'system' user, and 0 if
it is a normal user. System users can be used for special stuff like the
delivery chain, and cannot log in using IMAP or POP.
Functions like auth_user_exists() will then still return the user_idnr
of a user, but functions like auth_validate() will always return 0 (not
validated), when called with this user as an argument.
This way, we do not have to reserve a range of numbers for special users.
Any thoughts on this?
Ilja
Aaron Stone wrote:
A few weeks ago, while Ilja and I were working on integrating my LMTP
and Sorting patch, I asked Ilja what he thought about reserving user
id numbers 1-10 or 1-100 (or 1-9 or 1-99, ie all single or double
digits, whatever) for system accounts. There are some interesting uses
for reserved accounts, particularly with foreign key constraints. Lost
mail, unowned shared mailboxes, stuff like that. At the time we
figured that minimal rocking of the boat was in order while my patch
was going in, since we wanted people to begin testing it right away.
So I'll share the idea with the mailing list: shall reserve a range of
user id numbers? Will this be too difficult to migrate? Would you be
comfortable using a script that renumbered some of your lower-numbered
of users?
Aaron
""Christian G. Warden"" <[EMAIL PROTECTED]> said:
On Sat, Jan 31, 2004 at 09:32:29PM -0000, Aaron Stone wrote:
The new delivery chain requires a temporary account with the fixed
user id
number 0. The next release candidate should probably include an
appropriate
insert/update to add this user (note that it needs to be an insert
and then an
update, because the insert alone with '0' triggers the auto_increment.
INSERT INTO users (user_idnr, userid, passwd) VALUES (0, '*', '*');
UPDATE userid SET user_idnr = 0 WHERE username = '*';
We should consider using something else besides user_idnr = 0, for this
special account. Perhaps, username = 'delivery' (or whatever) and
client_id = 0, or even a special boolean column just for this user.
Using user_idnr=0 has some unfortanate side-effects with mysql. If
you're joining between aliases and users on deliver_to = user_indr,
mysql considers 0 equal to any string, e.g.
SELECT
IF (u.user_idnr IS NULL, a.deliver_to, u.userid) AS recipient
FROM
aliases a
LEFT JOIN
users u
ON
u.user_idnr = a.deliver_to
WHERE
a.alias = "[EMAIL PROTECTED]"
Also, when altering the table, you can run into key violations as mysql
helpfully tries to replace the 0.
xn
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
IC&S
Stadhouderslaan 57
3583 JD Utrecht
PGP-key:
http://www.ic-s.nl/keys/ilja.txt
