Is there any software that has issues with messages having a MSGID like

string@z:r/n.p serialno

?

('string' not being too long and containing only letters, numbers, dots, underscores)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

Hi! Carlos,

On 03 Feb 2022, Carlos Navarro said the following...

Is there any software that has issues with messages having a MSGID like

string@z:r/n.p serialno
?
('string' not being too long and containing only letters, numbers, dots, underscores)

AFAIK the only software I've had that choked on it was my old favourite (Windows) SemPoint reader/editor. It became 'not a problem' after a few years.

Cheers,
Paul.

... For a good time call 86753099 (Jenny)...

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/32)
* Origin: Quinn's Rock vBox - sunny-side up on the desktop (3:640/1384)

Hi Carlos,

On 2022-02-03 07:25:14, you wrote to All:

Is there any software that has issues with messages having a MSGID
like

string@z:r/n.p serialno

?

('string' not being too long and containing only letters, numbers, dots, underscores)

I don't know about problems, but I do know FMail handles them differently then the standard compliant ones.

You never know what any software will do when there is unexpected input... (Unless you have the source ofcourse ;-)).

Bye, Wilfred.

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

Re: MSGID
By: Carlos Navarro to All on Thu Feb 03 2022 07:25 am

Is there any software that has issues with messages having a MSGID like

string@z:r/n.p serialno

If there is, that software should be fixed. The only requirement on the "origaddr" portion of the FTN MSGID value is that it "should be specified in a form that constitutes a valid return address for the originating network" - so really, it can be whatever you like (except for spaces, obviously) and receiving/parsing software should be able to handle it correctly.

I have a whole write-up on this topic here if you want to read it: http://wiki.synchro.net/faq:misc#ftn_msgid

('string' not being too long and containing only letters, numbers, dots, underscores)

<chuckles at "not being too long">
--
digital man (rob)

Synchronet "Real Fact" #119:
Synchronet v2.00a for DOS was released on June 6, 1994 (6 months after v1c02) Norco, CA WX: 60.7°F, 20.0% humidity, 4 mph W wind, 0.00 inches rain/24hrs

Rob wrote (2022-02-03):

Re: MSGID
By: Carlos Navarro to All on Thu Feb 03 2022 07:25 am

> Is there any software that has issues with messages having a MSGID
> like
>
> string@z:r/n.p serialno

If there is, that software should be fixed. The only requirement on the "origaddr" portion of the FTN MSGID value is that it "should be specified
in a form that constitutes a valid return address for the originating network"

Your interpretation of a valid return address for the originating network is interesting though:

@MSGID: 31383.ftsc_pub@1:103/705 2661db4a

* Origin: DAEMON_ARGS (2:280/464.47)

Re: MSGID
By: Oli to Rob Swindell on Thu Feb 03 2022 10:51 pm

Rob wrote (2022-02-03):

Re: MSGID
By: Carlos Navarro to All on Thu Feb 03 2022 07:25 am

> Is there any software that has issues with messages having a MSGID
> like
>
> string@z:r/n.p serialno

If there is, that software should be fixed. The only requirement on the "origaddr" portion of the FTN MSGID value is that it "should be specified in a form that constitutes a valid return address for the originating network"

Your interpretation of a valid return address for the originating network is interesting though:

@MSGID: 31383.ftsc_pub@1:103/705 2661db4a

If you send a netmail there, it'll reach me. But that clause is only a "should" anyway. It doesn't *have* to be a valid return address for the originating network.
--
digital man (rob)

Rush quote #13:
Cast in this unlikely role, ill-equipped to act, with insufficient tact
Norco, CA WX: 60.1°F, 20.0% humidity, 9 mph NNW wind, 0.00 inches rain/24hrs

If you send a netmail there, it'll reach me. But that clause is only a "should" anyway. It doesn't *have* to be a valid return address for the originating network.

Says who?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Re: MSGID
By: Björn Felten to Rob Swindell on Fri Feb 04 2022 03:25 am

