• MSGID

    From Carlos Navarro@2:341/234 to All on Thursday, February 03, 2022 07:25:14
    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)
  • From Paul Quinn@3:640/1384 to Carlos Navarro on Thursday, February 03, 2022 16:37:48
    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)
  • From Wilfred van Velzen@2:280/464 to Carlos Navarro on Thursday, February 03, 2022 08:47:38
    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)
  • From Rob Swindell to Carlos Navarro on Thursday, February 03, 2022 11:19:15
    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
  • From Oli@2:280/464.47 to Rob Swindell on Thursday, February 03, 2022 22:51:08
    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)
  • From Rob Swindell to Oli on Thursday, February 03, 2022 18:03:05
    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
  • From Björn Felten@2:203/2 to Rob Swindell on Friday, February 04, 2022 03:25:19
    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)
  • From Rob Swindell to Björn Felten on Thursday, February 03, 2022 18:35:03
    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
  • From Björn Felten@2:203/2 to Rob Swindell on Friday, February 04, 2022 03:54:18
    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)
  • From Rob Swindell to Björn Felten on Thursday, February 03, 2022 19:36:25
    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
  • From Björn Felten@2:203/2 to Rob Swindell on Friday, February 04, 2022 05:57:24
    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)
  • From Björn Felten@2:203/2 to Björn Felten on Friday, February 04, 2022 06:21:54
    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)
  • From Oli@2:280/464.47 to Rob Swindell on Friday, February 04, 2022 12:49:28
    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)
  • From Carlos Navarro@2:341/234 to Paul Quinn on Friday, February 04, 2022 07:22:39
    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)
  • From Carlos Navarro@2:341/234 to Wilfred van Velzen on Friday, February 04, 2022 07:25:23
    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)
  • From Carlos Navarro@2:341/234 to Rob Swindell on Friday, February 04, 2022 07:28:59
    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)
  • From mark lewis@1:3634/12.73 to Carlos Navarro on Friday, February 04, 2022 09:06:38

    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)
  • From Carlos Navarro@2:341/234.12 to mark lewis on Friday, February 04, 2022 16:57:47
    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)
  • From Wilfred van Velzen@2:280/464 to Carlos Navarro on Friday, February 04, 2022 17:21:44
    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)
  • From Ward Dossche@2:292/854 to Carlos Navarro on Friday, February 04, 2022 18:34:43
    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)
  • From Paul Quinn@3:640/1384 to Carlos Navarro on Saturday, February 05, 2022 07:25:01
    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)
  • From Rob Swindell to Oli on Friday, February 04, 2022 18:33:35
    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
  • From Carlos Navarro@2:341/234 to Wilfred van Velzen on Saturday, February 05, 2022 09:52:23
    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)
  • From Carlos Navarro@2:341/234 to Ward Dossche on Saturday, February 05, 2022 10:33:27
    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)
  • From Carlos Navarro@2:341/234 to Paul Quinn on Saturday, February 05, 2022 10:35:29
    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)
  • From Carlos Navarro@2:341/234 to Rob Swindell on Saturday, February 05, 2022 11:03:18
    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)
  • From Wilfred van Velzen@2:280/464 to Carlos Navarro on Saturday, February 05, 2022 11:33:29
    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)
  • From Oli@2:280/464.47 to Rob Swindell on Saturday, February 05, 2022 11:57:38
    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)
  • From Oli@2:280/464.47 to Carlos Navarro on Saturday, February 05, 2022 11:59:39
    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)
  • From mark lewis@1:3634/12.73 to Oli on Saturday, February 05, 2022 09:49:22

    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)
  • From Dan Clough@1:123/115 to mark lewis on Saturday, February 05, 2022 12:45:00
    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)
  • From Ward Dossche@2:292/854 to mark lewis on Saturday, February 05, 2022 16:24:46
    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)
  • From Ward Dossche@2:292/854 to Dan Clough on Saturday, February 05, 2022 20:15:47
    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)
  • From Dan Clough@1:123/115 to Ward Dossche on Saturday, February 05, 2022 15:54:00
    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)
  • From Ward Dossche@2:292/854 to Dan Clough on Sunday, February 06, 2022 09:45:16
    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)
  • From mark lewis@1:3634/12.73 to Ward Dossche on Sunday, February 06, 2022 06:22:14

    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)
  • From Carlos Navarro@2:341/234 to All on Saturday, February 12, 2022 21:42:11
    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)
  • From Oli@2:280/464.47 to Carlos Navarro on Sunday, February 13, 2022 13:23:17
    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)
  • From Carlos Navarro@2:341/234.12 to Oli on Sunday, February 13, 2022 16:57:00
    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)
  • From Oli@2:280/464.47 to Carlos Navarro on Monday, February 14, 2022 10:06:33
    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)
  • From Martin Foster@2:280/464.27 to Oli on Monday, February 14, 2022 11:27:19
    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)
  • From mark lewis@1:3634/12.73 to Oli on Monday, February 14, 2022 07:30:32
    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)
  • From Wilfred van Velzen@2:280/464 to Oli on Monday, February 14, 2022 18:22:20



    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)
  • From Tim Schattkowsky@2:240/1120.29 to Oli on Monday, February 14, 2022 19:11:05
    //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)
  • From Nick Andre@1:229/426 to Wilfred Van Velzen on Monday, February 14, 2022 13:15:05
    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)
  • From andrew clarke@3:633/267 to Oli on Tuesday, February 15, 2022 05:21:21
    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)
  • From andrew clarke@3:633/267 to Tim Schattkowsky on Tuesday, February 15, 2022 05:35:19
    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)
  • From Wilfred van Velzen@2:280/464 to Nick Andre on Monday, February 14, 2022 19:51:23
    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)
  • From Rob Swindell to Oli on Monday, February 14, 2022 11:14:32
    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
  • From Carlos Navarro@2:341/234.5 to Oli on Tuesday, February 15, 2022 21:02:52
    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)