Subj : Re: message-id
To   : andrew clarke
From : Dale Ross
Date : Thu Nov 21 2002 01:26 am

ac> ========FTN PACKET HEADER (PKT_MSG20):========
ac> type          2
ac> origNode      1
ac> destNode      1
ac> origNet       379
ac> destNet       379
ac> AttributeWord 0
ac> cost          0
ac> DateTime[20]  05 Nov 02  11:22:08
ac> toUserName    Jasen Betts
ac> fromUserName  andrew clarke
ac> subject       message-id

ac> ========FTN MESSAGE SOURCE:========
ac> AREA:NET_DEV
ac> @MSGID: 3:633/267@fidonet 3dc76ac0
ac> @TZUTC: 1100
ac> @REPLY: 3:640/531.42 1eb6d8b9
ac> @TID: hpt 0.9.7d-stable/w32 02-01-01
ac> Thu 2002-10-31 20:01, Jasen Betts (3:640/531.42) wrote to andrew
ac> clarke:

ac>>> FTS-9 MSGIDs are not unique enough to be accurately relied upon.

>> sure they are, FTS-9 says they don't reapeat for three years,

>> of course many implementations don't ensure that.

>> IMO what's needed is a proper implementation of FTS-9

>> eg using sequential numbers from a single source for all the messagids
>> on the system.

>> At it simplest This means about 15 lines of C. (or pascal, bssic etc)
>> in each program where they generate the message-ids, and a key file
>> somewhere where all the mail processors can reach it,

ac> Good in theory, but not going to work if you don't have the source code
ac> to everything unfortunately.  I guess the good thing about this is that
ac> more and more people are using open source FTN software, if not most of
ac> them, so there may be hope yet!

ac> It could be unreliable if the key file goes missing or gets corrupted
ac> (eg. two programs trying to write to it at once) but is probably not
ac> such a bad solution if you decide not to generate random numbers.
ac> Particularly if the user can decide for themselves which method to use.

ac> Although I still think a random number generator seeded with the year +
ac> month + day + hour + minute + second + subsecond would do a pretty
ac> reasonable job if the string to be generated was long enough.  I guess
ac> I should do some tests.

ac> In any case Charles Cruden's idea of basically allowing any unique
ac> string seemed the most logical in hindsight.  You could then have a
ac> combination of user-supplied-data + random number + MD5 of the message
ac> text, or any other combination you wanted to use...

>> Maybe another kludge could be added to indicate the the msgid so
>> generated is guaranteed to be unique.

ac> May as well invent a new kludge that does both.  ;-)

ac>>> Implementations that generate a Message-ID may also optionally
ac>>> generate a MSGID conforming to the FTS-9 standard for systems that
ac>>> do not recognise the Message-ID.

>> is there going to be a replacemnt to the REPLY kludge too ?

ac> Yep.

>> one solution to different applications generating matching msgids is to
>> give the different appications diffrerent addresses - eg give the news
>> autoposter a point address so it can't clash with the message editor.

ac> Quite true, but not always practical.

ac> -- [email protected]

ac> --- Msged/NT 6.1.1
ac>  * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)
ac> SEEN-BY: 10/345 28/1 105/8 106/1 124/5009 143/2 150/220 205/1 229/1000
ac> 3000 SEEN-BY: 247/101 250/99 254/6 275/311 278/230 280/5003 282/4066
ac> 311/13 SEEN-BY: 322/320 343/41 362/627 379/1 1200 396/45 633/267
ac> 751/321 2604/416 @PATH: 633/267 285 260 774/605 123/500 106/2000 140/1
ac> 250/501 280/100 28/1 @PATH: 10/345 379/1

ac> ========FTN MESSAGE END============


Sorry for the long quote and no reply. This message took TWO WEEKS to arrive
here.

With best regards, Dale Ross.  E-mail: [email protected]

--- Fidolook Lite FTN stub
* Origin: FidoHub Point 1 (1:379/1.1)