On Wednesday 29 December 1999 Steve Lamb wrote:
> Tuesday, December 28, 1999, 6:14:39 PM, Sashka wrote:
>> IMHO, Bat doesn't generate them,
> TB! does generate them. From my last message on this topic:
>> mail server adds them to headers.
> This *can* happen if a message doesn't have a MSGID.
Pretty much all mail servers *will* add a Message-ID header
themselves, *if* the message was received without one already.
>> And this only way it will be only one e-mail or article with same number.
> This is false. MSGIDs are generally a mixture of random, incremental and
> static data. If we take the first 4 digits in [EMAIL PROTECTED] as
> random here is how it breaks down.
> 2735 - Random number. I don't think it is purely random, but there it is.
> 991228 - Today's date.
The date-dependant field should preferably go down to second
resolution. If the 'random' number really is just a 4-digit random number,
then there is a high chance of hitting the same number twice in a day
if you send a lot of messages.
A better strategy is to use a 'watchdog' value which is usually
constant, but will increment in order to ensure uniqueness of the
whole id. This is similar to how GUIDs (numbers which *must* be
globally unique) are generated under Windows. Off the top of my head,
you initially generate a random value for this 'seed', store it in
permanent storage along with the time it was last accessed, and
increment it if i) you send more than 1 message within the timer
resolution you are working to (which is why the message-id should
depend down to second resolution!), ii) if the application crashed/was
restarted and you can't guarantee that the seed state was correctly
saved, iii) If you can't be sure that the system clock has not been
altered since the last time you generated an id. In practice (ii) and
(iii) mean The Bat! would have to increment each time it was started
up.
> rpglink.com - The host "sending" the message.
This is also bad - it ought to be possible to set the message-id
domain independantly of the email address of the account. (Consider
the case where you use some sort of redirection scheme - for example
in a big organisation you might be sending from
[EMAIL PROTECTED], but your incoming email address is
[EMAIL PROTECTED] In this case @mycorp.com is a shared resource
(since everyone at mycorp is using it) not specifically owned by you,
or the machine sending the mail.
The standards are pretty clear about this point: the message-id domain
must be a a domain[*] wholly owned by the machine adding the message-id
header. In my case, @kanargh.force9.co.uk is fine, since this is *my*
domain and no-one elses, but @mycorp.com is definitely bad, as would
be anything like @hotmail.com (unless added by hotmail's own
servers!). In cases where you don't have your own FQDN but need to
generate a message-id yourself, a suggested strategy is to prefix your
username onto the message-id domain so for example @myself.mycorp.com
would be acceptable. But this requires that this string is
configurable from within The Bat! somehow.
[*] Actually, "domain" is too strict. There is no requirement that
the message-id domain part be an actual DNS domain, only that it
be a string belonging wholly to the host generating the header.
By convention this has meant a string based around the
generating host's FQDN.
And for most situations: if in doubt, leave it out. If the mailer
doesn't add a message-id header, the transport will. We should have an
*option* to turn off message-id generation in The Bat!
> For a duplicate MSGID to be generated it would have to be from this host,
> on this day, with the same first 4 digits. That, alone, is a virtual
> impossibility.
Is it? If the number is purely random? If there are no other
constraints on how this number is chosen, I think you'd be surprised
at how often duplicates could happen.
> Now, the mail servers do basically the same thing. They will use a mix of
> constant and dynamic data to guarentee that the chance of a duplicate is
> virtually impossible to come up with.
Not *virtually* impossible - *actually* impossible. The standards are
quite clear that duplicate message-ids must not occur. (This is
especially important with news, where the whole flood-propagation scheme
relies on unique message-ids, but it also applies to mail messages.)
> Having the server attach a MSGID to a
> message does not make it any more or less likely of a duplicate.
Well, it *does* if your mailer chooses bad message-ids: most mail
servers choose good ones!
> In fact, all
> it does is prevent you from doing a search on the MSGID of your own messages
> since they are not a part of your sent-mail.
True, however you could always bcc yourself and save these messages
using a filter rule instead of using the default 'Sent' folder.
John
--
you gave me something that i could touch in a world where i'd had too much
something i could feel with my broken hands full of lost ideals but soon i'm
returning to you my friend and we'll go where the rivers end in the silver sea
and i'll carry you if you carry me
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