If you send a netmail there, it'll reach me. But that clause is only a "should" anyway. It doesn't *have* to be a valid return address for the originating network.

Says who?

Says FTS-0009.001:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."
--
digital man (rob)

Synchronet "Real Fact" #74:
Vertrauen went online (as a WWIV BBS running on a 10MHz PC-XT clone) in 1988 Norco, CA WX: 58.8°F, 20.0% humidity, 4 mph S wind, 0.00 inches rain/24hrs

If you send a netmail there, it'll reach me. But that clause is only a
"should" anyway. It doesn't *have* to be a valid return address for the
originating network.

Says who?

Says FTS-0009.001:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."

I was more thinking about how you interpret "should" to "yeah, fuck that, it actually doesn't say I *have* to, so I ignore that totally, they probably just added the "should" for fun".




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Re: MSGID
By: Björn Felten to Rob Swindell on Fri Feb 04 2022 03:54 am

If you send a netmail there, it'll reach me. But that clause is only a
"should" anyway. It doesn't *have* to be a valid return address for the
originating network.

Says who?

Says FTS-0009.001:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."

I was more thinking about how you interpret "should" to "yeah, fuck that, it actually doesn't say I *have* to, so I ignore that totally, they probably just added the "should" for fun".

In the language of technical specifications there is a firm differentiation between "should" (or "may") and "shall" (or "must"). The use of the word "should" is deliberate and not "just added for fun".

http://ftsc.org/docs/fta-1006.002 defines "SHOULD" to "mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

I'll leave it to the original poster to fully understand the implications before choosing their course. I was just providing my own insight.
--
digital man (rob)

This Is Spinal Tap quote #25:
Viv Savage: Have... a good... time... all the time. That's my philosophy. Norco, CA WX: 57.4°F, 22.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs

I'll leave it to the original poster to fully understand the implications before choosing their course. I was just providing my own insight.

First of all, I humbly ask for forgiveness for taking out my frustration onto you. Basically I totally understand what you are saying, and I agree.

I have saved messages in various FTSC echoes (by then they were like FTSC-WGA, -WGB, -WGC and so on) from 1997 so I guess I must have been involved somehow by then. And for every year I was an elected member of the FTSC I got more and more frustrated by how the FTSC had to act.

How it has always worshipped the sacred "backwards compatibility". Even when it was obvious how our Russian colleagues managed to take Fidonet to new levels.

Obviously we had a dire need to modernize our beloved museum piece, but that never happened. About half a century ago, I spent many hours on trying to modernize FTS-1

http://eljaco.se/files/FTSC/FTS-0001.017%20--%20RFC.txt

and then went on with FTS-4

http://eljaco.se/files/FTSC/FTS-0004.002%20--%20RFC.txt

Well, no real comments, just "but we have to respect all the old, outdated vapourware still in use". So my attempt fell flatly on the ground.

Needless to say, that's when I realized that the FTSC is no longer of any use for furthering our beloved network, so I resigned.

Should we ever want to revive Fidonet, we *have* to let go of all the DOS-based shit we cherish, and take aim at the future.

FTSC should no longer just document decades old crap, it should *set* the standards. I'm confident, that there's still many of us, that will stay behind even when the products by Happy Amateurs From The 1980s will have to yield.

To paraphrase what you so properly worded, Rob, I'm hereby just providing my own insight...

..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

About half a century ago, I spent many hours on trying to modernize FTS-1

Yeah, well, neither I nor Fidonet is old enough for that. Half a decade ago...



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

Rob wrote (2022-02-03):

> Your interpretation of a valid return address for the originating
> network is interesting though:
>
> @MSGID: 31383.ftsc_pub@1:103/705 2661db4a

If you send a netmail there, it'll reach me.

Since when is name@1:2/3 a valid address scheme in Fido? Can you point to the relevant FTS/FSC?

---
* Origin: DAEMON_ARGS (2:280/464.47)

03 Feb 2022 16:37, you wrote to me:

AFAIK the only software I've had that choked on it was my old
favourite (Windows) SemPoint reader/editor. It became 'not a problem' after a few years.

