Correct, the new user will be assigned a new id number, despite having the same user name. Since the messages are linked by id number rather than name, the new user doesn't see the messages which used to belong to the old user of the same name.
As for the old messages, I believe that dbmail-maintenance will delete them for being unconnected, and so the space will be reclaimed anyhow. I believe that the major issue here is that there are any number of situation / administrators who wouldn't want to delete a user if they still had mail in their account, either because they don't want to face killer typos (ie. same reason many people alias mv, cp and rm with -i) or because you might want to expire a large number of older accounts, but keep the ones that are still being used actively (although there are other better ways to do this, I believe in having tools that aid in consistency as much as having administrators adhere to consistent policy). Aaron On Tue, 17 Jun 2003, Jacques Beaudoin wrote: > After doing some test. > > I think that if you delete a user that as messages in the tables > and recreate that user the newly recreate user will not se is old > messages. > > So why be so fussy about deleting messages that belongs to nobody. > > Jacques > > > Aaron Stone a écrit : > > > On the other hand, it wouldn't take a lot of code or any significant > > overhead to run a few queries to see what the user has in the database. > > Further, I believe that in a data-destroying operation like this, there > > should be a warning message by default and a --force option if you really > > don't want to hear about it ;-) > > > > Aaron > > > > On Tue, 17 Jun 2003, Matthew T. O'Connor wrote: > > > > > > If i delete a user is aliases are not deleted thats not a big problem i > > > > just delete via a script is aliases (dbmail-aduser c user -a aliases) > > > > before i delete that user. > > > > > > > > But what about is old mailboxes and messages in the > > > > mailboxes, messages, messageblks tables. > > > > > > I would think this is best handled via referential integrity from the > > > database. I added all the foreign key relationships that seem relevant to > > > my postgres setup, this guarantees that everthing associated with the > > > user gets deleted when the user is deleted (or won't let you delete the > > > user while there is data dependentand on the user, depending on how the > > > foreign key was setup). > > > > > > > > > _______________________________________________ > > > Dbmail mailing list > > > [email protected] > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > _______________________________________________ > > Dbmail mailing list > > [email protected] > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
