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 6074260e
REPLY: 2:221/1.58@fidonet ef514dc6
Hi August,

On 2021-04-11 20:56:00, you wrote to Maurice Kinal:

 AA> I thought the concern was that some dupe-check implementations
 AA> only use the "serialno" part.

If they do that is a bug in the software.

 MK>> ..Adding more characters doesn't add meaning or additional
 MK>> functionality to it.

 AA> BUT.. you must agree that the likely hood of two rando numbers
 AA> colliding given that any of the 8 chars in the serialno part can
 AA> be [a-z][A-Z][0-9] at 62^8, is pretty unlikely.

 AA> Even a serial number based on an incremental 8 char string with
 AA> [a-z][A-Z][0-9] could work too.

My suggestion for anyone who thinks the current MSGID isn't good enough and
needs improving, is to not mess with the MSGID itself, because it is a FTSC
standard, and systems more or less depend on it to be according to that
standard.

Just create a new kludge, so you can do with it what you want, and you are
guaranteed not to cause any problems.
For instance:

@UUID: cd882502-9b77-11eb-a8b3-0242ac130003

It's 128 bit so the collision problem is virtually non existent, and you don't
have to bother with the address. And most modern OS's have standard optimized
routines to generate a good and secure number like this.

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 120/340 123/131 124/5016 129/305
SEEN-BY: 154/10 203/0 221/0 226/30 227/114 229/101 424 426 452 664
SEEN-BY: 229/700 1016 1017 240/5832 249/110 206 317 400 280/464 5003
SEEN-BY: 282/1038 288/100 292/8125 301/1 310/31 317/3 322/757 342/200
SEEN-BY: 396/45 423/120 460/58 633/280 770/1
PATH: 280/464 229/101 426