Michael Monnerie wrote: > On Freitag, 1. Juni 2007 Jake Anderson wrote: >> So you are moving to splitting the messages on logical boundries (ie >> message bodies, headers,attachments) rather than the 512k blocks? One >> would have to think that would help performance on large messages >> greatly? especially if you can (optionally?) move the big files out >> of the DB > > I highly oppose against moving anything out of the DB. After all, we use > the DB in order to have the advantages from it: scalability, (high) > availability, replication, etc. If there are external files, who copies > them to the other servers, etc?
That right. Moving stuff out of the database is not an option. > As I understood, the 512k junks will stay, it's just they are organized > into pieces of attachments, mime-types, etc. There will be a checksum > of each file (md5 or so), so that 2 different e-mails can link to the > same attachment. Half right. The 512k boundary will be dropped. It was there for historical reasons (read: mysql-3.0) and there is no need for it at all anymore. The messages will be split into logical first level mimeparts: no recursion. > > Still there can be the problem of checksum collissions, especially on > really large DBs, so I'd suggest using two checksum algorithms. > Or maybe make an md5 sum over each 512k junk, then apply md5 and sha1 on > those checksums only, for a quicker calculation. > > Under no circumstances it should ever happen that "high secret > attachment" of user A has the same checksum of "funny pic" from user B, > and the DB makes a link for user B to "high secret attachment" of user > A. Definitely. We need an algorithm that will prevent collisions at all cost. Such checksums will only be calculated during insertion to ensure uniqueness of the attachment so they will not affect the retrieval processes (pop/imap). That said, "high secret" stuff should of course have been encrypted to begin with. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
