For the life of me - I cannot find the FSTC document which states that
MSGID is a required field. Isn't it?

Thanks,
O.

--- ExchangeBBS NNTP Server v3.1/Linux64
* Origin: (1:1/123)

On 2019 Apr 29 10:48:10, you wrote to All:

For the life of me - I cannot find the FSTC document which states that MSGID is a required field. Isn't it?

MSGID/REPLY are not required /unless/ your software supports FTS-0009... if your software supports FTS-0009, it is expected to adhere to the protocols defined within it...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'm lost. I left a trail of crumbs, but somebody ate'em.
---
* Origin: (1:3634/12.73)

Haha... I hit (Q)uote, it barfed up the MSGID instead of the message
doh! Anyway, this post also serves as a test - did anyone see it? How
about the msgid and reply, they look ok????

Yep, the message I am replying to looks good kludge wise, and I do so it.. :)

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Haha... I hit (Q)uote, it barfed up the MSGID instead of the message
doh! Anyway, this post also serves as a test - did anyone see it? How
about the msgid and reply, they look ok????

Ozz
--- ExchangeBBS FTN Tosser/JAM v1.19.04 (Beta 4.09)
* Origin: (1:1/123)

MSGID/REPLY are not required /unless/ your software supports FTS-0009... if >your software supports FTS-0009, it is expected to adhere to the protocols >defined within it...

The reason I ask, was a message came in on another FTN type network,
and my tosser processed but reported a message with no MSGID. Of
course, nothing says it has to be there, but, there are a few FTSC
documents which mention how to use it for dupe checking and reply
chaining. Which would break as soon as two different topics come in
with the same blank msgid, and thus blank reply.

Ozz
(Not policing, just trying to make sure I don't allow CRAP in/out!)
--- ExchangeBBS FTN Tosser/JAM v1.19.04 (Beta 4.09)
* Origin: (1:1/123)

Hi August,

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

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

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

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

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

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

H:\myutils>> rando2

lfz$bkmcmmg36ye@jll1xpieaats

Those aren't 32 bit.

So.. why couldn't something like that be implemented? And,
instead of limiting the "serialno" to hex chars, use the entire
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.

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

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

I thought it was copacetic with other systems. On which ones
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...

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

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

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

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

Most systems keep it simple:

z:f/n.p hhhhhhhh

And some others look like:

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)

Hello Wilfred!

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

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

I can see that to be the case as well. A serial-style also has
a built-in chronological feature.

H:\myutils>> rando2

lfz$bkmcmmg36ye@jll1xpieaats

Those aren't 32 bit.

Ah... so the "serialno" part *must" be 8-char? Then rando could
still work like so:

H:\myutils>rando
yZn=ZRG-
i)G)0ej=
YwSj-6B+
kwg5r(aR
Fp902h8A
lFyNVofN
R)5vlK+(
Sg7y-pPE
DDvCC2Sm
mX20Wj3d
()AO8oN\
\DTe29VA
4xqhDjbB
QXK\uqOs

:D

there's always a change of a collision within 3 years.

Yes.. I've suspected that could be problematic. But look at the
variation produced above. My math for calculating the minimum
number of possibilies (if excluding characters like "(, ), \, =,
-, etc.." and only allowing for the letters of the alphabet,
upper and lower case, is: 52^8 That's a lot more than just a
plain hex version: 16^8.

Echomail traffic would have to attain avalanche proportions
before collisions would be a concern. ;)

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

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

Ah.. that little word "for" makes a big difference. :

Then the synchronet version adds some added uniqueness.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

-={ 2021-04-11 19:31:13.137413143+00:00 }=-

Hey August!

Then the synchronet version adds some added uniqueness.

I disagree. The address itself is unique without adding any extra proprietary bytes that are totally meaningless to the network at large. Any alterations ought to be to the serial number portion.

Your suggestion is perfectly valid but to be honest I still believe that a 32-bit hex value for the unixtime or rfc-868 (seconds since 1900) is the best choice for uniqueness over the longest span which is much greater than the 3 year period required by the current standard. Also it adds meaning to it beyond what is capable for a randomly generated serial number. Unfortunetly it has a shelf life that is quickly running out whereas the random one doesn't.

Life is good,
Maurice

... Wa bið þam þe sceal of langoþe leofes abidan.
Woe it is for the one who must wait in longing for the beloved.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi August,

On 2021-04-11 13:53:00, you wrote to me:

H:\myutils>> rando2

lfz$bkmcmmg36ye@jll1xpieaats

Those aren't 32 bit.

Ah... so the "serialno" part *must" be 8-char? Then rando could
still work like so:

You should read the fts document on it! ;)

"...The serial number may be any eight character hexadecimal number"

H:\myutils>> rando

yZn=ZRG-

there's always a change of a collision within 3 years.

Yes.. I've suspected that could be problematic.

It's a very small chance, but it can still happen. I think I have seen a few cases where it happend in the last decades... ;)

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

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

Ah.. that little word "for" makes a big difference. :

Then the synchronet version adds some added uniqueness.

As Maurice said... ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred van Velzen!

Ah... so the "serialno" part *must" be 8-char? Then rando could
still work like so:

You should read the fts document on it! ;)

"...The serial number may be any eight character hexadecimal number"

^^^

I have! And the little word "may" is merely a suggestion. ;)

H:\myutils>> rando

yZn=ZRG-

An 8-char series where each char can be [a-z]|[A-Z] = 52^8
possible strings. Add the numbers [0-9] and the possibilities
climb to 62^8. Throw in some special char options, and the
number climbs even higher. That approach far surpasses the hex
choice at 16^8.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

