On Tue, Nov 18, 2003 at 01:34:58PM -0600, Gary Murphy wrote: > The new table contains message_idnr, mailbox_idnr + all message flags. The > messages table no longer contains copies of these. This allows one user to > store multiple copies of a message as long as she/he only stores one copy in > a mailbox. It also allows multiple users to store copies in their > individual mailboxes.
What would happen if someone tries to store multiple copies of the same message in a mailbox? > > Even better might be to allow the same message to be delivered to > > different users by separate invocations of dbmail-smtp and only storing > > a single copy of the message body based on Message-ID, but separate > > versions of headers for each user allowing headers such as Envelope-To > > without exposing bcc'd recipients. > > I had not thought about the Bcc: issue. Sendmail, etc. should strip this > but if it does then I will have to accept one call per user to be inserted, > which will generate different headers but isn't optimal. If it doesn't I > will strip the Bcc: out within dbmail-smtp, which I prefer. However, beyond > not exposing blind-copy users, which I have no intention of doing, I do not > understand what would be gained by storing a separate header for each user. > Is a separate Message-ID and or Envelope-To really that important as long as > blind-copy users are not exposed? The message can be easily identified by > one Message-ID and it's internal unique_id will always be the same no matter > who is on the recipients list. I have my MTA configured to add an Envelope-To during delivery. This is helpful if you have multiple aliases and you want to see what address a message was sent to when none of the addresses in the To or CC headers are yours. > > Even more ambitious would be to parse MIME and store only a single copy > > of unique MIME attachments so users who forward around 10MB files don't > > take up so much space. > > Attachments are stored by dbmail as part of the message body within a > messageblk, so only one copy will ever be stored, if this approach works. I was thinking one copy per unique attachment rather than per message so messages with large attachments forwarded to additional recipients wouldn't take up so much space. So, when dbmail-smtp gets a new message, it parses the MIME attachments, generates a checksum on each attachment, stores unknown attachments and links to ones already in the database. This would obviously be a pretty big architectural change. xn
