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)
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)
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)
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"
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.
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?
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."
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".
I'll leave it to the original poster to fully understand the implications before choosing their course. I was just providing my own insight.
About half a century ago, I spent many hours on trying to modernize FTS-1
> 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.
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.
I don't know about problems, but I do know FMail handles them
differently then the standard compliant ones.
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">
<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.
I was thinking about not longer than 40 chars or so, so that thewhy would this artificial(?) limit be in place to start with?
kludge line doesn't exceed 78.
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?
But I'm more interested in my previous question.
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?
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?
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...
But I'm more interested in my previous question.
Yes, if you show up here we'll have a beer ...
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.
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.
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.
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.
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.
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?
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?
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.
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 ...
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.
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.
Is there any software that has issues with messages having a MSGID
like
string@z:r/n.p serialno
?
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.
I still don't understand the reasoning and advantages of "string@z:r/n.p".
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
According to FTS-9 and FTS-4000 this would be valid too:
^aMSGID: 🤔🙏🤫🧠😷🤖🥳 🖕
So did anyone experience any problems with non-unique / repeating MSGIDs in
real life? Is it a real problem or just theoretical?
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.
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: 🤔🙏🤫🧠😷🤖🥳 🖕
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'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...
So did anyone experience any problems with non-unique / repeating MSGIDs in real life? Is it a real problem or just theoretical?
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'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.
So did anyone experience any problems with non-unique / repeating MSGIDs in real life? Is it a real problem or just theoretical?
So did anyone experience any problems with non-unique / repeating MSGIDs[snip]
in real life? Is it a real problem or just theoretical?
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: 🤔🙏🤫🧠😷🤖🥳 🖕
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 512 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 153:47:58 |
| Calls: | 8,281 |
| Calls today: | 1 |
| Files: | 15,511 |
| D/L today: |
2 files (29K bytes) |
| Messages: | 926,721 |