Was that fixed?
Anyone still using it?

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

03 Feb 2022 08:47, you wrote to me:

I don't know about problems, but I do know FMail handles them
differently then the standard compliant ones.

Does it also handle MSGIDs with z:r/n.p@string differently?

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

03 Feb 2022 11:19, you wrote to me:

If there is, that software should be fixed. The only requirement on
the "origaddr" portion of the FTN MSGID value is that it "should be specified in a form that constitutes a valid return address for the originating network" - so really, it can be whatever you like (except
for spaces, obviously) and receiving/parsing software should be able
to handle it correctly.

I have a whole write-up on this topic here if you want to read it: http://wiki.synchro.net/faq:misc#ftn_msgid

Thank you. I had already read your article months ago.

('string' not being too long and containing only letters, numbers,
dots, underscores)

<chuckles at "not being too long">

I was thinking about not longer than 40 chars or so, so that the kludge line doesn't exceed 78.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

On 2022 Feb 04 07:28:58, you wrote to Rob Swindell:

<chuckles at "not being too long">

I was thinking about not longer than 40 chars or so, so that the
kludge line doesn't exceed 78.

why would this artificial(?) limit be in place to start with?

for example, Message-ID control lines in gated news and email messages can be very long... if one uses some portion of that Message-ID to generate the FTN MSGID's first field, well...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Mail your ideas, written on the back of a $20 bill, to..
---
* Origin: (1:3634/12.73)

Hello, mark lewis.
On 4/2/22 9:06 a. m. you wrote:

I was thinking about not longer than 40 chars or so, so that the
kludge line doesn't exceed 78.

why would this artificial(?) limit be in place to start with?

It was just a question. Another one would be:

Is there any software that has issues with MSGID or any other kludge that is longer than 80 chars?

But I'm more interested in my previous question.

Carlos
--- Hotdoged/2.13.5/Android
* Origin: Costa Blanca, Spain (2:341/234.12)

Hi Carlos,

On 2022-02-04 07:25:23, you wrote to me:

I don't know about problems, but I do know FMail handles them
differently then the standard compliant ones.

Does it also handle MSGIDs with z:r/n.p@string differently?

No, that's a valid FTN address...

Bye, Wilfred.

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

But I'm more interested in my previous question.

Yes, if you show up here we'll have a beer ...

--- DB4 - Jan 26 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hi! Carlos,

On 04 Feb 2022, Carlos Navarro said the following...

AFAIK the only software I've had that choked on it was my old favourite (Windows) SemPoint reader/editor. It became 'not a problem after a few years.

Was that fixed?

TTBOMK, no.

Anyone still using it?

I'm not aware of anyone currently using it (last user was about two years ago, IIRC. (It was a 16 bit app, BTW.) There are other toys to use now.

Cheers,
Paul.

... Lymph (v.), to walk with a lisp.

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/32)
* Origin: Quinn's Rock vBox - sunny-side up on the desktop (3:640/1384)

Re: MSGID
By: Oli to Rob Swindell on Fri Feb 04 2022 12:49 pm

Rob wrote (2022-02-03):

> Your interpretation of a valid return address for the originating
> network is interesting though:
>
> @MSGID: 31383.ftsc_pub@1:103/705 2661db4a

If you send a netmail there, it'll reach me.

Since when is name@1:2/3 a valid address scheme in Fido? Can you point to the relevant FTS/FSC?

Here's one:
http://ftsc.org/docs/fsc-0058.002

But mainly, I can point you to "prior art" in the form of *thousands* of MSGIDs that contain originaddr fields using that scheme from FidoNet messages going back 20+ years.

But that's kind of irrelevant as the field does not *have* to be a valid return address for the originating networking; it can be whatever that developer decides will make the message-ID the most useful. In my opinion, uniqueness is the most important and useful attribute of a message-ID, so anything that improves its uniqueness is a virtue.
--
digital man (rob)