Hello Maurice Kinal!

Your suggestion is perfectly valid but to be honest I still
believe that a 32-bit hex value for the unixtime or rfc-868
(seconds since 1900) is the best choice for uniqueness over
the longest span which is much greater than the 3 year
period required by the current standard.

But what if two or more systems process messages at exactly the
same time of the day? A collision seems far more likely than if
the respective systems produce random 32 bit strings.

Also it adds meaning to it beyond what is capable for a
randomly generated serial number. Unfortunetly it has a
shelf life that is quickly running out whereas the random
one doesn't.

Right. Therefore, I see two +1's for the random [a-z]|[A-Z]|[0-
9] version, and atleast one -1 for the time-serial version.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

-={ 2021-04-11 23:04:06.451242390+00:00 }=-

Hey August!

But what if two or more systems process messages at exactly the
same time of the day?

It won't matter since two or more systems will have two or more unique addresses. Also points off the same system creating the same id would still be unique given the differing point numbers in the address. Using my node address in comparison for a point system off my node potentially could create MSGIDs as follows;

MSGID: 1:153/7001.0 01234567
MSGID: 1:153/7001.1 01234567

That odds of that happening given the number of fidonet users here are pretty much nil here but why tempt the fates? As for random collisions there isn't any guarentee that either of the above two systems won't create a collision within three years no matter how remote that possibility is whereas the serial number created by the number of seconds since 1970|1900 should NEVER create a collision within it's lifetime, 2106 in my particular case since I am using the 1970 benchmark with an unsigned 32-bit integer. Also this serial number has real meaning that can be extracted by those in the know whereas a random serial number offers nothing in that direction other than uniqueness. Using your scoring system then the serial time generated one scores higher when compared to the random serial number no matter if it is a hex representation or not. Adding more characters doesn't add meaning or additional functionality to it.

Life is good,
Maurice

... Gif ðu hwæt on druncen misdo, ne wit ðu hit ðam ealoþe.
If you do something wrong when drunk, don't blame it on the ale.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

It won't matter since two or more systems will have two or more unique addresses..

MSGID: 1:153/7001.0 01234567
MSGID: 1:153/7001.1 01234567

OH! Ok, if dupe-checking takes into consideration the "address"
part along with the "serialno" part, then uniqueness is pretty
good as it stands.

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

..As for random collisions there isn't any guarentee that
either of the above two systems won't create a collision
within three years no matter how remote that possibility
is..

True. There could very well be a collision created on the same
system given enough time.

whereas the serial number created by the number of seconds
since 1970|1900 should NEVER create a collision within it's
lifetime, 2106 in my particular case..

Good point. That guarantees uniqueness. You win.

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

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

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

I'm amazed how long the services of TinyURL have relied on 8-
char uniqueness. As far as I can tell they only use the
lowercase letters + the numbers:

https://tinyurl.com/ydpdc3td
https://tinyurl.com/ydt9y4os

..the service as been operating for a l-o-n-g time.


And, now that we've totally bored the vast number of ASIAN_LINK
listeners, we should probably move to something less technical.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

-={ 2021-04-12 01:41:38.694142067+00:00 }=-

Hey August!

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

You could be right about that but I was under the impression that the entire MSGID is used. I say we give it a try using the [:alnum:] regex which I've taken the liberty of doing in this reply. In my case I am using /dev/urandom to generate the random characters in conjunction with tr and the [:alnum:] regex to strip out 8 suitable characters as shown in the MSGID of this reply to you. It certainly doesn't add that much drag but I am going to reserve judgement on that once I try it out on the slowest cpu I have running at the moment. It is busy upgrading itself to the newest gcc-10.3.0 release so it might be awhile before I can give it a proper test. Offhand I think your idea might be best all things considered. I still think my idea is the ultimate but I have serious doubts about getting it adopted any time soon. Definetly something we have time to ponder ... or at least I do. :-)

And, now that we've totally bored the vast number of ASIAN_LINK
listeners, we should probably move to something less technical.

Bah! I say if they are bothered by it then they should speak up instead of just lurking. Besides I think we need to test your idea to see what constitutes
valid characters in the serial number. Once we get a better handle on what works and what doesn't as far as acceptable characters are concerned we can safely
drop this subject. Offhand I think this might be a keeper. Also I want to try it on the EuroPoint once I get confirmation about it's validity. Only one way
to find out.

Sound like a plan?

Life is good,
Maurice

... Sprec ofter embe oðres monnes weldæde þonne emb ðine agna.
Speak more often about other people's good deeds than about your own.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi August,

On 2021-04-11 16:50:00, you wrote to me:

H:\myutils>> rando

yZn=ZRG-

An 8-char series where each char can be [a-z]|[A-Z] = 52^8
possible strings. Add the numbers [0-9] and the possibilities
climb to 62^8. Throw in some special char options, and the
number climbs even higher. That approach far surpasses the hex
choice at 16^8.

Yes, but it's not according to the standard.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi August,

On 2021-04-11 17:06:00, you wrote to Maurice Kinal:

Also it adds meaning to it beyond what is capable for a
randomly generated serial number. Unfortunetly it has a
shelf life that is quickly running out whereas the random
one doesn't.

Right. Therefore, I see two +1's for the random [a-z]|[A-Z]|[0-
9] version, and atleast one -1 for the time-serial version.

You forget the -INFINITE for the random [a-z]|[A-Z]|[0-9] version, because it's not according to the standard.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi August,

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

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

If they do that is a bug in the software.

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

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

Even a serial number based on an incremental 8 char string with [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)