TID: FMail-lnx64 2.1.0.18-B20170815
RFC-X-No-Archive: Yes
TZUTC: 0200
CHRS: UTF-8 2
PID: GED+LNX 1.1.5-b20161221
MSGID: 2:280/464 60731d99
REPLY: 2:221/1.58@fidonet ef51437e
Hi August,

On 2021-04-11 08:56:00, you wrote to me:

 WvV>> There are those moderator messages that stay the same for
 WvV>> ages...

 AA> Not if the hash includes the entire msg and the date posted.

Ok. But the serial based ones are still better. ;)

 WvV>> A good secure hash, needs a lot of cpu to be calculated.

 AA> Even a simple random num generator could work.  For example, the
 AA> following took less than a sec to produce:

 H:\myutils>> rando2
 AA> lfz$bkmcmmg36ye@jll1xpieaats

Those aren't 32 bit.

 AA> So..  why couldn't something like that be implemented? And,
 AA> instead of limiting the "serialno" to hex chars, use the entire
 AA> alphabet and throw in some extra chars (# $ ~ % & *)

Well it could if it complies to the standard. The serial based ones are still
better, because they take less cpu. And they can be made so they don't repeat
within three years. With random numbers, or with hashes, there's always a
change of a collision within 3 years.

 AA>>> Synchronet systems have come up with another unique
 AA>>> approach to the MSGID line which seems to cooperate with
 AA>>> existing systems quite well.

 WvV>> It isn't according to the standard, which might cause some
 WvV>> problems on other systems.

 AA> I thought it was copacetic with other systems. On which ones
 AA> does it break?

I don't know, but it is not according to the standard, so it could cause
problems. That doesn't directly mean that things noticeably break. But maybe
dupe detection doesn't work as reliable for those...

 WvV>> And I think it went like this: They miss used the MSGID to
 WvV>> store some internal information for their messagebase, and
 WvV>> came up with an excuse afterwards, when it was difficult
 WvV>> to correct.

 AA> I remember something about the MSGID being referred to as a two-
 AA> part string with "origaddr" + "serialno", where "origaddr" is
 AA> intended to be a qualified "address of the originating system".

No: "... address for the originating network"
                                     ^^^^^^^

http://ftsc.org/docs/fts-0009.001

 AA> Most systems keep it simple:

 AA>  z:f/n.p hhhhhhhh

 AA> And some others look like:

 AA>  n.areaname@z:f/n.p hhhhhhhh

That's not a valid fido address.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
 * Origin: FMail development HQ (2:280/464)
SEEN-BY: 1/123 18/200 90/1 105/81 114/705 120/340 123/120 131 124/5016
SEEN-BY: 129/305 153/250 154/10 203/0 220/70 221/0 226/17 30 227/114
SEEN-BY: 229/101 424 426 452 664 700 1016 1017 240/5832 249/206 317
SEEN-BY: 249/400 250/5 8 267/800 280/464 5003 282/1038 288/100 292/8125
SEEN-BY: 298/25 301/1 305/3 310/31 317/3 322/757 340/1000 342/200
SEEN-BY: 396/45 423/120 460/58 633/280 712/848 770/1 100 330 340 772/210
SEEN-BY: 772/220 230
PATH: 280/464 770/1 317/3 229/426