Synchronet/BBS Terminology Definition #49:
KD = King Drafus (Allen Christiansen)
Norco, CA WX: 59.5°F, 19.0% humidity, 8 mph NW wind, 0.00 inches rain/24hrs

04 Feb 2022 17:21, you wrote to me:

Hi Carlos,

On 2022-02-04 07:25:23, you wrote to me:

I don't know about problems, but I do know FMail handles them
differently then the standard compliant ones.

Does it have any issues (for dupe detection or whatever) with that kind of 'origaddr'?

Does it also handle MSGIDs with z:r/n.p@string differently?

No, that's a valid FTN address...

Is it really? I mean, is there any document that define 5D as a valid address format? I've seen several ones (about ticks, binkp, srif...) that mention it, but...

BTW I think that using 5D in MSGIDs might be redundant, unless it's done in an echo that is shared by several FTN networks.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

04 Feb 2022 18:34, you wrote to me:

But I'm more interested in my previous question.

Yes, if you show up here we'll have a beer ...

If I ever go over there I'd be happy to.
I tell you the same thing.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

05 Feb 2022 07:25, you wrote to me:

Anyone still using it?

I'm not aware of anyone currently using it (last user was about two
years ago, IIRC. (It was a 16 bit app, BTW.)

Ok, thank you for your replies.

There are other toys to use now.

Yes :-)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

04 Feb 2022 18:33, you wrote to Oli:

But that's kind of irrelevant as the field does not *have* to be a
valid return address for the originating networking; it can be
whatever that developer decides will make the message-ID the most
useful. In my opinion, uniqueness is the most important and useful attribute of a message-ID, so anything that improves its uniqueness is
a virtue.

+1

If SBBS-style MSGIDs are harmless as it seems and other developers decide to use them too, it could become a standard.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

Hi Carlos,

On 2022-02-05 09:52:23, you wrote to me:

I don't know about problems, but I do know FMail handles them
differently then the standard compliant ones.

Does it have any issues (for dupe detection or whatever) with that kind of 'origaddr'?

Not that I'm aware of. It just treats it like a string of characters for the dupe checksum calculation

Does it also handle MSGIDs with z:r/n.p@string differently?

No, that's a valid FTN address...

Is it really? I mean, is there any document that define 5D as a valid address format? I've seen several ones (about ticks, binkp, srif...) that mention it, but...

I don't know. But FMail treats it as valid.

BTW I think that using 5D in MSGIDs might be redundant, unless it's
done in an echo that is shared by several FTN networks.

I'm not aware of such echo's, or if it's even technically possible to have them.

Bye, Wilfred.

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

Rob wrote (2022-02-04):

Re: MSGID
By: Oli to Rob Swindell on Fri Feb 04 2022 12:49 pm

Rob wrote (2022-02-03):

Your interpretation of a valid return address for the
originating network is interesting though:

@MSGID: 31383.ftsc_pub@1:103/705 2661db4a

If you send a netmail there, it'll reach me.

Since when is name@1:2/3 a valid address scheme in Fido? Can you
point to the relevant FTS/FSC?

Here's one:
http://ftsc.org/docs/fsc-0058.002

great, you found the only one and it's an irrelevant FSC that never got any real world use.

But mainly, I can point you to "prior art" in the form of *thousands* of MSGIDs that contain originaddr fields using that scheme from FidoNet messages going back 20+ years.

Is it synchronet's prior art? Whenever I see a header like this, it's from synchronet.

And why should "prior art" (aka buggy software) override a technical standard?

But that's kind of irrelevant as the field does not *have* to be a valid return address for the originating networking; it can be whatever that developer decides will make the message-ID the most useful. In my
opinion, uniqueness is the most important and useful attribute of a message-ID, so anything that improves its uniqueness is a virtue.

Okay, so your MSGID doesn't follow the FTS recommendation, but now it's irrelevant anyway and ignoring the FTS is a virtue?

So your definition of SHOULD is SHOULD NOT.

---
* Origin: Birds aren't real (2:280/464.47)

Carlos wrote (2022-02-05):

