• Problem at your system

    From Ward Dossche@2:292/854 to Paul Hayton on Sat Jan 21 23:56:33 2023
    Hi Paul,

    You just sent me a netmailed message about a possible node in Z2.

    I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".

    **************************************************************************** Date: 21 Jan 23 23:37:52
    From: Ward Dossche on 2:292/854 Many-Glacier (020) in Mortsel
    To: Paul Hayton on 2:2/3 Unlisted node in B
    Subj: Your question ____________________________________________________________________________ INTL 2:2/3 2:292/854
    TZUTC: 0100
    FLAGS A/S
    I have a chap in Xxxxxx looking to contact someone in Z2 to get help to
    set up with a Fidonet address.
    ...
    Via 2:292/854@Ward_Dossche @20230121.223859.UTC O/T-Track+ 2.85
    Via 3:770/1 @20230121.224349.UTC hpt/lnx 1.9 2022-07-03
    Via 2:292/854 @20230121.234424 D'Bridge 4 *****************************************************************************

    Can you have a look please?

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Paul Hayton@3:770/100 to Ward Dossche on Sun Jan 22 12:25:14 2023
    On 21 Jan 2023 at 11:56p, Ward Dossche pondered and said...

    You just sent me a netmailed message about a possible node in Z2.

    I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".



    Can you have a look please?

    will do

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Ward Dossche on Sun Jan 22 14:21:54 2023
    On 21 Jan 2023 at 11:56p, Ward Dossche pondered and said...

    Hi Paul,

    You just sent me a netmailed message about a possible node in Z2.

    I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".

    I have looked back at the logging and will drop a file called pingpong.txt in your inbound.

    As far as I can tell you are sending me netmail addressed to 2:2/3.0 and my system is simply routing it back to you as per routing rules I have set to default to route Zone 2 netmail traffic via your system (asides direct Z2 links I have)

    The logs show netmails bounced back and forth three times before it ended. I guess by you?

    Here's a section of the text file I'll send you

    [snip]

    original netmail leaves Agency bound for Ward

    + Jan 22 08:58:21 Resuming from 2186 in fidomail
    + Jan 22 08:58:21 Route (Paul Hayton@3:770/100 to Ward Dossche@2:292/854) via 3:770/1
    + Jan 22 08:58:21 Export FIDO_NMAIL #2186 to 3:770/1@fidonet
    - Jan 22 08:58:21 1 msgs from Netmail (FidoNet)

    3:770/1 tosses and sends direct to Ward

    ----------------------- Sun 22 Jan 2023, hpt/lnx 1.9 2022-07-03
    1 Jan:22:2023:08:58:22 Start
    1 Jan:22:2023:08:58:22 Start packing...
    4 Jan:22:2023:08:58:22 EchoTossLogFile not found -> Scanning all areas
    4 Jan:22:2023:08:58:22 Scanning NetmailArea NETMAIL
    M Jan:22:2023:08:58:22 pktFile /hub/echomail/out/temp/cc444100.pkt created for [2:292/854]
    7 Jan:22:2023:08:58:22 Msg from 3:770/100 to 2:292/854 packed via 2:292/854
    L Jan:22:2023:08:58:22 Msg #27 from 3:770/100 to 2:292/854 deleted
    4 Jan:22:2023:08:58:22 Scanning NetmailArea NETMSG
    M Jan:22:2023:08:58:22 packFile /hub/echomail/out.002/cc444100.su0 created for [2:292/854 via 2:292/854]
    O Jan:22:2023:08:58:22 toss.c:arcmail(): opened '/hub/echomail/out.002/01240356.clo' ("a+" mode)
    7 Jan:22:2023:08:58:22 Packing for 2:292/854 Ward Dossche, cc444100.pkt > cc444100.su0
    6 Jan:22:2023:08:58:22 cmd: zip -9 -j -q /hub/echomail/out.002/cc444100.su0 /hub/echomail/out/temp/cc444100.pkt
    D Jan:22:2023:08:58:22 Statistics
    D Jan:22:2023:08:58:22 areas: 2 msgs: 26
    D Jan:22:2023:08:58:22 exported: 1
    E Jan:22:2023:08:58:22 Areas summary:
    E Jan:22:2023:08:58:22 netmail area NETMAIL - 1 msgs
    1 Jan:22:2023:08:58:22 End

    BinkP delivers to Ward

    22 Jan 08:58:34 [21200] trying many-glacier.dyndns.org [2a02:a03f:83a9:c400:4df3:890a:8ec1:7cc0]...
    22 Jan 08:58:34 [21200] connected
    + 22 Jan 08:58:34 [21200] outgoing session with many-glacier.dyndns.org:24554 [2a02:a03f:83a9:c400:4df3:890a:8ec1:7cc0]
    - 22 Jan 08:58:34 [21200] OPT CRAM-MD5-980f299204b9a537f15f4954ec32d7ee
    + 22 Jan 08:58:34 [21200] Remote requests MD mode
    - 22 Jan 08:58:34 [21200] SYS Many Glacier
    - 22 Jan 08:58:34 [21200] ZYZ Ward Dossche
    - 22 Jan 08:58:34 [21200] LOC Mortsel, Belgium
    - 22 Jan 08:58:34 [21200] NDL 115200,TCP,BINKP
    - 22 Jan 08:58:34 [21200] TIME Sat, 21 Jan 2023 20:58:43 +0100
    - 22 Jan 08:58:34 [21200] VER binkd/1.1a-113/Win32 binkp/1.1
    + 22 Jan 08:58:34 [21200] addr: 2:292/854@fidonet
    + 22 Jan 08:58:34 [21200] addr: 2:2/0@fidonet
    + 22 Jan 08:58:34 [21200] addr: 2:292/80@fidonet
    + 22 Jan 08:58:34 [21200] addr: 2:2/1000@fidonet
    + 22 Jan 08:58:34 [21200] addr: 2:2/1002@fidonet
    - 22 Jan 08:58:35 [21200] TRF 0 0
    + 22 Jan 08:58:35 [21200] Remote has 0b of mail and 0b of files for us
    - 22 Jan 08:58:35 [21200] OPT EXTCMD CRYPT GZ BZ2
    + 22 Jan 08:58:35 [21200] Remote supports EXTCMD mode
    + 22 Jan 08:58:35 [21200] Remote requests CRYPT mode
    + 22 Jan 08:58:35 [21200] Remote supports GZ mode
    + 22 Jan 08:58:35 [21200] Remote supports BZ2 mode
    + 22 Jan 08:58:35 [21200] pwd protected session (MD5)
    - 22 Jan 08:58:35 [21200] session in CRYPT mode
    + 22 Jan 08:58:35 [21200] sending /hub/echomail/out.002/cc444100.su0 as cc444100.su0 (751)
    + 22 Jan 08:58:36 [21200] sent: /hub/echomail/out.002/cc444100.su0 (751, 751.00 CPS, 2:292/854@fidonet)
    + 22 Jan 08:58:36 [21200] done (to 2:292/854@fidonet, OK, S/R: 1/0 (751/0 bytes))
    22 Jan 08:58:36 [21200] session closed, quitting...

    You call back with reply

    + 22 Jan 11:26:40 [30904] incoming session with 2a02:a03f:83a9:c400:4df3:890a:8ec1:7cc0
    - 22 Jan 11:26:40 [30904] SYS Many Glacier
    - 22 Jan 11:26:40 [30904] ZYZ Ward Dossche
    - 22 Jan 11:26:40 [30904] LOC Mortsel, Belgium
    - 22 Jan 11:26:40 [30904] NDL 115200,TCP,BINKP
    - 22 Jan 11:26:40 [30904] TIME Sat, 21 Jan 2023 23:26:48 +0100
    - 22 Jan 11:26:40 [30904] VER binkd/1.1a-113/Win32 binkp/1.1
    + 22 Jan 11:26:40 [30904] addr: 2:292/854@fidonet
    + 22 Jan 11:26:40 [30904] addr: 2:2/0@fidonet
    + 22 Jan 11:26:40 [30904] addr: 2:292/80@fidonet
    + 22 Jan 11:26:40 [30904] addr: 2:2/1000@fidonet
    + 22 Jan 11:26:40 [30904] addr: 2:2/1002@fidonet
    - 22 Jan 11:26:40 [30904] OPT NDA EXTCMD CRYPT GZ BZ2
    + 22 Jan 11:26:40 [30904] Remote supports asymmetric ND mode
    + 22 Jan 11:26:40 [30904] Remote supports EXTCMD mode
    + 22 Jan 11:26:40 [30904] Remote requests CRYPT mode
    + 22 Jan 11:26:40 [30904] Remote supports GZ mode
    + 22 Jan 11:26:40 [30904] Remote supports BZ2 mode
    - 22 Jan 11:26:40 [30904] TRF 0 994
    + 22 Jan 11:26:40 [30904] Remote has 0b of mail and 994b of files for us
    + 22 Jan 11:26:40 [30904] pwd protected session (MD5)
    - 22 Jan 11:26:40 [30904] session in CRYPT mode
    - 22 Jan 11:26:40 [30904] receiving 62325521.PKT (994 byte(s), off 0)
    + 22 Jan 11:26:41 [30904] 62325521.PKT -> /hub/echomail/in/62325521.PKT
    22 Jan 11:26:41 [30904] got *.[pP][kK][tT], delayed starting /hub/bats/hpt-incoming.sh
    + 22 Jan 11:26:41 [30904] rcvd: 62325521.PKT (994, 994.00 CPS, 2:292/854@fidonet)
    + 22 Jan 11:26:41 [30904] done (from 2:292/854@fidonet, OK, S/R: 0/1 (0/994 bytes))
    22 Jan 11:26:41 [30904] Running /hub/bats/hpt-incoming.sh
    - 22 Jan 11:26:41 [30904] executing `/hub/bats/hpt-incoming.sh'
    - 22 Jan 11:26:41 [30904] rc=0
    22 Jan 11:26:41 [30904] session closed, quitting...

    Your netmail is processed it's addressed to 2:2/3.0

    ----------------------- Sun 22 Jan 2023, hpt/lnx 1.9 2022-07-03
    1 Jan:22:2023:11:26:41 Start
    1 Jan:22:2023:11:26:41 Start tossing...
    O Jan:22:2023:11:26:41 Process incoming file /hub/echomail/in/62325521.PKT
    O Jan:22:2023:11:26:41 toss.c:processPkt(): opened '/hub/echomail/in/62325521.tos' ("rb" mode)
    7 Jan:22:2023:11:26:41 pkt: /hub/echomail/in/62325521.tos [2:292/854]
    L Jan:22:2023:11:26:41 Netmail from 2:292/854 to 2:2/3.0
    L Jan:22:2023:11:26:41 Wrote Netmail: 2:292/854.0 -> 2:2/3.0
    4 Jan:22:2023:11:26:41 Statistics:
    4 Jan:22:2023:11:26:41 arc: 0 netMail: 1 echoMail: 0 CC: 0
    4 Jan:22:2023:11:26:41 pkt's: 1 dupe: 0 passthru: 0 exported: 0
    4 Jan:22:2023:11:26:41 msgs: 1 bad: 0 saved: 0 empty: 0
    4 Jan:22:2023:11:26:41 Input: 125.00 mails/sec Output: 0.00 mails/sec
    4 Jan:22:2023:11:26:41 121.34 kb/sec
    4 Jan:22:2023:11:26:41 0.97 kb total, processed in 0.008 seconds
    4 Jan:22:2023:11:26:41 Areas summary:
    4 Jan:22:2023:11:26:41 netmail area NETMAIL - 1 msgs
    1 Jan:22:2023:11:26:41 End tossing
    3 Jan:22:2023:11:26:41 Using importlogfile -> linking only listed Areas
    3 Jan:22:2023:11:26:41 Linking area NETMAIL
    1 Jan:22:2023:11:26:41 End

    My routing rules route this back to you, the route file contains

    route crash 2:292/854 2:*

    So it routes your message back to you

    ----------------------- Sun 22 Jan 2023, hpt/lnx 1.9 2022-07-03
    1 Jan:22:2023:11:26:41 Start
    1 Jan:22:2023:11:26:41 Start packing...
    4 Jan:22:2023:11:26:41 EchoTossLogFile not found -> Scanning all areas
    4 Jan:22:2023:11:26:41 Scanning NetmailArea NETMAIL
    M Jan:22:2023:11:26:41 pktFile /hub/echomail/out/temp/cc670400.pkt created for [2:292/854]
    7 Jan:22:2023:11:26:41 Msg from 2:292/854 to 2:2/3 packed via 2:292/854
    L Jan:22:2023:11:26:41 Msg #27 from 2:292/854 to 2:2/3 deleted
    4 Jan:22:2023:11:26:41 Scanning NetmailArea NETMSG
    M Jan:22:2023:11:26:41 packFile /hub/echomail/out.002/cc670400.su0 created for [2:292/854 via 2:292/854]
    O Jan:22:2023:11:26:41 toss.c:arcmail(): opened '/hub/echomail/out.002/01240356.clo' ("a+" mode)
    7 Jan:22:2023:11:26:41 Packing for 2:292/854 Ward Dossche, cc670400.pkt > cc670400.su0
    6 Jan:22:2023:11:26:41 cmd: zip -9 -j -q /hub/echomail/out.002/cc670400.su0 /hub/echomail/out/temp/cc670400.pkt
    D Jan:22:2023:11:26:41 Statistics
    D Jan:22:2023:11:26:41 areas: 2 msgs: 26
    D Jan:22:2023:11:26:41 exported: 1
    E Jan:22:2023:11:26:41 Areas summary:
    E Jan:22:2023:11:26:41 netmail area NETMAIL - 1 msgs
    1 Jan:22:2023:11:26:41 End

    BinkD sends it back

    + 22 Jan 11:26:45 [30912] call to 2:292/854@fidonet
    22 Jan 11:26:45 [30912] trying many-glacier.dyndns.org [2a02:a03f:83a9:c400:4df3:890a:8ec1:7cc0]...
    22 Jan 11:26:46 [30912] connected
    + 22 Jan 11:26:46 [30912] outgoing session with many-glacier.dyndns.org:24554 [2a02:a03f:83a9:c400:4df3:890a:8ec1:7cc0]
    - 22 Jan 11:26:47 [30912] OPT CRAM-MD5-f7145dd9885524feef0f196bf7c267ee
    + 22 Jan 11:26:47 [30912] Remote requests MD mode
    - 22 Jan 11:26:47 [30912] SYS Many Glacier
    - 22 Jan 11:26:47 [30912] ZYZ Ward Dossche
    - 22 Jan 11:26:47 [30912] LOC Mortsel, Belgium
    - 22 Jan 11:26:47 [30912] NDL 115200,TCP,BINKP
    - 22 Jan 11:26:47 [30912] TIME Sat, 21 Jan 2023 23:26:55 +0100
    - 22 Jan 11:26:47 [30912] VER binkd/1.1a-113/Win32 binkp/1.1
    + 22 Jan 11:26:47 [30912] addr: 2:292/854@fidonet
    + 22 Jan 11:26:47 [30912] addr: 2:2/0@fidonet
    + 22 Jan 11:26:47 [30912] addr: 2:292/80@fidonet
    + 22 Jan 11:26:47 [30912] addr: 2:2/1000@fidonet
    + 22 Jan 11:26:47 [30912] addr: 2:2/1002@fidonet
    - 22 Jan 11:26:47 [30912] TRF 0 0
    + 22 Jan 11:26:47 [30912] Remote has 0b of mail and 0b of files for us
    - 22 Jan 11:26:47 [30912] OPT EXTCMD CRYPT GZ BZ2
    + 22 Jan 11:26:47 [30912] Remote supports EXTCMD mode
    + 22 Jan 11:26:47 [30912] Remote requests CRYPT mode
    + 22 Jan 11:26:47 [30912] Remote supports GZ mode
    + 22 Jan 11:26:47 [30912] Remote supports BZ2 mode
    + 22 Jan 11:26:47 [30912] pwd protected session (MD5)
    - 22 Jan 11:26:47 [30912] session in CRYPT mode
    + 22 Jan 11:26:47 [30912] sending /hub/echomail/out.002/cc670400.su0 as cc670400.su0 (852)
    + 22 Jan 11:26:48 [30912] sent: /hub/echomail/out.002/cc670400.su0 (852, 852.00 CPS, 2:292/854@fidonet)
    + 22 Jan 11:26:48 [30912] done (to 2:292/854@fidonet, OK, S/R: 1/0 (852/0 bytes))
    22 Jan 11:26:48 [30912] session closed, quitting...

    [snip]

    As far as I can see my end is not causing any issues.

    Best, Paul

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Andrew Leary@1:320/219 to Ward Dossche on Sun Jan 22 00:35:31 2023

    Hello Ward!

    21 Jan 23 23:56, you wrote to Paul Hayton:

    I responded to your message and your system dumps the netmail back on
    my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".

    Looks like someone's system is trying to use a ZoneGate from Z2 to Z3. Of course, these haven't existed for quite some time...

    Andrew

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Paul Hayton@3:770/100 to Andrew Leary on Sun Jan 22 19:44:51 2023
    On 22 Jan 2023 at 12:35a, Andrew Leary pondered and said...

    Looks like someone's system is trying to use a ZoneGate from Z2 to Z3.
    Of course, these haven't existed for quite some time...

    Hi Andrew

    is this something I need to check on my end?

    If so where do I need to look?

    Thanks :)

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Andrew Leary@1:320/219 to Paul Hayton on Sun Jan 22 02:22:00 2023
    Hello Paul!

    22 Jan 23 19:44, you wrote to me:

    Looks like someone's system is trying to use a ZoneGate from Z2
    to Z3. Of course, these haven't existed for quite some time...

    Hi Andrew

    is this something I need to check on my end?

    If so where do I need to look?

    The ZoneGate option is normally selected on the sending system. When it is selected, the destination address in the message header is changed from the actual destination to the ZoneGate system, (origin zone:origin zone/destination zone) with the actual destination remaining in the INTL kludge line. With most connections in FidoNet being made over the internet these days, the ZoneGates were considered unnecessary overhead and thus removed from the nodelist.

    In this case, I wonder if Ward accidentally selected the ZoneGate option when replying to your message. Your system apparently saw that the incoming packet was addressed to 2:2/3 and sent it back to Ward based on your routing rules.

    Andrew

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Paul Hayton@3:770/100 to Andrew Leary on Sun Jan 22 21:28:23 2023
    On 22 Jan 2023 at 02:22a, Andrew Leary pondered and said...

    The ZoneGate option is normally selected on the sending system. When it is selected, the destination address in the message header is changed from the actual destination to the ZoneGate system, (origin zone:origin zone/destination zone) with the actual destination remaining in the INTL kludge line. With most connections in FidoNet being made over the internet these days, the ZoneGates were considered unnecessary overhead and thus removed from the nodelist.

    Thanks for this info Andrew.

    In this case, I wonder if Ward accidentally selected the ZoneGate option when replying to your message. Your system apparently saw that the incoming packet was addressed to 2:2/3 and sent it back to Ward based
    on your routing rules.

    Yes, it looked to me like the incoming message from him was addressed to 2:2/3 so my system just routed it back to him as per my routing rules.

    Thanks for your reply. Let's see if Ward can shed any further light.

    Best, Paul

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Ward Dossche@2:292/854 to Paul Hayton on Sun Jan 22 11:45:16 2023
    Hey Paul,

    Thanks for your reply. Let's see if Ward can shed any further light.

    I was hoping to avoid a Roy Witt scenario, but here we are anyway.

    But it's Sunday, I haven't had my morning coffee yet. Traditionally on Sunday mornings we eat a soft-boiled egg with a "pistolet", I don't know how to translate that into english, it's not a gun but a small French bread. Americans would call it "a bun" but they're sometimes such culinary bastards as that would remind me immediately of McDonalds, BK etc ... Think of the same bun, but fresh and crunchy.

    Then my youngest daughter is going to have a baby and she has gotten a lot of baby-room furniture for free from a sister-in-law ... now she has a pile of panels, wooden plugs, screws and bolts and "Daddy, we've had a problem" where "daddy" is a replacement for "Houston". I wouldn't mind arguing with you about how bad your software set-up is after I dropped some messages in Z3 and only your system is sending it back ... altered, it's HPT I see, but I'm not going to argue with a pregnant young female bursting with hormones as that could be the end of me .... I could argue with Andrew Leary after he jumped into this that Roy Witt should not be impersonated in turning the facts around and putting the cart in front of the horse ... but that still will not save me from the scorn of the pregnant female. 8-)

    It's just a matter of priorities so please bear with me for a while and pray to the gods that I will survive long enough to continue this, so far, not very fruitful conversation. But I'm sure we'll get to somewhere ... eventually.

    {I write some of the best political bullshit, right?}

    Take care,

    \%/@rd

    Hmmmm ... in fact, why was a cart never put in front of a horse? It might have worked, in the european lowlands it used to be done with dogs ...

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Paul Hayton on Sun Jan 22 14:04:50 2023
    Hey Paul,

    As far as I can tell you are sending me netmail addressed to 2:2/3.0 ...

    Thank you for looking into this, but after this one single line you've already de-railed ... For test-purposes I created a new message and it is addressed to 3:770/100 .... This is how it looks ...

    ***************************************************************************** Date: 22 Jan 23 12:41:57
    From: Ward Dossche on 2:292/854 Many-Glacier (021) in Mortsel
    To: Paul Hayton on 3:770/100 Agency BBS in Dunedin
    Subj: This is the ultimate test ____________________________________________________________________________ INTL 3:770/100 2:292/854
    TZUTC: 0100
    FLAGS A/S
    It really is ... *****************************************************************************

    It gets delivered at 3:770/1 and within a second your system responds and sends the netmail below back to me ...

    ***************************************************************************** Date: 22 Jan 23 12:41:56
    From: Ward Dossche on 2:292/854 Many-Glacier (021) in Mortsel
    To: Paul Hayton on 2:2/3 Unlisted node in B
    Subj: This is the ultimate test ____________________________________________________________________________ INTL 2:2/3 2:292/854
    TZUTC: 0100
    FLAGS A/S
    It really is ...
    Via 2:292/854@Ward_Dossche @20230122.114314.UTC O/T-Track+ 2.85
    Via 3:770/1 @20230122.114948.UTC hpt/lnx 1.9 2022-07-03
    Via 2:292/854 @20230122.125104 D'Bridge 4 *****************************************************************************

    Note, the INTL-kludge has been altered from "3:770/100 2:292/854"
    to "2:2/3 2:292/854" ....

    Not only that, but the time-stamp of the netmail has been changed from "12:41:57" to "12:41:56".

    I have delivered a netmail from you at Scott's system and it does not bounce back...

    So, yes, there is a problem at your site and I suspect it is software related.

    Zonegates are not an issue here, I have never used them, you cannot find them anywhere here, they were dropped from the nodelist here in March 2009.

    It "is" a software-problem, or a case of set-up, on your side, Paul.

    For the ones loving discussions, here's the log of my system delivering that netmail at Paul's system and the immediate return of the altered version.

    ********************** OUTGOING ***************************************
    22 Jan 12:49:47 [9732] trying agency.bbs.nz [2001:470:d:123::200]...
    22 Jan 12:49:47 [9732] connected
    + 22 Jan 12:49:47 [9732] outgoing session with agency.bbs.nz:24554 [2001:470:d:123::200]
    - 22 Jan 12:49:48 [9732] OPT CRAM-MD5-6db1bd639153d8eea397573aef74adee
    + 22 Jan 12:49:48 [9732] Remote requests MD mode
    - 22 Jan 12:49:48 [9732] SYS Agency + Risa HUB
    - 22 Jan 12:49:48 [9732] ZYZ Paul Hayton
    - 22 Jan 12:49:48 [9732] LOC Dunedin, New Zealand
    - 22 Jan 12:49:48 [9732] NDL 115200,TCP,CM,MO,IBN,BINKP,PING,IPv6
    - 22 Jan 12:49:48 [9732] TIME Mon, 23 Jan 2023 00:49:47 +1300
    - 22 Jan 12:49:48 [9732] VER binkd/1.1a-115/Linux binkp/1.1
    + 22 Jan 12:49:48 [9732] addr: 3:57/0@fidonet
    + 22 Jan 12:49:48 [9732] addr: 3:770/1@fidonet
    + 22 Jan 12:49:48 [9732] addr: 3:770/0@fidonet
    + 22 Jan 12:49:48 [9732] addr: 3:772/1@fidonet
    + 22 Jan 12:49:48 [9732] addr: 3:772/0@fidonet
    + 22 Jan 12:49:48 [9732] addr: 21:1/100@fsxnet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 21:1/3@fsxnet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 21:1/2@fsxnet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 21:1/1@fsxnet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 21:1/0@fsxnet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 39:970/0@amiganet (n/a or busy)
    + 22 Jan 12:49:48 [9732] addr: 46:3/103@agoranet (n/a or busy)
    - 22 Jan 12:49:48 [9732] TRF 0 0
    + 22 Jan 12:49:48 [9732] Remote has 0b of mail and 0b of files for us
    - 22 Jan 12:49:48 [9732] OPT EXTCMD CRYPT GZ BZ2
    + 22 Jan 12:49:48 [9732] Remote supports EXTCMD mode
    + 22 Jan 12:49:48 [9732] Remote requests CRYPT mode
    + 22 Jan 12:49:48 [9732] Remote supports GZ mode
    + 22 Jan 12:49:48 [9732] Remote supports BZ2 mode
    + 22 Jan 12:49:48 [9732] pwd protected session (MD5)
    - 22 Jan 12:49:48 [9732] session in CRYPT mode
    + 22 Jan 12:49:48 [9732] sending C:\DB\BINKD\37701\01249331.PKT as 01249331.PKT (297)
    + 22 Jan 12:49:49 [9732] sent: C:\DB\BINKD\37701\01249331.PKT (297, 297.00 CPS, 3:770/1@fidonet)
    + 22 Jan 12:49:49 [9732] done (to 3:770/1@fidonet, OK, S/R: 1/0 (297/0 bytes))
    22 Jan 12:49:49 [9732] session closed, quitting...
    *********************** INCOMING ******************************************
    - 22 Jan 12:49:50 [17944] incoming from 2001:470:d:123::200 (49182)
    + 22 Jan 12:49:50 [4872] incoming session with 2001:470:d:123::200
    - 22 Jan 12:49:50 [4872] SYS Agency + Risa HUB
    - 22 Jan 12:49:50 [4872] ZYZ Paul Hayton
    - 22 Jan 12:49:50 [4872] LOC Dunedin, New Zealand
    - 22 Jan 12:49:50 [4872] NDL 115200,TCP,CM,MO,IBN,BINKP,PING,IPv6
    - 22 Jan 12:49:50 [4872] TIME Mon, 23 Jan 2023 00:49:49 +1300
    - 22 Jan 12:49:50 [4872] VER binkd/1.1a-115/Linux binkp/1.1
    + 22 Jan 12:49:50 [4872] addr: 3:57/0@fidonet
    + 22 Jan 12:49:50 [4872] addr: 3:770/1@fidonet
    + 22 Jan 12:49:50 [4872] addr: 3:770/0@fidonet
    + 22 Jan 12:49:50 [4872] addr: 3:772/1@fidonet
    + 22 Jan 12:49:50 [4872] addr: 3:772/0@fidonet
    + 22 Jan 12:49:50 [4872] addr: 21:1/100@fsxnet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 21:1/3@fsxnet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 21:1/2@fsxnet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 21:1/1@fsxnet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 21:1/0@fsxnet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 39:970/0@amiganet (n/a or busy)
    + 22 Jan 12:49:50 [4872] addr: 46:3/103@agoranet (n/a or busy)
    - 22 Jan 12:49:50 [4872] OPT NDA EXTCMD CRYPT GZ BZ2
    + 22 Jan 12:49:50 [4872] Remote supports asymmetric ND mode
    + 22 Jan 12:49:50 [4872] Remote supports EXTCMD mode
    + 22 Jan 12:49:50 [4872] Remote requests CRYPT mode
    + 22 Jan 12:49:50 [4872] Remote supports GZ mode
    + 22 Jan 12:49:50 [4872] Remote supports BZ2 mode
    - 22 Jan 12:49:50 [4872] TRF 0 428
    + 22 Jan 12:49:50 [4872] Remote has 0b of mail and 428b of files for us
    + 22 Jan 12:49:50 [4872] pwd protected session (MD5)
    - 22 Jan 12:49:50 [4872] session in CRYPT mode
    - 22 Jan 12:49:51 [4872] receiving cd233f00.mo0 (428 byte(s), off 0)
    + 22 Jan 12:49:51 [4872] cd233f00.mo0 -> c:\db\inbound\cd233f00.mo0
    + 22 Jan 12:49:51 [4872] rcvd: cd233f00.mo0 (428, 428.00 CPS, 3:57/0@fidonet)
    + 22 Jan 12:49:51 [4872] done (from 3:57/0@fidonet, OK, S/R: 0/1 (0/428 bytes))
    22 Jan 12:49:51 [4872] session closed, quitting... *****************************************************************************

    Please, Paul, no Roy Witt stuff here by turning the issue around, I've been too long in this business to not understand it.

    And don't take this personal ..

    Take care,

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Andrew Leary on Sun Jan 22 14:18:59 2023
    Andrew,

    In this case, I wonder if Ward accidentally selected the ZoneGate option when replying to your message.

    The thing is, Andrew, the software which I use which is the D'Bridge system, doesn't even mention zonegates anywhere ... it doesn't know what it is (though Nick may always correct me). It is not mentioned in the help-file/manual.

    As I started to log all kind of khrap years ago when issues popped-up and it was more import to deny them than to deal with them, I went to look in the outbound LOG and those message went exactly the way they should go.

    Besides, if/when Paul's system encountered a message miraculously addressed at 2:2/3 ... as it isn't listed in any modelist inside Fidonet (!), his tracker should have discarded it as undeliverable ...

    Andrew, no Roy Witt stuff please.

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Paul Hayton on Sun Jan 22 14:20:05 2023
    Paul,

    Yes, it looked to me like the incoming message from him was addressed to 2:2/3 so my system just routed it back to him as per my routing rules.

    Did you examine the inbound pkt-file?

    Mu bet is on "no" ...

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Mike Miller@1:154/30 to Ward Dossche on Sun Jan 22 08:10:24 2023

    Hello Ward!

    22 Jan 23 11:45, you wrote to Paul Hayton:

    Hey Paul,

    Thanks for your reply. Let's see if Ward can shed any further
    light.

    I was hoping to avoid a Roy Witt scenario, but here we are anyway.

    But it's Sunday, I haven't had my morning coffee yet. Traditionally on Sunday mornings we eat a soft-boiled egg with a "pistolet", I don't
    know how to translate that into english, it's not a gun but a small
    French bread. Americans would call it "a bun" but they're sometimes
    such culinary bastards as that would remind me immediately of
    McDonalds, BK etc ... Think of the same bun, but fresh and crunchy.

    A "roll". we call it a "roll".



    Mike


    ... Murphy's Eighth Law:
    === GoldED+/LNX 1.1.5-b20220504
    --- SBBSecho 3.20-Linux
    * Origin: War Ensemble - warensemble.com - Appleton, WI (1:154/30)
  • From Ward Dossche@2:292/854 to Mike Miller on Sun Jan 22 17:49:15 2023
    Mike,

    A "roll". we call it a "roll".

    Ah yes, I was looking for the word but it didn't dawn.

    Nevertheless, crunchy, not soft ...

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 08:31:43 2023
    Re: Re: Problem at your system
    By: Ward Dossche to Paul Hayton on Sun Jan 22 2023 02:04 pm

    Hey Ward,

    Thank you for looking into this, but after this one single line you've already de-railed ... For test-purposes I created a new message and it is addressed to 3:770/100 .... This is how it looks ...

    Any chance you can make a new message, but instead of "delivering it", capture the packet that gets created and make it available? Paul and I run a very similar setup and I wasnt aware that hpt did that - so I'd be keen to understand if it does, under what cirmcustances it does and how it's controlled.

    Can you zip the packet up and drop it to me please ? 3:633/509.



    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to deon on Sun Jan 22 23:10:07 2023
    deon,

    Any chance you can make a new message, but instead of "delivering it", capture the packet that gets created and make it available? Paul and I
    run a very similar setup and I wasnt aware that hpt did that - so I'd be keen to understand if it does, under what cirmcustances it does and how
    it's controlled.

    I suppose that could be done ...

    Can you zip the packet up and drop it to me please ? 3:633/509.

    Let me look into that and I'll try to comply ...

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Paul Hayton@3:770/100 to Ward Dossche on Mon Jan 23 11:44:27 2023
    On 22 Jan 2023 at 02:20p, Ward Dossche pondered and said...

    Yes, it looked to me like the incoming message from him was addressed 2:2/3 so my system just routed it back to him as per my routing rules.

    Did you examine the inbound pkt-file?

    Mu bet is on "no" ...

    I have not, it was deleted when processed and I don't (at the moment) capture a copy of all inbound packets. But I can work on setting that up temporarily to see what I can find out. We'll need to co-ordinate this when I am set up.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Ward Dossche on Mon Jan 23 11:45:36 2023
    On 22 Jan 2023 at 11:45a, Ward Dossche pondered and said...

    Hey Paul,

    Thanks for your reply. Let's see if Ward can shed any further light.

    I was hoping to avoid a Roy Witt scenario, but here we are anyway.

    I don't know what you're on about. I've just replied to your echomail in good faith with all that I can find out about what is happening.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Ward Dossche on Mon Jan 23 11:54:10 2023
    On 22 Jan 2023 at 02:04p, Ward Dossche pondered and said...

    Hey Paul,

    As far as I can tell you are sending me netmail addressed to 2:2/3.0 .

    Thank you for looking into this, but after this one single line you've already de-railed ... For test-purposes I created a new message and it
    is addressed to 3:770/100 .... This is how it looks ...

    [snip]

    So, yes, there is a problem at your site and I suspect it is software related.
    Zonegates are not an issue here, I have never used them, you cannot find them anywhere here, they were dropped from the nodelist here in March 2009.
    It "is" a software-problem, or a case of set-up, on your side, Paul.

    For the ones loving discussions, here's the log of my system delivering that netmail at Paul's system and the immediate return of the altered version.

    [snip]

    ************************************************************************** Please, Paul, no Roy Witt stuff here by turning the issue around, I've been too long in this business to not understand it.

    And don't take this personal ..

    Ward, you are making this into something it is not. I recall the name and the chap and from my limited time in Fido when he was alive I recall a lot of combative posts between Roy and others (yourself included?). Why you feel the need to invoke this sentiment and his name in a thread that you kicked off and I am just doing my best to respond to lord knows.

    I've just tried in good faith to get your email contact details confirmed via netmail so I can pass them along to a chap who is in Z2 wanting to talk to someone in Fido about getting a node number.

    I have seen a test netmail from you via Scott and replied to that... but as yet I am none the wiser about my original question to you to help this new sysop. Perhaps you can reply to that by netmail and send it via Scott while we work to sort out what is happening to netmail between our two systems?

    I will try to look at logs again later tonight (my time) to share what I find. If it's a fault with the software / system at my end I'm happy to own that but for now all I have done is share with you (and others) what I have found.

    In doing so, and by replying to your echomail post that started this thread, it's seemingly morphing into something with a vibe that feels combative and I'm at a loss to understand why. Roy Witt. Don't take this personally. Really? WTF?

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Ward Dossche@2:292/854 to deon on Sun Jan 22 23:33:15 2023
    Deon,

    Can you zip the packet up and drop it to me please ? 3:633/509.

    I just delivered it at your system.

    Also I released the message to Paul and it came back within a second.

    Take care,

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Paul Hayton on Mon Jan 23 00:14:08 2023
    Hello Paul,

    I've just tried in good faith to get your email contact details confirmed via netmail so I can pass them along to a chap who is in Z2 wanting to
    talk to someone in Fido about getting a node number.

    I can confirm the email address you mentioned is correct, but as the prospective node resides in Norway (whose region expired in 2014 by request of its last node) and Norway is part of Scandinavia I would refer it to the RC who handles the joint Scandinavian nets. I'm sure he will have a solution one way or the other .

    That RC is Bjorn Felten and he can be reached by netmail at b@felten.se. If your guy sends email overthere it will be handled.

    If it doesn't work-out, get back to me in email and I'll handle it from this location.

    \%/@rd

    That was more or less the content of the netmail that didn't work-out

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Paul Hayton on Mon Jan 23 00:41:44 2023
    Hello Paul,

    Why you feel the need to invoke this sentiment and his name in a thread that you kicked off and I am just doing my best to respond to lord knows.

    That is a very good question.

    At some point in time, I coined the phrase "Pulling a Witt" meaning that when confronted with an issue the other side by definition must be wrong without looking into the matter. Roy was a master in that, especially in turning the argument around.

    So when I got totally confused at what was happening and went to echomail, here was Andrew Leary suggesting I was accidentally the culprit anyway by unknowingly triggering a zonegate ... something which doesn't exist in D'Bridge.

    I have been using the package since 1988 somewhat as a point, later as a node and I can run it blindfolded ... there's no hidden 2:2/3 in it, nor is there in the nodelist.

    Some weeks ago there was some issue with a CRC in a nodediff down the line, only on 1 system ... "Ward must have made an error" was the immediate comment. This has happened before.

    I have erred in the past and when I do I have tried to be open about it but the automatic finger pointing and guessing what I have done wrong needs to end at some point, my learning curve is close to 35 years long.

    And remember, I wrote "Don't take it personal". When someone calls me an asshole, I don't take it personal either, after all that person may even be right.

    Take care,

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Paul Hayton@3:770/100 to Ward Dossche on Mon Jan 23 12:54:18 2023
    On 23 Jan 2023 at 12:14a, Ward Dossche pondered and said...

    That RC is Bjorn Felten and he can be reached by netmail at b@felten.se. If your guy sends email overthere it will be handled.

    Thanks will pass the details along to the new prospective node.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to deon on Mon Jan 23 12:57:22 2023
    On 23 Jan 2023 at 08:31a, deon pondered and said...

    Any chance you can make a new message, but instead of "delivering it", capture the packet that gets created and make it available? Paul and I
    run a very similar setup and I wasnt aware that hpt did that - so I'd be keen to understand if it does, under what cirmcustances it does and how it's controlled.

    thanks Deon.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Ward Dossche on Mon Jan 23 13:10:26 2023
    On 23 Jan 2023 at 12:41a, Ward Dossche pondered and said...

    At some point in time, I coined the phrase "Pulling a Witt" meaning that when confronted with an issue the other side by definition must be wrong without looking into the matter. Roy was a master in that, especially in turning the argument around.

    So when I got totally confused at what was happening and went to
    echomail, here was Andrew Leary suggesting I was accidentally the
    culprit anyway by unknowingly triggering a zonegate ... something which doesn't exist in D'Bridge.

    [snip]

    And remember, I wrote "Don't take it personal". When someone calls me an asshole, I don't take it personal either, after all that person may even be right.

    It all seemed to me totally unnecessary Ward. Regardless of the encounters you have had with whomever over what in the past. If you reply with a 'Please, Paul, no Roy Witt stuff here by turning the issue around. I've been too long in this business to not understand it" that's a poor stance to adopt with someone just trying to reply and help debug a problem.

    It infers you think I am motivated to act in some negative fashion towards you and I was not. I fail to see why I should not take it personally when you write to me so explicitly in this manner.

    May I suggest you take 5 and double check your assumptions on motive and seek to ask further questions to clarify the stance of your correspondent before you invoke your erm sense of Witt.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 11:16:07 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Sun Jan 22 2023 11:33 pm

    Can you zip the packet up and drop it to me please ? 3:633/509.

    I just delivered it at your system.

    Also I released the message to Paul and it came back within a second.

    Got it, thank you.

    And indeed, from your side it seems to be addressed correctly - so I think I would also be able to process it (if my hpt system was servicing my fido feed).

    Validated on my site:
    https://clrghouz.bbs.dege.au/pkt

    Paul, indeed it looks like it might be your side that is modifying and doing something to that packet? Certainly does seem odd whats going on...


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 11:20:00 2023
    Re: Re: Problem at your system
    By: deon to Ward Dossche on Mon Jan 23 2023 11:16 am

    I was wrong...

    Can you zip the packet up and drop it to me please ? 3:633/509.

    I just delivered it at your system.

    Also I released the message to Paul and it came back within a second.

    Got it, thank you.

    And indeed, from your side it seems to be addressed correctly - so I think I would also be able to process it (if my hpt system was servicing my fido feed).

    Validated on my site:
    https://clrghouz.bbs.dege.au/pkt

    Paul, indeed it looks like it might be your side that is modifying and doing something to that packet? Certainly does seem odd whats going on...

    Ward, I didnt read my dump fully.

    Ward, it does appear to be your system, that is addressing the "packet" to Paul at 3:770/1, but the "netmail" inside the packet file, is addressed to "2/3".

    So it would appear to be from your side...


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to Paul Hayton on Mon Jan 23 01:23:32 2023
    It infers you think I am motivated to act in some negative fashion
    towards you and I was not. I fail to see why I should not take it personally when you write to me so explicitly in this manner.

    It's a good thing ZC1 is not involved because if you think I was explicit, think again.

    Anyway, I take it your guy is being helped soon and deon will be back with an analyses.

    My bet? HPT?

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 11:34:58 2023
    Re: Re: Problem at your system
    By: deon to Ward Dossche on Mon Jan 23 2023 11:20 am

    Sorry, pressed send by mistake:

    I was wrong...
    Ward, I didnt read my dump fully.

    Ward, it does appear to be your system, that is addressing the "packet" to Paul at 3:770/1, but the "netmail" inside the packet file, is addressed to "2/3".

    So it would appear to be from your side...

    Sorry, pressed send by mistake, here is the detail:
    00000030: 03 00 00 00 00 00 00 00 00 00 02 00 56 03 03 00 [............V...] 00000040: 24 01 02 00 01 00 00 00 32 32 20 4a 61 6e 20 32 [$.......22 Jan 2] 00000050: 33 20 20 32 33 3a 32 32 3a 30 33 00 50 61 75 6c [3 23:22:03.Paul]

    More info, for those interested:
    A packet message starts after the packet header (which finishes at 0x3a) and starts with 0x02 0x00 (FTS-0001.16)

    Then:
    * 0x56 0x03 (0x356 = 854) - Ward originating node
    * 0x03 0x00 (0x003 = 3) - designation node
    * 0x24 0x01 (0x124 = 292) - Ward originating net
    * 0x02 0x00 (0x002 = 2) - destination net

    Ward, it seems you are packing the message incorrectly.


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Dan Clough@1:123/115 to Ward Dossche on Sun Jan 22 18:51:00 2023
    Ward Dossche wrote to Paul Hayton <=-

    Why you feel the need to invoke this sentiment and his name in a thread that you kicked off and I am just doing my best to respond to lord knows.

    That is a very good question.

    One which is very easy to answer. It's because you're a cratchety old asshole, through and through.



    ... Ignorance can be cured. Stupid is forever.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Dan Clough@1:123/115 to deon on Sun Jan 22 18:54:00 2023
    deon wrote to Ward Dossche <=-

    Ward, I didnt read my dump fully.

    Ward, it does appear to be your system, that is addressing the
    "packet" to Paul at 3:770/1, but the "netmail" inside the packet
    file, is addressed to "2/3".

    So it would appear to be from your side...

    Please, <deity-of-choice>, let this be true. I am very eager to see
    Ward eat some crow and publicly apologize for being an asshole for no
    reason.



    ... Honk if you've never seen an Uzi fired from a car window.
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Tommi Koivula@2:221/6 to Ward Dossche on Mon Jan 23 08:29:14 2023
    On 22.1.2023 0.56, Ward Dossche wrote:

    Hi Paul,

    You just sent me a netmailed message about a possible node in Z2.

    I responded to your message and your system dumps the netmail back on my system with this change that "Paul Hayton 3:770/100" is changed to "Paul Hayton 2:2/3".

    **************************************************************************** Date: 21 Jan 23 23:37:52
    From: Ward Dossche on 2:292/854 Many-Glacier (020) in Mortsel
    To: Paul Hayton on 2:2/3 Unlisted node in B
    Subj: Your question ____________________________________________________________________________ INTL 2:2/3 2:292/854
    TZUTC: 0100
    FLAGS A/S
    I have a chap in Xxxxxx looking to contact someone in Z2 to get help to set up with a Fidonet address.
    ..
    Via 2:292/854@Ward_Dossche @20230121.223859.UTC O/T-Track+ 2.85
    Via 3:770/1 @20230121.224349.UTC hpt/lnx 1.9 2022-07-03
    Via 2:292/854 @20230121.234424 D'Bridge 4 *****************************************************************************

    Can you have a look please?

    You should check your O/T-Track zonegate settings.

    Via 2:292/854@Ward_Dossche @20230121.223859.UTC O/T-Track+ 2.85

    The domain is wrong for sure.

    'Tommi

    ---
    * Origin: nntp://news.fidonet.fi (2:221/6.0)
  • From Andrew Leary@1:320/219 to deon on Mon Jan 23 00:47:04 2023

    Hello deon!

    23 Jan 23 11:34, you wrote to Ward Dossche:

    Sorry, pressed send by mistake:

    I was wrong...
    Ward, I didnt read my dump fully.

    Ward, it does appear to be your system, that is addressing the
    "packet" to Paul at 3:770/1, but the "netmail" inside the packet
    file, is addressed to "2/3".

    So it would appear to be from your side...

    Sorry, pressed send by mistake, here is the detail:
    00000030: 03 00 00 00 00 00 00 00 00 00 02 00 56 03 03 00 [............V...]
    00000040: 24 01 02 00 01 00 00 00 32 32 20 4a 61 6e 20 32
    [$.......22 Jan 2]
    00000050: 33 20 20 32 33 3a 32 32 3a 30 33 00 50 61 75 6c [3 23:22:03.Paul]

    More info, for those interested:
    A packet message starts after the packet header (which finishes at
    0x3a) and starts with 0x02 0x00 (FTS-0001.16)

    Then:
    * 0x56 0x03 (0x356 = 854) - Ward originating node
    * 0x03 0x00 (0x003 = 3) - designation node
    * 0x24 0x01 (0x124 = 292) - Ward originating net
    * 0x02 0x00 (0x002 = 2) - destination net

    Ward, it seems you are packing the message incorrectly.

    Confirmed here on my D'Bridge 4 (01-01-2023) test point; I created a message addressed to Ward in the D'Bridge editor, saved it, and quit back to D'Bridge. The message was packed for 2:292/854 in the queue. I then quit out of D'Bridge and examined the .PKT file in D'Bridge's queue directory. The packet header was addressed to 2:292/854, but the message was addressed to 1:1/2 with the INTL kludge indicating 2:292/854 as the ultimate destination.

    It appears that the version of D'Bridge 4 that Ward is using (01-01-2023?) is packing messages as if they were to be sent through a zonegate. The packet header is properly addressed to the destination, but the message(s) in the packet are addressed to the zonegate address. This appears to happen regardless of whether or not you select the "Use Zonegate" flag in D'Bridge's editor. It also seems to happen even on messages flagged as Crash or Direct.

    Andrew

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Andrew Leary@1:320/219 to deon on Mon Jan 23 01:50:28 2023
    Hello deon!

    23 Jan 23 00:47, I wrote to you:

    It appears that the version of D'Bridge 4 that Ward is using
    (01-01-2023?) is packing messages as if they were to be sent through a zonegate. The packet header is properly addressed to the destination,
    but the message(s) in the packet are addressed to the zonegate
    address. This appears to happen regardless of whether or not you
    select the "Use Zonegate" flag in D'Bridge's editor. It also seems to happen even on messages flagged as Crash or Direct.

    After further testing, it appears that Direct messages are packed properly with the message header indicating the actual destination. Normal, Crash, and Immediate messages are packed with the message header showing the Zonegate address.

    Andrew

    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Ward Dossche@2:292/854 to Dan Clough on Mon Jan 23 09:00:45 2023
    Dan,

    That is a very good question.

    One which is very easy to answer. It's because you're a cratchety old asshole, through and through.

    I love you too, Dan ... 8-)

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to Nick Andre on Mon Jan 23 09:06:54 2023
    Nick,

    Ward, it does appear to be your system, that is addressing the "packet"
    to Paul at 3:770/1, but the "netmail" inside the packet file, is
    addressed to "2/3".

    Are you connected here and reading?

    This seems to be a D'Bridge bug in that case ...

    Very odd though ... as mail routed via Scott Little arrives at destination ...

    Your opinion please after examining?

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to deon on Mon Jan 23 09:10:44 2023
    deon,

    Sorry, pressed send by mistake:

    I was wrong...
    Ward, I didnt read my dump fully.

    No sweat ... now what I am mystified about is that when I send a message to Paul routed via Scott, it arrives at destination while following the same phylosophy it would have to be sent back ... same as the hundreds of netmails I exchanged with Janis for example.

    Question: can I fabricate a dummy message for Paul to be routed via Scott and send it to you, zipped, to see how it looks there?

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 20:52:06 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Mon Jan 23 2023 09:10 am

    Howdy,

    No sweat ... now what I am mystified about is that when I send a message to Paul routed via Scott, it arrives at destination while following the same phylosophy it would have to be sent back ... same as the hundreds of netmails I exchanged with Janis for example.

    This was the same question that I asked of Paul, but really needs to be asked of Scott. I too am curious why his system is forwarding it on...

    Question: can I fabricate a dummy message for Paul to be routed via Scott and send it to you, zipped, to see how it looks there?

    Yes, sure. I expect it will be the same, but lets confirm...



    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to deon on Mon Jan 23 11:35:49 2023
    Deon,

    This was the same question that I asked of Paul, but really needs to be asked of Scott. I too am curious why his system is forwarding it on...

    Not just that, if a zonegate address becomes part of the game here then why are the hundreds of netmails I have exchanged over the years with other ZCs and out of zone sysops not bouncing?

    Even more interesting ... how come my netmail to you is not sent back with an undeliverable inexistant zonegate address ? Your system also should be sending mails addressed to you back then ...

    Yes, sure. I expect it will be the same, but lets confirm...

    I'm going to do that "in a jiffy" ... 8-)

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Mon Jan 23 22:32:27 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Mon Jan 23 2023 11:35 am

    Howdy,

    Even more interesting ... how come my netmail to you is not sent back with an undeliverable inexistant zonegate address ? Your system also should be sending mails addressed to you back then ...

    Well, lets have some facts before we come to a conclusion. We have confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included or not.

    If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of) and if it doesnt, then we'll go down a different avenue of questions I'm sure :)


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to deon on Mon Jan 23 14:20:10 2023
    Deon,

    Well, lets have some facts before we come to a conclusion. We have
    confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included
    or not.

    If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of)
    and if it doesnt, then we'll go down a different avenue of questions I'm sure :)

    Isn't this exciting? Back to the old days of the pioneers ... :-)

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Ward Dossche@2:292/854 to deon on Mon Jan 23 14:30:46 2023
    Deon,

    Well, lets have some facts before we come to a conclusion. We have
    confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included
    or not.

    When you read this, there should be a file TO-DEON.ZIP in your inbound with a netmail/pkt containing a message addressed to you. At the same time the message has been released as well.

    \%/@rd

    --- DB4 - MidniteSpecial
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Nick Andre@1:229/426 to Ward Dossche on Mon Jan 23 08:04:43 2023
    On 23 Jan 23 09:06:54, Ward Dossche said the following to Nick Andre:

    Are you connected here and reading?

    This seems to be a D'Bridge bug in that case ...

    Answered via Netmail.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Dan Clough@1:123/115 to Ward Dossche on Mon Jan 23 08:06:00 2023
    Ward Dossche wrote to deon <=-

    Well, lets have some facts before we come to a conclusion. We have confirmed why Paul's system is bouncing messages addressed to him (from you), but send me a netmail (in a zip file, so that Synchronet doesnt process it) so that I can validate the same zonegate details are included or not.

    If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of) and if it doesnt, then we'll go down a different avenue of questions I'm sure :)

    Isn't this exciting? Back to the old days of the pioneers ... :-)

    Uh-huh. When can we expect to see your public apology to Paul for being
    a complete dickhead towards him before it became apparent that the fault
    was yours (or at least a bug in the software you are using). It clearly wasn't Paul's fault, and you were shitting all over him.

    When?



    ... He does the work of 3 Men...Moe, Larry & Curly
    === MultiMail/Linux v0.52
    --- SBBSecho 3.20-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Nick Andre@1:229/426 to Ward Dossche on Mon Jan 23 09:35:45 2023
    On 23 Jan 23 09:06:54, Ward Dossche said the following to Nick Andre:

    This seems to be a D'Bridge bug in that case ...

    Fixed.

    Nick

    --- Renegade vY2Ka2
    * Origin: Joey, do you like movies about gladiators? (1:229/426)
  • From Ward Dossche@2:292/854 to Nick Andre on Mon Jan 23 16:43:17 2023
    This seems to be a D'Bridge bug in that case ...

    Fixed.

    Thank you sir. So far the problem didn't propagate anymore ...

    \%/@rd

    --- DB4 - 20220517
    * Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Tue Jan 24 08:07:56 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Mon Jan 23 2023 02:20 pm

    If they are, then Rob who may be watching could reply why sbbs is happily processing it, (perhaps there's another thing that we havent thought of) and if it doesnt, then we'll go down a different avenue of questions I'm sure :)

    Isn't this exciting? Back to the old days of the pioneers ... :-)

    So your netmail to me was "zonegated" - and SBBS imported it.

    I've asked Rob for his comments on it - in they Dove/Synchronet Discussion echo - which I think is gated to Fido, but I dont get it that way...


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to deon on Mon Jan 23 23:00:35 2023
    Deon,

    So your netmail to me was "zonegated" - and SBBS imported it.

    We need more bugs to uncover flaws...

    \%/@rd

    --- DB4 - 20220517
    * Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)
  • From Mike Powell@1:2320/107 to Ward Dossche on Mon Jan 23 16:13:26 2023
    Ward Dossche wrote to Mike Miller <=-

    A "roll". we call it a "roll".

    Ah yes, I was looking for the word but it didn't dawn.

    Nevertheless, crunchy, not soft ...

    Crousant (sp?). Based on the description, I suspect that is what many
    North Americans would call it. Those are, too, sometimes all soft.
    Fancier ones are crisp on the outside, while flakey on the inside.

    If you overbake, or let one sit out too long, they get crunchier inside.


    ... Goodness! That was close! I almost gave a damn.
    --- MultiMail/DOS
    * Origin: possumso.fsxnet.nz * SSH:2122/telnet:24/ftelnet:80 (1:2320/107)
  • From Ward Dossche@2:292/854 to Mike Powell on Tue Jan 24 01:44:23 2023
    Crousant (sp?). Based on the description, I suspect that is what many North Americans would call it. Those are, too, sometimes all soft.
    Fancier ones are crisp on the outside, while flakey on the inside.

    Croissant ... :-) ... it's puff pastry dough ... a thin layer on the outside may be crunchy.

    If you overbake, or let one sit out too long, they get crunchier inside.

    Gotta love that burned campfire-taste.

    Trivia ... during the summer months of July and August there's a mass migration in Europe of tourists to the south ... Spain, Portugal, Italy, Greece, Turkey ... and France.

    Suddenly in the south of France there's an influx of 2 million tourists and bakeries simply cannot keep up with the demand for croissants at breakfast.

    So industrial bakeries in Belgium bake humongous anounts of croissants, every day for 2 months, sometime during the afternoon. they are trucked in a system timed like a Swiss clockwork to brussels airport, containerized and flown to the south of France in 4 freight 747s one to Marseille, one to Nice and the 2 others also go somewhere. They arrive after midnight, are immediately unloaded and the goodies are devived over an army of delivery vans setting off to supermarkets, hotels, restaurant chains etc so that by 8am the vacationers can enjoy a freshly baked typical French croissant.

    \%/@rd

    --- DB4 - 20220517
    * Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)
  • From Paul Hayton@3:770/100 to All on Tue Jan 24 18:03:22 2023
    On 23 Jan 2023 at 09:35a, Nick Andre pondered and said...

    On 23 Jan 23 09:06:54, Ward Dossche said the following to Nick Andre:

    This seems to be a D'Bridge bug in that case ...

    Fixed.

    Hi all.

    I can confirm a netmail from Ward arrived today that was processed without issue. I'll reply to it in a minute. I have made no changes to settings at my end.

    [snip]

    ----------------------- Tue 24 Jan 2023, hpt/lnx 1.9 2022-07-03
    1 Jan:24:2023:02:50:08 Start
    1 Jan:24:2023:02:50:08 Start tossing...
    O Jan:24:2023:02:50:08 Process incoming file /hub/echomail/in/11450021.PKT
    O Jan:24:2023:02:50:08 toss.c:processPkt(): opened '/hub/echomail/in/11450021.tos' ("rb" mode)
    7 Jan:24:2023:02:50:08 pkt: /hub/echomail/in/11450021.tos [2:292/854]
    L Jan:24:2023:02:50:08 Netmail from 2:292/854 to 3:770/100.0
    L Jan:24:2023:02:50:08 Wrote Netmail: 2:292/854.0 -> 3:770/100.0
    4 Jan:24:2023:02:50:08 Statistics:
    4 Jan:24:2023:02:50:08 arc: 0 netMail: 1 echoMail: 0 CC: 0
    4 Jan:24:2023:02:50:08 pkt's: 1 dupe: 0 passthru: 0 exported: 0
    4 Jan:24:2023:02:50:08 msgs: 1 bad: 0 saved: 0 empty: 0
    4 Jan:24:2023:02:50:08 Input: 125.00 mails/sec Output: 0.00 mails/sec
    4 Jan:24:2023:02:50:08 61.77 kb/sec
    4 Jan:24:2023:02:50:08 0.49 kb total, processed in 0.008 seconds
    4 Jan:24:2023:02:50:08 Areas summary:
    4 Jan:24:2023:02:50:08 netmail area NETMAIL - 1 msgs
    1 Jan:24:2023:02:50:08 End tossing
    3 Jan:24:2023:02:50:08 Using importlogfile -> linking only listed Areas
    3 Jan:24:2023:02:50:08 Linking area NETMAIL
    1 Jan:24:2023:02:50:08 End

    ----------------------- Tue 24 Jan 2023, hpt/lnx 1.9 2022-07-03
    1 Jan:24:2023:02:50:09 Start
    1 Jan:24:2023:02:50:09 Start packing...
    4 Jan:24:2023:02:50:09 EchoTossLogFile not found -> Scanning all areas
    4 Jan:24:2023:02:50:09 Scanning NetmailArea NETMAIL
    M Jan:24:2023:02:50:09 pktFile /hub/echomail/out/temp/ce90f400.pkt created for [3:770/100]
    7 Jan:24:2023:02:50:09 Msg from 2:292/854 to 3:770/100 packed via 3:770/100
    L Jan:24:2023:02:50:09 Msg #30 from 2:292/854 to 3:770/100 deleted
    4 Jan:24:2023:02:50:09 Scanning NetmailArea NETMSG
    M Jan:24:2023:02:50:09 packFile /hub/echomail/out/ce90f400.tu0 created for [3:770/100 via 3:770/100]
    O Jan:24:2023:02:50:09 toss.c:arcmail(): opened '/hub/echomail/out/03020064.clo' ("a+" mode)
    7 Jan:24:2023:02:50:09 Packing for 3:770/100 Paul Hayton, ce90f400.pkt > ce90f400.tu0
    6 Jan:24:2023:02:50:09 cmd: zip -9 -j -q /hub/echomail/out/ce90f400.tu0 /hub/echomail/out/temp/ce90f400.pkt
    D Jan:24:2023:02:50:09 Statistics
    D Jan:24:2023:02:50:09 areas: 2 msgs: 29
    D Jan:24:2023:02:50:09 exported: 1
    E Jan:24:2023:02:50:09 Areas summary:
    E Jan:24:2023:02:50:09 netmail area NETMAIL - 1 msgs
    1 Jan:24:2023:02:50:09 End

    ----------------- MUTIL v1.12 A48 2023/01/15 Tue, Jan 24 2023 (loglevel 3)
    + Jan 24 02:50:23 Startup using mailin.ini
    - Jan 24 02:50:23 EXEC FileToss
    - Jan 24 02:50:23 EXEC ImportEchoMail
    + Jan 24 02:50:23 Process: Toss FDN/TIC Files
    + Jan 24 02:50:23 Waiting for BUSY nodes
    + Jan 24 02:50:23 Scanning Hatches
    + Jan 24 02:50:23 Results: 0 import, 0 toss, 0 hatch, 0 bad in 0.00s
    + Jan 24 02:50:23 Process: Importing EchoMail
    + Jan 24 02:50:23 Waiting for BUSY nodes
    ! Jan 24 02:50:23 Import from /bbs/mystic/echomail/in/
    + Jan 24 02:50:23 Extracting ce90f400.tu0
    - Jan 24 02:50:23 Execute Res: 0 Cmd: unzip -oqqjC "/bbs/mystic/echomail/in/ce90f400.tu0" "*.pkt" -d /bbs/mystic/temputil/ > /dev/null 2>&1
    + Jan 24 02:50:23 Importing ce90f400.pkt (3:770/1 to 3:770/100)
    + Jan 24 02:50:23 Netmail from Ward Dossche (2:292/854) to Paul Hayton (3:770/100)
    + Jan 24 02:50:23 Results: 0 echo, 1 net, 0 dupes, 0 tossed in 0.12s
    + Jan 24 02:50:23 Shutdown Normal (0)

    [snip]

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Ward Dossche@2:292/854 to Paul Hayton on Tue Jan 24 10:12:55 2023
    I can confirm a netmail from Ward arrived today that was processed
    without issue. I'll reply to it in a minute. I have made no changes to settings at my end.

    And the reply got here as well. Seems there was an issue in D'Bridge which got dealt with rather immediately.

    My appologies, Paul, for getting you upset ... the problem was elsewhere than what I expected.

    \%/@rd

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Wilfred van Velzen@2:280/464 to Ward Dossche on Tue Jan 24 10:18:39 2023
    Hi Ward,

    On 2023-01-24 10:12:55, you wrote to Paul Hayton:

    I can confirm a netmail from Ward arrived today that was processed
    without issue. I'll reply to it in a minute. I have made no changes
    to settings at my end.

    And the reply got here as well. Seems there was an issue in D'Bridge which got dealt with rather immediately.

    My appologies, Paul, for getting you upset ... the problem was elsewhere than what I expected.

    We also found out that HPT seems to processes netmail differently than other tossers. It seems to prevail the data in the message header over that in the INTL kludge line. If either is more correct than the other I don't know. And how do zonegates factor in to this?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to All on Tue Jan 24 10:54:45 2023
    Hi,

    On 2023-01-24 10:18:39, I wrote to you:

    We also found out that HPT seems to processes netmail differently
    than other tossers. It seems to prevail the data in the message
    header over that in the INTL kludge line. If either is more correct
    than the other I don't know. And how do zonegates factor in to this?

    In FTS-4001.001 it says:

    5. INTL
    -------

    The INTL control paragraph shall be used to give information aboutthe zone numbers of the original sender and the ultimate
    addressee of a message.

    Notice the 'ultimate addressee'. Since the message already arrived in Z3 on Paul's system and Paul's system probably knows were to route/deliver mail for Z3 nodes. The address in the header (of the zonegate) shouldn't be used over the ultimate destination address in the INTL kludge. So in my opinion the behaviour of HPT is wrong here.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From deon@3:633/509 to Wilfred van Velzen on Tue Jan 24 21:22:00 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to Ward Dossche on Tue Jan 24 2023 10:18 am

    We also found out that HPT seems to processes netmail differently than other tossers. It seems to prevail the data in the message header over that in the INTL kludge line. If either is more correct than the other I don't know. And how do zonegates factor in to this?

    It does seem that developers have their own interpretation of how a packet (netmail one at least) gets processed and routed.

    I was going to refresh my memory from the standards, but it seems that ftsc.org has not been renewed and now replaced by a common parked page?


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From deon@3:633/509 to Wilfred van Velzen on Tue Jan 24 21:24:59 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to All on Tue Jan 24 2023 10:54 am

    The INTL control paragraph shall be used to give information aboutthe zone numbers of the original sender and the ultimate
    addressee of a message.

    Notice the 'ultimate addressee'. Since the message already arrived in Z3 on Paul's system and Paul's system probably knows were to route/deliver mail for Z3 nodes. The address in the header (of the zonegate) shouldn't be used over the ultimate destination address in the INTL kludge. So in my opinion the behaviour of HPT is wrong here.

    But what is the responsibilty of the destination address in the packed message header?

    Since the wording is "shall be used to give information", and not "must be used to determine routing" its not definitive in my mind.



    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Wilfred van Velzen@2:280/464 to deon on Tue Jan 24 11:45:58 2023
    * Originally in FN_SYSOP
    * Crossposted in FTSC_PUBLIC

    Hi deon,

    On 2023-01-24 21:22:00, you wrote to me:

    I was going to refresh my memory from the standards, but it seems that ftsc.org has not been renewed and now replaced by a common parked
    page?

    Something seems wrong indeed. I get a blank page, but that is because my add blockers filter out all the sh*t. ;-)
    When I look at the source I indeed see a lot of javascript and some 'parking-lander' urls...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to deon on Tue Jan 24 11:49:59 2023
    Hi deon,

    On 2023-01-24 21:24:59, you wrote to me:

    The INTL control paragraph shall be used to give information aboutthe
    zone numbers of the original sender and the ultimate
    addressee of a message.

    Notice the 'ultimate addressee'. Since the message already arrived in Z3
    on Paul's system and Paul's system probably knows were to route/deliver
    mail for Z3 nodes. The address in the header (of the zonegate) shouldn't
    be used over the ultimate destination address in the INTL kludge. So in
    my opinion the behaviour of HPT is wrong here.

    But what is the responsibilty of the destination address in the packed message header?

    Since the wording is "shall be used to give information", and not "must be used to determine routing" its not definitive in my mind.

    That just refers to the _addition_ of the INTL kludge which is not mandatory (I think). But when it's present there is no reason not to use it as intended...

    It's just stupid when the INTL kludge shows the message is destined for your system (as the ultimate destination by defintion) to forward it to the address in the header.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From deon@3:633/509 to Wilfred van Velzen on Tue Jan 24 22:45:57 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to deon on Tue Jan 24 2023 11:49 am

    That just refers to the _addition_ of the INTL kludge which is not mandatory (I think). But when it's present there is no reason not to use it as intended...

    It's just stupid when the INTL kludge shows the message is destined for your system (as the ultimate destination by defintion) to forward it to the address in the header.

    True.

    But I also think that the 'router' should "route" it to the correct destination in the first place.

    So if the sender intended it to go to a zone gate (or some other system for "special processing" - and by definition in the current zone), then the packed message header could be used to indicate that.

    But if it is intended to processed by the destination system (ie: the address in the INTL kludge) then the packed message header should have that address in it.

    Otherwise, why have a destination in the packed message header? Make it nulls, especially if intermediate systems are not going to look at it anyway, or rather are only going to look at it if an INTL kludge isnt present.


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Wilfred van Velzen@2:280/464 to deon on Tue Jan 24 13:31:19 2023
    Hi deon,

    On 2023-01-24 22:45:57, you wrote to me:

    That just refers to the _addition_ of the INTL kludge which is not
    mandatory (I think). But when it's present there is no reason not to
    use it as intended...

    It's just stupid when the INTL kludge shows the message is destined for
    your system (as the ultimate destination by defintion) to forward it to
    the address in the header.

    True.

    But I also think that the 'router' should "route" it to the correct destination in the first place.

    True but that was a different matter and a (fixed) bug in d'Bridge.

    So if the sender intended it to go to a zone gate (or some other
    system for "special processing" - and by definition in the current
    zone), then the packed message header could be used to indicate that.

    That is how it should be done as I understand it. (But Ward's system, because of the bug, didn't route it to the (non existent) zonegate.)

    But if it is intended to processed by the destination system (ie: the address in the INTL kludge) then the packed message header should have that
    address in it.

    That's the case for non gated messages (normally).

    Otherwise, why have a destination in the packed message header? Make
    it nulls, especially if intermediate systems are not going to look at
    it anyway, or rather are only going to look at it if an INTL kludge
    isnt present.

    It's more redundant to also fill the message header fields with the destination address, just in case there is very old software on the route, that doesn't know about INTL kludges. And it's probably against the standards to put nulls in the message header for the destination address.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Ward Dossche@2:292/854 to deon on Tue Jan 24 13:39:18 2023
    Deon,

    I was going to refresh my memory from the standards, but it seems that ftsc.org has not been renewed and now replaced by a common parked page?

    Ahhhhhh ....

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Wilfred van Velzen on Wed Jan 25 00:13:10 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to deon on Tue Jan 24 2023 01:31 pm

    But I also think that the 'router' should "route" it to the correct destination in the first place.

    True but that was a different matter and a (fixed) bug in d'Bridge.

    I get that - so putting that case aside, the "purpose" of the packed message header, especially the destination address...

    It's more redundant to also fill the message header fields with the destination address, just in case there is very old software on the route, that doesn't know about INTL kludges. And it's probably against the standards to put nulls in the message header for the destination address.

    I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists). I generally dont like filling stuff in, if its not intended to be used - perhaps that's just me.

    What is clear though, the standard must be vague, given more than 1 software developer has implemented a different process logic for processing netmails with those fields filled. (And hence why some of Ward's messages were being processed and delivered, and some were being sent on somewhere else to be delivered - but failed.)

    I would normally say, lets get it clear and fixed up - but then that normally leads to a different discussion that normally doesnt end well :(


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alan Ianson@1:153/757.2 to Wilfred van Velzen on Tue Jan 24 05:40:03 2023
    Hello Wilfred,

    Notice the 'ultimate addressee'. Since the message already arrived in
    Z3 on Paul's system and Paul's system probably knows were to
    route/deliver mail for Z3 nodes. The address in the header (of the zonegate) shouldn't be used over the ultimate destination address in
    the INTL kludge. So in my opinion the behaviour of HPT is wrong here.

    When you input bad information you get bad results. I can't call hpt wrong because it followed the information it was given in the header, where one would expect to find the needed information.

    Ttyl :-),
    Al

    ... Luxuriantly hand-crafted from only the finest ASCII.
    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Wilfred van Velzen@2:280/464 to Alan Ianson on Tue Jan 24 15:18:16 2023
    Hi Alan,

    On 2023-01-24 05:40:03, you wrote to me:

    Notice the 'ultimate addressee'. Since the message already arrived in
    Z3 on Paul's system and Paul's system probably knows were to
    route/deliver mail for Z3 nodes. The address in the header (of the
    zonegate) shouldn't be used over the ultimate destination address in
    the INTL kludge. So in my opinion the behaviour of HPT is wrong here.

    When you input bad information you get bad results. I can't call hpt wrong because it followed the information it was given in the header, where one would expect to find the needed information.

    No you have to consider both the header destination and INTL kludge destination before making the decision where to route or deliver (locally) the message.

    But if the ultimate destination in the INTL kludge is the local system, there is no need to even look at what is in the header.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757.2 to Wilfred van Velzen on Tue Jan 24 06:28:47 2023
    Hello Wilfred,

    No you have to consider both the header destination and INTL kludge destination before making the decision where to route or deliver
    (locally) the message.

    The address in the header is standard and INTL kludges are not.

    But if the ultimate destination in the INTL kludge is the local
    system, there is no need to even look at what is in the header.

    So close, an yet so far.

    Ttyl :-),
    Al

    ... Conscience gets a lot of credit that belongs to cold feet
    --- GoldED+/LNX 1.1.5-b20220504
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Kurt Weiske@1:218/700 to Mike Powell on Tue Jan 24 06:55:00 2023
    Mike Powell wrote to Ward Dossche <=-

    A "roll". we call it a "roll".

    Ah yes, I was looking for the word but it didn't dawn.

    Nevertheless, crunchy, not soft ...

    Crousant (sp?). Based on the description, I suspect that is what many North Americans would call it. Those are, too, sometimes all soft. Fancier ones are crisp on the outside, while flakey on the inside.


    We're going down a baking rabbit hole, love it!

    A croissant is pastry dough, flattened like puff pastry dough and rolled
    into a triangular shape. What we call a crescent roll in the USA is
    typically bread dough flattened and rolled. The original poster was
    referring to a dinner roll, a one piece (not sliced) baked good made
    with bread dough, usually with butter added to make a flakier bread.

    Rolls are plain ol' bread dough.



    ... "We can't stop here, this is bat country."
    --- MultiMail/Win v0.52
    * Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)
  • From Kurt Weiske@1:218/700 to Ward Dossche on Tue Jan 24 06:57:00 2023
    Ward Dossche wrote to Mike Powell <=-

    If you overbake, or let one sit out too long, they get crunchier inside.

    Gotta love that burned campfire-taste.

    Crusteaz brand biscuit dough only needs water - makes great camping drop biscuits if you have a grill or a pan with you.

    Trivia ... during the summer months of July and August there's a mass migration in Europe of tourists to the south ... Spain, Portugal,
    Italy, Greece, Turkey ... and France.

    The only time I got to go to Paris was in August, and the town was
    empty. Can confirm.

    Suddenly in the south of France there's an influx of 2 million tourists and bakeries simply cannot keep up with the demand for croissants at breakfast.

    So industrial bakeries in Belgium bake humongous anounts of croissants, every day for 2 months, sometime during the afternoon. they are trucked
    in a system timed like a Swiss clockwork to brussels airport, containerized and flown to the south of France in 4 freight 747s one to Marseille, one to Nice and the 2 others also go somewhere. They arrive after midnight, are immediately unloaded and the goodies are devived
    over an army of delivery vans setting off to supermarkets, hotels, restaurant chains etc so that by 8am the vacationers can enjoy a
    freshly baked typical French croissant.

    But, Croissants only come from the Croissant valley in France -
    otherwise, they're sparkling dinner rolls.



    ... When in doubt, predict that the trend will continue.
    --- MultiMail/Win v0.52
    * Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)
  • From Wilfred van Velzen@2:280/464 to Alan Ianson on Tue Jan 24 16:03:20 2023
    Hi Alan,

    On 2023-01-24 06:28:47, you wrote to me:

    No you have to consider both the header destination and INTL kludge
    destination before making the decision where to route or deliver
    (locally) the message.

    The address in the header is standard and INTL kludges are not.

    INTL kludges are described in FTS-4001, that's a standard!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to deon on Tue Jan 24 16:15:18 2023


    Hi deon,

    On 2023-01-25 00:13:10, you wrote to me:

    It's more redundant to also fill the message header fields with the
    destination address, just in case there is very old software on the
    route, that doesn't know about INTL kludges. And it's probably against
    the standards to put nulls in the message header for the destination
    address.

    I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).

    Non of the FTSC documents say that.

    I generally dont like filling stuff in, if its not intended to be used
    - perhaps that's just me.

    FTS-0001 is quite clear about what is supposed to be in the packed message header.

    What is clear though, the standard must be vague, given more than 1 software developer has implemented a different process logic for processing
    netmails with those fields filled. (And hence why some of Ward's messages were being processed and delivered, and some were being sent on somewhere else to be delivered - but failed.)

    There can be different reasons for this, but there is room for clarification in the documents. ;-)

    I would normally say, lets get it clear and fixed up - but then that normally leads to a different discussion that normally doesnt end well :(

    There is currently an election on going for FTSC standing members, maybe you should apply? ;-)


    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Ward Dossche@2:292/854 to deon on Tue Jan 24 16:12:15 2023
    Deon,

    So if the sender intended it to go to a zone gate (or some other system
    for "special processing" - and by definition in the current zone), then
    the packed message header could be used to indicate that.

    There are no zonegates.

    \%/@rd

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Wilfred van Velzen on Wed Jan 25 08:34:56 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to deon on Tue Jan 24 2023 04:15 pm

    I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).

    Non of the FTSC documents say that.

    So I was going to re-view the standard (but the website is down). Does it say ignore the packed message header and use INTL if it exists instead?

    FTS-0001 is quite clear about what is supposed to be in the packed message header.

    I agree - but we have a differing view point on when it should be used :(

    There is currently an election on going for FTSC standing members, maybe you should apply? ;-)

    I was there once - I'm struggling with many projects and not enough arms and legs, and I dont want to give it a half baked effort. There are other reasons to, but they dont need to be public. I'll mull it over though...


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From deon@3:633/509 to Ward Dossche on Wed Jan 25 08:37:19 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Tue Jan 24 2023 04:12 pm

    So if the sender intended it to go to a zone gate (or some other system for "special processing" - and by definition in the current zone), then the packed message header could be used to indicate that.

    There are no zonegates.

    I know, there was once - so the design was setup to use them right? I dont know if the design has been "revised" since they are no longer in used. (I couldnt go and validate).

    That said, that functionality might be usable for other purposes (dont have any in mind at the moment), but not if tosser processing doesnt support it.


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Ward Dossche@2:292/854 to deon on Wed Jan 25 00:47:27 2023
    Deon,

    I know, there was once - so the design was setup to use them right? I
    dont know if the design has been "revised" since they are no longer in
    used. (I couldnt go and validate).

    Actually, in a properly set-up system a netmail addressed to a zonegate should be bounced by a tracker as those addresses don't exist.

    If a person has no tracker installed, that person should not even process in-transit netmail.

    \%/@rd

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From deon@3:633/509 to Ward Dossche on Wed Jan 25 11:06:00 2023
    Re: Re: Problem at your system
    By: Ward Dossche to deon on Wed Jan 25 2023 12:47 am

    Howdy,

    Actually, in a properly set-up system a netmail addressed to a zonegate should be bounced by a tracker as those addresses don't exist.

    If a person has no tracker installed, that person should not even process in-transit netmail.

    Do we know if that actually works too?

    In the netmails you sent via Scott, his via lines show a tracker?

    @Via: 2:292/854@Ward_Dossche @20230122.111359.UTC O/T-Track+ 2.85
    @Via: 3:712/848 @20230122.111702.UTC RNtrack 1.21/W32
    @Via: 3:712/848 @20230122.111703.UTC hpt/w32-mvcdll 1.9.0-cur 04-11-15
    @Via: 3:770/1 @20230122.111858.UTC hpt/lnx 1.9 2022-07-03

    (I dont know what RNtrack is, but I'm assuming that is a "tracker"?)

    Is yours a tracker too? (O/T-Track+) if so, shouldnt that have stopped it? (Dont know what O/T-Track+ is either...)

    And yes, Scott's via lines show hpt is involved, so perhaps the RNtrack re-packaged the mail so hpt could forward it on (since we know Paul's hpt did something different when the packed message header had a different destination).


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Tue Jan 24 16:25:50 2023
    No you have to consider both the header destination and INTL kludge
    destination before making the decision where to route or deliver
    (locally) the message.

    The address in the header is standard and INTL kludges are not.

    INTL kludges are described in FTS-4001, that's a standard!

    Yes, but they may or may not be present.

    The error here is that the packet header was incorrect. That header should indicate the destination of the message if INTL kludges are present or not.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Tue Jan 24 16:27:10 2023
    I would normally say, lets get it clear and fixed up - but then that
    normally leads to a different discussion that normally doesnt end well :(

    There is currently an election on going for FTSC standing members, maybe you should apply? ;-)

    Deon is, or was an FTSC member at one time.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From deon@3:633/509 to Wilfred van Velzen on Wed Jan 25 11:29:16 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to deon on Tue Jan 24 2023 04:15 pm

    Howdy,

    I'm not sure it would be against a standard to put nulls in a field that a standard would describe "dont use in this case" (and in this particular scenario, I think we are talking about if an INTL kludge exists).

    Non of the FTSC documents say that.

    Actually, I think they do. Just found a copy of FTS-0001.016 (1995) and there are several references to fields being null if not used:

    serialNo (* binary serial number (otherwise null)*)
    password (* session password (otherwise null) *)
    origZone (* zone of pkt sender (otherwise null) *)
    destZone (* zone of pkt receiver (otherwise null)*)

    So the concept of using null if a field is not used has been set.


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Wilfred van Velzen@2:280/464 to Alan Ianson on Wed Jan 25 08:27:39 2023
    Hi Alan,

    On 2023-01-24 16:25:50, you wrote to me:

    The address in the header is standard and INTL kludges are not.

    INTL kludges are described in FTS-4001, that's a standard!

    Yes, but they may or may not be present.

    The error here is that the packet header was incorrect. That header should indicate the destination of the message if INTL kludges are present or not.

    Yes but they should be handled differently if the INTL kludge is present.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to deon on Wed Jan 25 08:31:21 2023
    Hi deon,

    On 2023-01-25 11:29:16, you wrote to me:

    I'm not sure it would be against a standard to put nulls in a
    field
    that a standard would describe "dont use in this case" (and in this
    particular scenario, I think we are talking about if an INTL kludge
    exists).

    Non of the FTSC documents say that.

    Actually, I think they do. Just found a copy of FTS-0001.016 (1995) and there are several references to fields being null if not used:

    serialNo (* binary serial number (otherwise null)*)
    password (* session password (otherwise null) *)
    origZone (* zone of pkt sender (otherwise null) *)
    destZone (* zone of pkt receiver (otherwise null)*)

    So the concept of using null if a field is not used has been set.

    Indeed, and it doesn't say so for any of the node and net fields in the pkt and message header. So null is not an option for those.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Paul Hayton@3:770/100 to Ward Dossche on Thu Jan 26 12:13:51 2023
    On 24 Jan 2023 at 10:12a, Ward Dossche pondered and said...

    I can confirm a netmail from Ward arrived today that was processed without issue. I'll reply to it in a minute. I have made no changes to settings at my end.

    And the reply got here as well. Seems there was an issue in D'Bridge
    which got dealt with rather immediately.

    My appologies, Paul, for getting you upset ... the problem was elsewhere than what I expected.

    Thank you Ward.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Mike Powell@1:2320/107 to Ward Dossche on Wed Jan 25 16:53:05 2023
    Ward Dossche wrote to Mike Powell <=-

    So industrial bakeries in Belgium bake humongous anounts of croissants, every day for 2 months, sometime during the afternoon. they are trucked
    in a system timed like a Swiss clockwork to brussels airport, containerized and flown to the south of France in 4 freight 747s one to Marseille, one to Nice and the 2 others also go somewhere. They arrive after midnight, are immediately unloaded and the goodies are devived
    over an army of delivery vans setting off to supermarkets, hotels, restaurant chains etc so that by 8am the vacationers can enjoy a
    freshly baked typical French croissant.

    And none the wiser, unless they know what you know. :)

    Mike


    ... Spelling is a sober man's game
    --- MultiMail/DOS
    * Origin: possumso.fsxnet.nz * SSH:2122/telnet:24/ftelnet:80 (1:2320/107)
  • From Ward Dossche@2:292/854 to Mike Powell on Thu Jan 26 02:19:54 2023
    ... so that by 8am the vacationers can enjoy a
    freshly baked typical French croissant.

    And none the wiser, unless they know what you know. :)

    As with so many other things in Life ... 8-)

    * The US is boycotting products from Russia
    * Russia delivers oil to Europe
    * In the refinery part of the Antwerp harbor JETA1 fuel is produced from
    Russian oil
    * Every week two 75.000 tonnes fuel tankships leave from here for North
    America to deliver jetfuel for JFK and EWR airports

    8-)

    \%/@rd

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Wilfred van Velzen@2:280/464 to deon on Thu Jan 26 16:15:18 2023


    Hi deon,

    On 2023-01-25 08:34:56, you wrote to me:

    I'm not sure it would be against a standard to put nulls in a
    field
    that a standard would describe "dont use in this case" (and in this
    particular scenario, I think we are talking about if an INTL kludge
    exists).

    Non of the FTSC documents say that.

    So I was going to re-view the standard (but the website is down).

    It's up again. ;)

    Does it say ignore the packed message header and use INTL if it exists instead?

    It doesn't say either way, if anything at all about how to apply the INTL kludge in conjuction with the message header fields. You should consider the INTL kludge was "invented", when zones (and zone gates) were introduced in fidonet, and they needed a way to sent netmail to other zones. Since the message header doesn't contain zone information.

    So FTS-0001 just says:

    o INTL <dest z:n/n> <orig z:n/n> - used for inter-zone address

    FTS-0004 doesn't say much more.

    So we are left with common sense and logic, how to apply them. ;-)
    And it's not logical to forward a routed netmail to a zone-gate when it has already arrived at it's ultimate destination! Or has arrived in the destination zone.

    And if you apply the reality of the modern fidonet, without zone-gates. You could just ignore the message header fields, if an INTL kludge is present.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Thu Jan 26 14:26:14 2023
    So we are left with common sense and logic, how to apply them. ;-)

    Common sense and logic dictates that the address in the header is correct.

    I am not against the INTL kludge. I like the INTL kludge as kludges go but the address in the header serves a purpose, and it should be correct.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Wilfred van Velzen@2:280/464 to Alan Ianson on Thu Jan 26 23:48:03 2023
    Hi Alan,

    On 2023-01-26 14:26:14, you wrote to me:

    So we are left with common sense and logic, how to apply them. ;-)

    Common sense and logic dictates that the address in the header is correct.

    I am not against the INTL kludge. I like the INTL kludge as kludges go but the address in the header serves a purpose, and it should be correct.

    The header doesn't contain the zone for the destination, so what is in the header is by definition incomplete, so it can't be the only source for the destination of the message, so you need what is in the INTL kludge, to be able to route a netmail.
    (Except when there is no INTL kludge, then the destination is in the same zone as the origin address, and it should never leave the zone. But I think such netmails haven't existed for at least 3 decades in fidonet)

    Further the only known use case, where the header and INTL kludge contain a different address is when the message is sent to a zone-gate in the same zone as the sender.
    1) Zone-gates are no longer used, or even exist. So something is wrong, and the message shouldn't be forwarded to a non existent address when the address in the INTL kludge does exist, and is even the local system.
    2) When the message is already outside of the zone of the sender, it's not logical to send it back to the zone-gate in the zone of the sender.


    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757 to Wilfred van Velzen on Thu Jan 26 15:20:34 2023
    Common sense and logic dictates that the address in the header is correct.

    I am not against the INTL kludge. I like the INTL kludge as kludges go but >> the address in the header serves a purpose, and it should be correct.

    The header doesn't contain the zone for the destination, so what is in the header is by definition incomplete, so it can't be the only source for the destination of the message, so you need what is in the INTL kludge, to be able to route a netmail.

    Sure, that is all true and always has been.

    What I am saying is that the address in the header should be correct, no?

    Question: When FMail sends a netmail out with the INTL kludges what address does it put in the header? Why?

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From deon@3:633/509 to Wilfred van Velzen on Fri Jan 27 10:20:36 2023
    Re: Re: Problem at your system
    By: Wilfred van Velzen to deon on Thu Jan 26 2023 04:15 pm

    So we are left with common sense and logic, how to apply them. ;-)
    And it's not logical to forward a routed netmail to a zone-gate when it has already arrived at it's ultimate destination! Or has arrived in the destination zone.

    And if you apply the reality of the modern fidonet, without zone-gates. You could just ignore the message header fields, if an INTL kludge is present.

    Sorry, we can't go from "its not mentioned so you can't do that", to "its not mentioned so you need to use (my understanding of) common sense". I'd argue that the common sense is to follow the instructions in the packed message header as it was designed in FTS-0001.

    But reading FTS-4001 - it states the purpose of the INTL kludge:

    "The INTL control paragraph shall be used to give information about the zone numbers of the original sender and the ultimate addressee of a message."

    This is a confusing sentence in English, because I can read it as "zone numbers of the sender and recipient", or I can read it as "zone number of the sender and address of the recipient". I believe the intention was the former, although I can see how some folks may argue for the later.

    And further it mentions

    "This gives both the originating system and the destination system as well as any intermediate routing systems unambiguous zone information even in a situation where one system may be active in a number of different (possibly non-FidoNet) zones."

    (Hence why I believe it is the former intention above.)

    It does not say, the address in the INTL kludge should be used for routing (outside of determining the ultimate destination zone), nor being authoritative that the address is to me, or a system I know.

    Certainly, I agree that could be a "short cut" (after all we do like to take short cuts), if the function of a system to do special processing (eg: a zone gate) is to be bypassed. (And yes I know there are no defined ones at the moment/anymore.)

    We have to remember that processing power back in the 90s was much less than it was today, and the goal (especially for hubs) was to process mail quickly.

    Parsing a binary object, looking at a packet header to confirm that a packet is destined to me, is a quick way to see if I should process the rest of the contents. I have many packets in my inbound that have been rejected because somebody having a bad config and my tosser ignoring them "not to us". (Should my tosser have processed the contents anyway?)

    If the packet is to us, its easy to identify packed messages (enclosed between 0x02 0x00 and the 4th 0x00 after 0x0e chars.) If the destination in the packed header message is not my 2D, forward the whole data to the next system in the path to that 2D destination. I do agree, now that there are no zonegates that 2D address is probably always the recipients 2D.

    If the packed message header is me, then import the message that I've just read.

    The only difference was a zone gate, who would recognised the {srczone}/{dsgzone} syntax in the packed message header and then look for the string INTL and the string contents, probably convert them to integers, and determine the next destination zone and route it appropriately (after repacking it with update headers). (I don't think a zonegate had any reason to import messages?). A more expensive processing activity that a general hub wouldn't have needed to do.

    So, since Scotts system correctly forwarded the message onto Paul, and Scott is Z3C, I can only assume is RNTrack did that (since he is logically the right person to run with address 2/3)? Paul's didn't, because he has no reason to run with that address. And while zonegates are no longer in use, only he can answer why his system correctly forwarded on the message. We know why Paul's didn't.

    So as this network has evolved, and processing power has got faster, its no longer an issue for every system to read a message fully and do what it thinks it should do to an incoming mail packet (there are less of them too as well). If we are going to change the "accepted way" of doing that, we should revise those documents - and perhaps even update the packet format, since the packed header source and destination are irrelevant if we are to depend on an INTL kludge.

    I'll get some popcorn now...


    ...лоеп
    --- SBBSecho 3.15-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Mike Powell@1:2320/107 to Ward Dossche on Thu Jan 26 16:15:38 2023
    Ward Dossche wrote to Mike Powell <=-

    And none the wiser, unless they know what you know. :)

    As with so many other things in Life ... 8-)

    * The US is boycotting products from Russia
    * Russia delivers oil to Europe
    * In the refinery part of the Antwerp harbor JETA1 fuel is produced
    from
    Russian oil
    * Every week two 75.000 tonnes fuel tankships leave from here for North
    America to deliver jetfuel for JFK and EWR airports

    Yeah, over here there has been some skepticism regarding how much we are
    really boycotting Russian products. ;)



    ... Tell me, is something eluding you, Sunshine?
    --- MultiMail/DOS
    * Origin: possumso.fsxnet.nz * SSH:2122/telnet:24/ftelnet:80 (1:2320/107)
  • From Ward Dossche@2:292/854 to Wilfred van Velzen on Fri Jan 27 01:17:54 2023
    Wilfred,

    1) Zone-gates are no longer used, or even exist. So something is wrong,
    and the message shouldn't be forwarded to a non existent address when the address in the INTL kludge does exist, and is even the local system.
    2) When the message is already outside of the zone of the sender, it's
    not logical to send it back to the zone-gate in the zone of the sender.

    The time-stamp and the INTL-kludge were also changed..

    \%/@rd

    --- DB4 - 20220519
    * Origin: Many Glacier - Preserve / Protect / Conserve (2:292/854)
  • From Wilfred van Velzen@2:280/464 to Ward Dossche on Fri Jan 27 02:00:04 2023
    Hi Ward,

    On 2023-01-27 01:17:54, you wrote to me:

    1) Zone-gates are no longer used, or even exist. So something is
    wrong,
    and the message shouldn't be forwarded to a non existent address when
    the address in the INTL kludge does exist, and is even the local
    system. 2) When the message is already outside of the zone of the
    sender, it's not logical to send it back to the zone-gate in the zone
    of the sender.

    The time-stamp and the INTL-kludge were also changed..

    If that's so, then there are 2 other bugs in hpt... There's no reason to ever change those on in transit netmails.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.5.2-B20230114
    * Origin: FMail development HQ (2:280/464)