Hello Steve,
SL> As you can see the format appears to be as follows:
SL> .@
SL> The addition of hhmmss reduces the chance of duplication greatly.
SL> Also, the 2nd half of the string I'm not sure is entirely random,
SL> either. I'm sure there are elements of randomness in there, but
SL> I'm
Thursday, April 06, 2000, 9:06:57 AM, Dirk wrote:
SL>> This is untrue. The string, as a whole, needs to be unique, that is the
SL>> /only/ requirement of it per RFC822.
> But that _must_ be guaranteed!! that is _another_ requirement by this RFC.
Dirk, what part of "The string, as a whol
ith the same string after the "@" you get the same MID (stronger
algorithm or not).
SL> the part after the @ is nothing more than a static string for the purposes of
SL> the whole. The Bat! should employ a stronger algorithm on the front end to
ensure unique addresses across instances of TB!. Also, it should continue to
generate MSGIDs since allowing the server to generate it reducing
functionality of TB!, most notably CNTL-BACKSPACE.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm y
27;m also sure the basis is on
SL> something unique.
SL> With that said, I believe it would behoove RITLABS to create a new
SL> algorithm for their MSGIDs to ensure uniqueness as required by RFC822.
SL> Granted the chances are slim as TB! is "small" but it is better to add
In a discussion on the PMMail mailing list the topic of Message-IDs came
up. I used TB!'s MSGIDs as an example of an MUA which generates its own
MSGIDs (PMMail does not do it currently). Here are some examples from my sent
mail, all messages sent in the past hour:
Message-ID: &l
6 matches
Mail list logo
