Blake Mitchell wrote:
Is all this going to fit in 32 bits?
Not a chance. Storing a date/time in human-readable form is inefficient -- we use a unix timestamp (seconds since 1970-01-01 00:00 +0000) which is 32 bits all by itself.
If you want to add microseconds, PIDs, host IDs, etc then the storage requirements will blow out considerably. We ended up using a 14 character hex string as our GUID -- 8 for the 32-bit timestamp, 2 for the host ID and 4 for a PID (all our systems have 16-bit PIDs).
Kevin Baker wrote:I'd be concerned about using the pid. The pid on each machine could be padded to different lengths causing the numbers to be non-ascending between servers.
Which is why we encode the pid as hex, padded with leading zeros. If your field is long enough to store the longest possible PID, this works.
With a machine id set in the dbmail conf we'd have control over this. Example with pid: [YYYY][MM][DD][hh][mm][SS][ss][pid] if you had two messages arrive at the same time with a pid of 123 on machine one and 95432 on machine two they would be out of order and nonsequential. In addition it is very unlikely, but the pids could be the same making the id non-unique, thus non rfc. The other way: [YYYY][MM][DD][hh][mm][SS][ss][server-id] server one 0001 server two 0002 So long as the ids are padded to the same length across machines in a cluster the number would always be ascending and unique. If messages did happen to come in at the same time they would never collide, because of the padded server-id suffix. [external-ip][YYYY][MM][DD][hh][mm][SS][ss][server-id] I like the idea of possibly adding a prefix to the id though.. something unique to the email solution such as the clusters external ip... this could also be set in the conf pulled from the message header. This would actually make the ids unique globally, while keeping the ascending order. However by RFC they only need to be unique to the mailbox(folder). - KevinI don't think so.. I'm pretty sure that the email client will just refresh the mailbox it is displaying.. messages are then sorted by message-id or other if in the view settings. We have had this happen in our current configuration cyrus as messages can sometimes get caught up in amavis running through filters for a second or so... they just appear and everthing is fine... <snip long text>I'm not at all familiar with IMAP, would that cause any problems with imap clients, having "old" unique-id's popping<snip>"new" messages have what appears to be out of sequence
-- Simon Cocking <[EMAIL PROTECTED]> Network Operations MailGuard Pty. Limited Email anti-virus, anti-spam and content filtering Melbourne 68-72 York St South Melbourne VIC 3205 P +61 3 9694 4444 Sydney Level 39, 2 Park Street Sydney NSW 2000 P +61 2 9004 7889 http://www.mailguard.com.au/mg
smime.p7s
Description: S/MIME Cryptographic Signature
