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