04 Feb 2022 18:33, you wrote to Oli:

But that's kind of irrelevant as the field does not *have* to be a
valid return address for the originating networking; it can be
whatever that developer decides will make the message-ID the most
useful. In my opinion, uniqueness is the most important and useful
attribute of a message-ID, so anything that improves its uniqueness
is a virtue.

+1

If SBBS-style MSGIDs are harmless as it seems and other developers decide to use them too, it could become a standard.

Why should it?

---
* Origin: Birds aren't real (2:280/464.47)

On 2022 Feb 05 11:59:38, you wrote to Carlos Navarro:

If SBBS-style MSGIDs are harmless as it seems and other developers
decide to use them too, it could become a standard.

Why should it?

if it is widely used, why should it not be documented as a standard?

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Yeah yeah, I know... the check is in the mail!
---
* Origin: (1:3634/12.73)

mark lewis wrote to Oli <=-

If SBBS-style MSGIDs are harmless as it seems and other developers
decide to use them too, it could become a standard.

Why should it?

if it is widely used, why should it not be documented as a
standard?

It's best to just ignore "Oli". He's an ignorant asshole who is only
out to stir up an argument, about anything he can get anyone to discuss
with him.



... All hope abandon, ye who enter messages here.
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

mark,

Why should it?

if it is widely used, why should it not be documented as a standard?

It only is a standard when something is used cross-platform, mot because a single product behaves in a specific way.

\%/@rd

--- DB4 - Jan 26 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Dan,

It's best to just ignore "Oli". He's an ignorant asshole who is only
out to stir up an argument, about anything he can get anyone to discuss with him.

Although Oli can be a pain in the ass, he's not an ignorant asshole. He has gotten on my back as well snd I don't mind as long as it's not personal ...

\%/@rd

--- DB4 - Jan 26 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Ward Dossche wrote to Dan Clough <=-

It's best to just ignore "Oli". He's an ignorant asshole who is only
out to stir up an argument, about anything he can get anyone to discuss with him.

Although Oli can be a pain in the ass, he's not an ignorant
asshole. He has gotten on my back as well snd I don't mind as
long as it's not personal ...

Yeah, OK. He's gotten on my back, and it WAS personal. I'll take my
own advice.


... So easy, a child could do it. Child sold separately.
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

Although Oli can be a pain in the ass, he's not an ignorant
asshole. He has gotten on my back as well snd I don't mind as
long as it's not personal ...

Yeah, OK. He's gotten on my back, and it WAS personal. I'll take my
own advice.

Oh dear ... Do not confuse straight talk with getting on someone's back ... I have my fanclub as well but I have a rule to drop as good as every discussion after 2 cycles; anything longer becomes boring, useless, waste of time....

Enjoy the week-end ...

\%/@rd

--- DB4 - Jan 26 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

On 2022 Feb 05 16:24:46, you wrote to me:

Why should it?

if it is widely used, why should it not be documented as a standard?

It only is a standard when something is used cross-platform, mot
because a single product behaves in a specific way.

not necessarially but you keep doing you :)

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Paradox: We buy more, but enjoy less.
---
* Origin: (1:3634/12.73)

03 Feb 2022 07:25, I asked:

Is there any software that has issues with messages having a MSGID
like
string@z:r/n.p serialno
?

So far I have only been told about:

- SemPoint
- NetMgr (*netmail only)

1. Looks like no one uses SemPoint nowadays.

2. NetMgr only has trouble with netmails. As I've been pointed out, this was reported and discussed in the TUB echo (Dec 2020). I've seen that SBBSecho was changed and currently uses 3D/4D (no "string@" prefix) in MSGIDs for netmails.

So it seems that using this type of origaddr's in echomail does not break anything.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Costa Blanca, Spain (2:341/234)

Carlos wrote (2022-02-12):

03 Feb 2022 07:25, I asked:

Is there any software that has issues with messages having a MSGID
like
string@z:r/n.p serialno
?

[...]

So it seems that using this type of origaddr's in echomail does not break anything.

