Sure, that works. It's probably the easiest way to retrofit onto an existing system, too. Should also work fine with LDAP, just as long as we mention that an LDAP account needs to be created with this name. Reserved numbers would have been an LDAP nightmare, now that I think about it.
In the future we can have things like... #define DBMAIL_LOST_MAILBOX_USERNAME "[EMAIL PROTECTED]@__" #define DBMAIL_LOST_MESSAGE_USERNAME "[EMAIL PROTECTED]@__" And we'll only need to insert those accounts as the code is written. Now, we just need make sure that these users cannot log in... Aaron Ilja Booij <[EMAIL PROTECTED]> said: > 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 > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
