Hmm, actually, there's a pretty big chunk of code in my patch that allows delivery to a non-existant mailbox and creates it in the process. The way I set it up, the mailbox is looked up first with a simple select and if it does not exist, an attempt is made to create the mailbox. The code sort of "double falls back" so that if it can successfully create the box and retrieve the mailbox_id, the message is delivered and if that fails, the message is bounced (or delayed? don't recall...).
The interaction with this database schema is to add another check that requires the mailbox to exist before the message insertion can succeed, and that's fine because if the message insertion fails the message is bounced to the MTA and can be retried later. About my use of 0 as the "magic id" for the "dbmail built-in account" I think that might need to change to 1 because it actually took two tries to force an id of 0 in an auto_increment column. If we get rid of auto_increment and use our own unique primary keys, then this isn't a problem anymore. In any case, I very much like the idea of requiring a built in account, basically a postmaster account, because in my experience, every mail system needs some way of collecting the junk that's bouncing around and sticking it someplace! Aaron On Mon, 16 Jun 2003, lou wrote: > In some email I received from "Jesse Norell" <[EMAIL PROTECTED]> on Mon, 16 > Jun 2003 12:56:49 > -0600 (MDT), wrote: > > > > > Hello, > > > [...] > > > > This would break all non-INBOX deliveries. > > Agree. > > [...] > > This may have implications with shared folders, but those > > aren't implimented just yet either, so... > > Please share:) > Somewhere i have a design for shared folders, I needed it fast so I manage to > alter > WeDBmail to do so, i didnt get any implication with it. > (considering that i didnt have to go along the rfc standart, right?) > > > > [...] > > I've not looked at Aaron's recent filtering patch, but this > > may have reprecussions there - I think at one time there was > > a possibility of setting mailbox_idnr to 0 for pre-filtered > > messages, and updating later. > > I understand, but we can still force ID 0 for temporary messages or > messages which are being filtered? and we keep consistency with the other > objects. > > I'll look further in the code to see if there are any other implications. > > > Another note: along with all the foreign keys, which are > > a good idea where appropriate/possible, quite a few of the > > indexes that have appeared on the list can be dropped. A > > primary key already gives you a unique index on the column, > > and a foreign key gives you an index (non-unique) as well. > > Correct. That's sounds like a call from db scheme cleaning ;) > > cheers > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