Even if it did break any software, let it break. There was never a promise, that the origaddr always will be in the form 1:2/3(.0).

I still don't understand the reasoning and advantages of "string@z:r/n.p". Why would one want to use an invalid FTN address in the MSGID, if the message is originating in an FTN?

* Origin: Birds aren't real (2:280/464.47)

I still don't understand the reasoning and advantages of "string@z:r/n.p".

See Rob's explanation here:
http://wiki.synchro.net/faq:misc#ftn_msgid

Carlos
--- Hotdoged/2.13.5/Android
* Origin: Costa Blanca, Spain (2:341/234.12)

Carlos wrote (2022-02-13):

I still don't understand the reasoning and advantages of
"string@z:r/n.p".

See Rob's explanation here:
http://wiki.synchro.net/faq:misc#ftn_msgid

So did anyone experience any problems with non-unique / repeating MSGIDs in real life? Is it a real problem or just theoretical?

It shouldn't been to hard to create an unique serialno within the domain of an origaddr.

Do we have an estimate of the probability of the same MSGID for different messages? Does anyone can point to non-unique MSGIDs in their message base?

An regarding MSGID format:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."

Of course one could insist there is only a "should" and not a "must" in FTS-9, but string@z:n/f.p is still not a valid return address.

But then I could also be very clever and recognize that

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

uses "may". So there is no hard requirement that there is a serialno at all.

FTS-9 also doesn't require that there are no spaces (0x32) in the origaddr (which doesn't have to be a valid address). Which means anything goes, as long as MSGID is unique and "A double-quote character within a quoted address is represented by by two consecutive double-quote characters."

According to FTS-9 and FTS-4000 this would be valid too:

^aMSGID: 🤔🙏🤫🧠😷🤖🥳 🖕


If your software breaks: "You should fix or replace your software"

---
* Origin: Birds aren't real (2:280/464.47)

Hello Oli!

*** Monday 14.02.22 at 9:06:33, Oli wrote to Carlos Navarro:

[snip]

According to FTS-9 and FTS-4000 this would be valid too:

^aMSGID: 🤔🙏🤫🧠😷🤖🥳 🖕

LOL!

Regards,
Martin

--- WinPoint 398.2
* Origin: WinPoint Test Rig - UK - (2:280/464.27)

On 2022 Feb 14 10:06:32, you wrote to Carlos Navarro:

So did anyone experience any problems with non-unique / repeating MSGIDs in
real life? Is it a real problem or just theoretical?

several operators who, for some unknown reason(s) seemed to reinstall their BBS software quite often, ran headlong into non-unique repeating MSGIDs when their systems would export newly written messages from their newly reinstalled setups... those messages were sidelined as dupes solely because of the duplicate MSGIDs even though the headers and message bodies were quite different... if they reinstalled three times in one week, i would see at least three sidelined messages from each posting test and all three of those messages would have the same serial number with quite different message bodies and header data...

i know about this because i let them know about the problem in case they were wondering why their posts were not getting any responses... i suspect they were simply not restoring some software config file that contained the last serial number used... they probably didn't even know about it if the data file even existed... in at least one case, the operator moved through two or three other BBS packages before finally settling on the one they are running now... this whole thing took place over 20 years or so...

we won't even comment about the packages that used CRC16 and/or CRC32 hashes for their serial number generators with no database of previously used numbers or any way of detecting they had already used a certain number...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... After two days in hospital, I took a turn for the nurse.
---
* Origin: (1:3634/12.73)

Hi Oli,

On 2022-02-14 10:06:33, you wrote to Carlos Navarro:

I still don't understand the reasoning and advantages of
"string@z:r/n.p".

See Rob's explanation here:
http://wiki.synchro.net/faq:misc#ftn_msgid

So did anyone experience any problems with non-unique / repeating MSGIDs in
real life? Is it a real problem or just theoretical?

I've noticed a few cases when for instance Ward re-installed d'Brigde, and his MSGID's started repeating those his system already generated 1 or 2 years earlier. This was a few years back, so I don't remember the exact details. And I don't know if d'Bridge still has this problem, or has improved the MSGID checksum generating algorithm, and made it time based...

Finding these was by pure luck, because I got replies to originals I didn't see before. So maybe it happens a lot, but these false dupes go undetected.

It shouldn't been to hard to create an unique serialno within the
domain of an origaddr.

It isn't, everyone could have a look at the golded code for instance...

An regarding MSGID format:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."

Of course one could insist there is only a "should" and not a "must" in FTS-9, but string@z:n/f.p is still not a valid return address.

But then I could also be very clever and recognize that

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

uses "may". So there is no hard requirement that there is a serialno at all.

FTS-9 also doesn't require that there are no spaces (0x32) in the origaddr (which doesn't have to be a valid address). Which means anything goes, as long as MSGID is unique and "A double-quote character within a quoted address is represented by by two consecutive double-quote characters."

According to FTS-9 and FTS-4000 this would be valid too:

^aMSGID: 🤔🙏🤫🧠😷🤖🥳 🖕

Well of course someone could do this and point at the semantics of the FTS documentation for legitimizing this. But there is such a thing as common sense, and to use the docs as intended, and not be annoying and cause problems in other software...


Bye, Wilfred.

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

//Hello Oli,//

on *13.02.22* at *12:23:17* You wrote in Area *FTSC_PUBLIC*
to *Carlos Navarro* about *"MSGID"*.

I still don't understand the reasoning and advantages of "string@z:r/n.p". Why would one want to use an invalid FTN address in the MSGID, if the message is originating in an FTN?

I am also a bit suprised by this discussion because it appears that somebody has the idea of using the address part of the MSGID for an unintended purpose. From my perspective, the *address part is essantially a unique ID that represents the system generating the MSGID number*. This enables the *two together to form a unique identifier for the message* itself w.r.t the system that has created the original FTN message.

I honestly think, *the "valid return address" is only a way of enforcing a sender UID*. Similar practice can be found all across the field (say Java package names). In particular this means, that there should actually be no furhter semantics attached to that address. In particular, no one should actually try to contact the system based on that string.

The hole MSGID/REPLY mechanism however has a generall problem with messages generated outside a FTN network, where the number is generated outside the originating sytem (i.e., a gateway). While such a gateway may indeed rely on the originating network adressing scheme for the adrress part, the number is generated by the gateway without any general mechanism for keeping it unique for that particular sender. While one gateway still could hold a history for each such sender, there may be multiple uncoordinated gateways of the same type producing duplicated numbers for the same origin address. However, in practice I see this only impacting reply linkage in the reade. Dupe checking usually involved information beyond the MSGID and should not fall for it.

Regards,
Tim
--- WinPoint 399.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

On 14 Feb 22 18:22:20, Wilfred Van Velzen said the following to Oli:

I've noticed a few cases when for instance Ward re-installed d'Brigde, and MSGID's started repeating those his system already generated 1 or 2 years earlier. This was a few years back, so I don't remember the exact details. I don't know if d'Bridge still has this problem, or has improved the MSGID checksum generating algorithm, and made it time based...

Originally when I added that kludge to D'Bridge it was serial-based because FTS-9 stated the 8-hex number can be of any unique value. It was changed to timestamp when a few Sysops requested it.

Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

On 2022-02-14 10:06:32, Oli (2:280/464.47) wrote to Carlos Navarro:

So did anyone experience any problems with non-unique / repeating MSGIDs in real life? Is it a real problem or just theoretical?

Long ago on some busy multiuser BBSes it was certainly possible for two users to generate the same MSGID serialno if the algorithm used was based on C's time_t (seconds since 1970-01-01 for most implementations) and they users posted a message at the same time. Potentially this could also happen with QWK mail uploads.

How often this happened in real life, I'm not sure. Back then I don't recall it being common for mail processors to do dupe detection based on MSGID alone. If they did I suspect it was mitigated somewhat by dupe detection usually being done on a per-area basis, which I think is still the case today.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

On 2022-02-14 19:11:04, Tim Schattkowsky (2:240/1120.29) wrote to Oli:

I am also a bit suprised by this discussion because it appears that somebody has the idea of using the address part of the MSGID for an unintended purpose. From my perspective, the *address part is
essantially a unique ID that represents the system generating the MSGID number*. This enables the *two together to form a unique identifier for the message* itself w.r.t the system that has created the original FTN message.

I don't recall the details but in the mid-1990s there were discussions on NET_DEV from devs wanting to parse the MSGID to obtain the address of a message instead of parsing the Origin line. The likely thinking at the time being that parsing the MSGID just after the header meant the software didn't have to waste CPU cycles looping over each line of the message until they got to the Origin line.

But there was never any guarantee in FTS-9 that the MSGID origaddr matched the Origin line's origaddr.

Of course this was back when hard drives were slow and CPU speeds were still measured in megahertz. I remember someone once wrote a FTN packet sorter that sorted by echoarea to supposedly optimise tossing speed. Wild.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

Hi Nick,

On 2022-02-14 13:15:05, you wrote to me:

I've noticed a few cases when for instance Ward re-installed
d'Brigde, and MSGID's started repeating those his system already
generated 1 or 2 years earlier. This was a few years back, so I don't
remember the exact details. I don't know if d'Bridge still has this
problem, or has improved the MSGID checksum generating algorithm, and
made it time based...

Originally when I added that kludge to D'Bridge it was serial-based because
FTS-9 stated the 8-hex number can be of any unique value. It was changed to
timestamp when a few Sysops requested it.

Ok, good to know!

Bye, Wilfred.

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

Re: MSGID
By: Oli to Carlos Navarro on Mon Feb 14 2022 10:06 am

So did anyone experience any problems with non-unique / repeating MSGIDs in real life? Is it a real problem or just theoretical?

Yes, I have found hundreds of duplicate message-IDs in my FidoNet message bases from messages that were not actually duplicates.
--
digital man (rob)

Synchronet/BBS Terminology Definition #30:
FF = Form Feed (ASCII 12, Ctrl-L)
Norco, CA WX: 73.3°F, 27.0% humidity, 1 mph E wind, 0.00 inches rain/24hrs

So did anyone experience any problems with non-unique / repeating MSGIDs
in real life? Is it a real problem or just theoretical?

[snip]

Rob, mark, andre ... have already commented about this.

An regarding MSGID format:

"The originating address should be specified in a form that
constitutes a valid return address for the originating network."

Of course one could insist there is only a "should" and not a "must" in FTS-9, but string@z:n/f.p is still not a valid return address.

Doesn't matter, because FTN software doesn't (or shouldn't) get it from the MSGID to use it as a return address. (except NetMgr for netmail only, it seems)

I suppose it can be considered as a way to specify a username or account in a Fido system, like in internet email. I've sometimes seen expressions like: "Send a netmail to PING@1:2/3"

Anyway, using string@z:n/f.p in the MSGID (at least in echomail) doesn't seem to break anything and we can still see the originating system's address there.

But then I could also be very clever and recognize that

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

uses "may". So there is no hard requirement that there is a serialno at all.

Yes there is. That sentence continues: "as long as it is unique ..."

But what matters is if using a different scheme for the serialno (longer, non-hex... or none) would create problems.

FTS-9 also doesn't require that there are no spaces (0x32) in the origaddr (which doesn't have to be a valid address). Which means anything goes, as long as MSGID is unique and "A double-quote character within a quoted address is represented by by two consecutive double-quote characters."

Yes, except that space is 0x20 ;-)

Perhaps all that stuff about quotes should be removed from the document (including the "orginating" typo) some day. AFAIK it's not current practice.

According to FTS-9 and FTS-4000 this would be valid too:

^aMSGID: 🤔🙏🤫🧠😷🤖🥳 🖕

Invalid MSGID - missing 8-byte hex serialno. 😛

Carlos

--- WinPoint 398.2
* Origin: Costa Blanca, Spain (2:341/234.5)