• makenl sbbsecho and netmail and routing issue

    From Ragnarok@1:103/705 to DOVE-Net.Synchronet_Discussion on Sun Oct 3 23:06:20 2021
    Hi all i working on makenl to create a nodelist updates for 39:943

    the tool generate a simple netmail to send the generated file this is
    the fmsgdump output:

    root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -ctrl -body 1.msg
    fmsgdump rev 3.6 - Dump FidoNet Stored Messages

    Opening 1.msg
    Subj: /sbbs/fido/makenl/out/net.943
    Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
    To : Coordinator (39:943/100.0)
    From: MakeNL 3.5.1 (39:943/0.0)
    Time: 03 Oct 21 01:41:01

    -start of message text-
    @MSGID: 39:943/0 615908bc
    -end of message text-

    I move that file to netmail directory on sbbs for sbbsecho procesing.

    I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    so this was ruoted via 4:* (zone was rewrite)

    2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject:
    /sbbs/fido/makenl/out/net.943
    2021-10-03 22:42:03 Routing NetMail (1.msg) to 4:90/1
    2021-10-03 22:42:03 Node (4:90/1) successfully locked via: /sbbs/fido/outbound/005a0001.bsy
    2021-10-03 22:42:03 File (/sbbs/fido/makenl/out/net.943, 0.6KB) for
    4:90/1 added to BSO/FLO file: /sbbs/fido/outbound/005a0001.flo
    2021-10-03 22:42:03 Adding NetMail (1.msg) to new packet for 4:90/1: /sbbs/fido/outbound/005a0001.out
    2021-10-03 22:42:03 Deleting /sbbs/fido/netmail/1.msg (from line 5311)

    I suspect that my sbbsecho settings are wrong somewhere

    I have 39:943/0 and 39:943/1 as my sbbs akas

    my zone 39:xx links are:

    39:90/0 my boss. i poll it via binkit,and set local AKA to 39:943/0
    39:ALL , set local aka to 39:943/0 and Route To 39:90/0
    39:943/100 the test node to i want to receive the netmail

    What option can I have wrongly configured that affects this?

    thanks!

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Wilfred van Velzen@2:280/464 to Ragnarok on Mon Oct 4 09:54:42 2021
    Hi Ragnarok,

    On 2021-10-03 23:06:20, you wrote to DOVE-Net.Synchronet_Discussion:

    my zone 39:xx links are:

    39:ALL , set local aka to 39:943/0 and Route To 39:90/0

    I don't know how synchronet works, so maybe this is "automatic", but I think there should be an exception for this route:

    39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those messages back immediately, and a loop is born...


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ragnarok@1:103/705 to Wilfred van Velzen on Mon Oct 4 13:18:16 2021
    El 4/10/21 a las 04:54, Wilfred van Velzen escribió:
    Hi Ragnarok,

    On 2021-10-03 23:06:20, you wrote to DOVE-Net.Synchronet_Discussion:

    Ra> my zone 39:xx links are:

    Ra> 39:ALL , set local aka to 39:943/0 and Route To 39:90/0

    I don't know how synchronet works, so maybe this is "automatic", but I think there should be an exception for this route:

    39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those messages back immediately, and a loop is born...

    Hi Wilfred! i don't route 39:943/all to 39:90/0

    I try to use same logic as another network nodes that i have working ex:

    my aka (ex micronet) 618:500/45

    sbbsecho entries:

    618:500/1 (mi boss)
    618:ALL route to 618:500/1

    this abobe example just working

    now, for the z39 i have:

    39:90/0 my boss -> your node :)
    39:ALL route to 39:90/0
    39:943/100 (my downlink node for testing)

    this abobe work echomail and netmail from sbbs.
    the issue is with this netmail that i copy from makenl to sbbs
    the fmsgdump show normal.
    I can not understand why the zone was changed from 39: to 4: at sbbsecho importing acction, i pretty shure that DigitalMan have the magic
    explanation =)

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Wilfred van Velzen@2:280/464 to Ragnarok on Mon Oct 4 20:27:08 2021
    Hi Ragnarok,

    On 2021-10-04 13:18:16, you wrote to me:

    I don't know how synchronet works, so maybe this is "automatic", but I
    think there should be an exception for this route:

    39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those
    messages back immediately, and a loop is born...

    Hi Wilfred! i don't route 39:943/all to 39:90/0

    You shouldn't but it seems you do!?

    now, for the z39 i have:

    39:90/0 my boss -> your node :)
    39:ALL route to 39:90/0
    39:943/100 (my downlink node for testing)

    There is no "39:943/all no route"...?

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Ragnarok on Mon Oct 4 22:34:30 2021
    Hi Ragnarok,

    On 2021-10-04 20:27:08, I wrote to you:

    I don't know how synchronet works, so maybe this is "automatic", but I
    think there should be an exception for this route:

    39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those
    messages back immediately, and a loop is born...

    Hi Wilfred! i don't route 39:943/all to 39:90/0

    You shouldn't but it seems you do!?

    now, for the z39 i have:

    39:90/0 my boss -> your node :)
    39:ALL route to 39:90/0
    39:943/100 (my downlink node for testing)

    There is no "39:943/all no route"...?

    What I was afraid of, is happening. I sent a test netmail to the none existing node 39:943/999, and this is what happend:

    From the latest "bouncing" version of the netmail, when I caught it:

    Via 39:943/0 @20211004.192054.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.192210.843.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.192253.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.192421.250.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.192654.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.192827.694.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.193102.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.193159.285.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.193458.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.193621.548.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.193859.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.194045.768.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.194358.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.194521.068.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.194558.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.194716.218.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.194959.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.195125.831.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.195358.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.195517.289.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.195759.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.195925.747.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.200159.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.200319.518.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.200619.UTC SBBSecho 3.14-Linux master/6722f2783
    Via 39:90/0 @20211004.200740.613.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815
    Via 39:943/0 @20211004.201019.UTC SBBSecho 3.14-Linux master/6722f2783


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Digital Man@1:103/705 to Ragnarok on Mon Oct 4 19:06:36 2021
    Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to DOVE-Net.Synchronet_Discussion on Sun Oct 03 2021 11:06 pm

    Hi all i working on makenl to create a nodelist updates for 39:943

    the tool generate a simple netmail to send the generated file this is
    the fmsgdump output:

    root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -ctrl -body 1.msg
    fmsgdump rev 3.6 - Dump FidoNet Stored Messages

    Opening 1.msg
    Subj: /sbbs/fido/makenl/out/net.943
    Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
    To : Coordinator (39:943/100.0)
    From: MakeNL 3.5.1 (39:943/0.0)
    Time: 03 Oct 21 01:41:01

    -start of message text-
    @MSGID: 39:943/0 615908bc
    -end of message text-

    I move that file to netmail directory on sbbs for sbbsecho procesing.

    I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    so this was ruoted via 4:* (zone was rewrite)

    2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject: /sbbs/fido/makenl/out/net.943

    Looks like Fuzzy Zone operation is enabled.

    Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    netmail with NO international zone information, it will compare the
    net/node of the destination to the net/node information in your AKAs
    and assume the (source and destination) zone of a matching AKA.
    This setting defaults to No.
    --
    digital man

    This Is Spinal Tap quote #3:
    How much more black could this be? and the answer is none. None more black. Norco, CA WX: 74.3øF, 34.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Wilfred van Velzen@2:280/464 to Digital Man on Tue Oct 5 09:45:57 2021
    Hi Digital,

    On 2021-10-04 19:06:36, you wrote to Ragnarok:

    I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    so this was ruoted via 4:* (zone was rewrite)

    2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject:
    /sbbs/fido/makenl/out/net.943

    Looks like Fuzzy Zone operation is enabled.

    Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    netmail with NO international zone information, it will compare the
    net/node of the destination to the net/node information in your AKAs
    and assume the (source and destination) zone of a matching AKA.
    This setting defaults to No.

    I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ragnarok@1:103/705 to Digital Man on Tue Oct 5 10:01:25 2021
    El 4/10/21 a las 23:06, Digital Man escribió:
    Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to DOVE-Net.Synchronet_Discussion on Sun Oct 03 2021 11:06 pm

    > Hi all i working on makenl to create a nodelist updates for 39:943
    >
    > the tool generate a simple netmail to send the generated file this is
    > the fmsgdump output:
    >
    > root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -ctrl -body 1.msg
    > fmsgdump rev 3.6 - Dump FidoNet Stored Messages
    >
    > Opening 1.msg
    > Subj: /sbbs/fido/makenl/out/net.943
    > Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
    > To : Coordinator (39:943/100.0)
    > From: MakeNL 3.5.1 (39:943/0.0)
    > Time: 03 Oct 21 01:41:01
    >
    > -start of message text-
    > @MSGID: 39:943/0 615908bc
    > -end of message text-
    >
    > I move that file to netmail directory on sbbs for sbbsecho procesing.
    >
    > I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    > so this was ruoted via 4:* (zone was rewrite)
    >
    > 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    > to Coordinator (4:943/100), attr: 0191, subject:
    > /sbbs/fido/makenl/out/net.943

    Looks like Fuzzy Zone operation is enabled.

    Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    netmail with NO international zone information, it will compare the
    net/node of the destination to the net/node information in your AKAs
    and assume the (source and destination) zone of a matching AKA.
    This setting defaults to No.


    I disable the Fuzzy zone option but have same result

    2021-10-05 09:59:21 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject:
    /sbbs/fido/makenl/out/net.943
    2021-10-05 09:59:21 Routing NetMail (1.msg) to 4:90/1

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Ragnarok@1:103/705 to Wilfred van Velzen on Tue Oct 5 10:21:54 2021
    El 5/10/21 a las 04:45, Wilfred van Velzen escribió:
    Hi Digital,

    On 2021-10-04 19:06:36, you wrote to Ragnarok:

    >> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    >> so this was ruoted via 4:* (zone was rewrite)
    >>
    >> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    >> to Coordinator (4:943/100), attr: 0191, subject:
    >> /sbbs/fido/makenl/out/net.943

    DM> Looks like Fuzzy Zone operation is enabled.

    DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    DM> netmail with NO international zone information, it will compare the
    DM> net/node of the destination to the net/node information in your AKAs
    DM> and assume the (source and destination) zone of a matching AKA.
    DM> This setting defaults to No.

    I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?

    this is the example file:

    http://downloads.bbs.docksud.com.ar/tmp/1.msg

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Wilfred van Velzen@2:280/464 to Ragnarok on Tue Oct 5 16:38:13 2021
    Hi Ragnarok,

    On 2021-10-05 10:21:54, you wrote to me:

    I checked a stored message that makenl generates. It has the complete
    4D address of the source and destination in the header (and also the
    source address in the MSGID kludge). A tosser should put those in the
    INTL kludge of the packed message in the .pkt file it generates. The
    Fuzzy Zone setting shouldn't overrule the information in an INTL kludge
    if present. So where does this go wrong?

    this is the example file:

    http://downloads.bbs.docksud.com.ar/tmp/1.msg

    # wget http://downloads.bbs.docksud.com.ar/tmp/1.msg
    --2021-10-05 16:23:36-- http://downloads.bbs.docksud.com.ar/tmp/1.msg Resolving downloads.bbs.docksud.com.ar (downloads.bbs.docksud.com.ar)... 2001:470:1f1e:4e::2, 152.169.156.2
    Connecting to downloads.bbs.docksud.com.ar (downloads.bbs.docksud.com.ar)|2001:470:1f1e:4e::2|:80...
    failed: Connection timed out.
    Connecting to downloads.bbs.docksud.com.ar (downloads.bbs.docksud.com.ar)|152.169.156.2|:80... connected.
    HTTP request sent, awaiting response... 200 OK

    It worked, but I had to wait on the timeout on the IPv6 connection. You probably have to configure a port forward in your router for IPv6! ;-)

    The file looks fine. It has the correct zone in the header for the source and destination, and in the MSGID kludge...

    # xxd 1.msg
    0000000: 4d61 6b65 4e4c 2033 2e35 2e31 0000 0000 MakeNL 3.5.1....
    0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    0000020: 0000 0000 436f 6f72 6469 6e61 746f 7200 ....Coordinator.
    0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    0000040: 0000 0000 0000 0000 2f73 6262 732f 6669 ......../sbbs/fi
    0000050: 646f 2f6d 616b 656e 6c2f 6f75 742f 6e65 do/makenl/out/ne
    0000060: 742e 3934 3300 0000 0000 0000 0000 0000 t.943...........
    0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    0000090: 3033 204f 6374 2032 3120 2030 313a 3431 03 Oct 21 01:41
    00000a0: 3a30 3100 0000 6400 0000 0000 af03 af03 :01...d.........
    00000b0: 2700 2700 0000 0000 0000 9101 0000 014d '.'............M
    ^^ ^^ 27 hex = 39 decimal
    00000c0: 5347 4944 3a20 3339 3a39 3433 2f30 2036 SGID: 39:943/0 6
    00000d0: 3135 3930 3862 630d 0a00 15908bc...


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ragnarok@1:103/705 to Wilfred van Velzen on Tue Oct 5 11:47:51 2021
    El 5/10/21 a las 04:45, Wilfred van Velzen escribió:
    Hi Digital,

    On 2021-10-04 19:06:36, you wrote to Ragnarok:

    >> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    >> so this was ruoted via 4:* (zone was rewrite)
    >>
    >> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    >> to Coordinator (4:943/100), attr: 0191, subject:
    >> /sbbs/fido/makenl/out/net.943

    DM> Looks like Fuzzy Zone operation is enabled.

    DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    DM> netmail with NO international zone information, it will compare the
    DM> net/node of the destination to the net/node information in your AKAs
    DM> and assume the (source and destination) zone of a matching AKA.
    DM> This setting defaults to No.

    I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?


    This Netmail was create from bbs (from qmail menu) just work: =|

    2021-10-05 11:20:00 Exporting NetMail message #186231 from Fernando
    Toledo to ragnarok (39:943/100)
    2021-10-05 11:20:00 Created NetMail (1.msg) from Fernando Toledo
    (39:943/0) to ragnarok (39:943/100), attr: 0181, subject: prueba 1
    2021-10-05 11:20:00 Packing NetMail (1.msg) from Fernando Toledo
    (39:943/0) to ragnarok (39:943/100), attr: 0181, subject: prueba 1
    2021-10-05 11:20:00 Node (39:943/100) successfully locked via: /sbbs/fido/outbound.027/03af0064.bsy
    2021-10-05 11:20:00 Adding NetMail (1.msg) to new packet for 39:943/100: /sbbs/fido/outbound.027/03af0064.out

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Wilfred van Velzen on Tue Oct 5 12:54:07 2021
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Wilfred van Velzen to Digital Man on Tue Oct 05 2021 09:45 am

    Hi Digital,

    On 2021-10-04 19:06:36, you wrote to Ragnarok:

    I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    so this was ruoted via 4:* (zone was rewrite)

    2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject:
    /sbbs/fido/makenl/out/net.943

    Looks like Fuzzy Zone operation is enabled.

    Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    netmail with NO international zone information, it will compare the
    net/node of the destination to the net/node information in your AKAs
    and assume the (source and destination) zone of a matching AKA.
    This setting defaults to No.

    I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?

    The Fuzzy Zone setting instructs SBBSecho to ignore the zone information in the netmail message header. If the netmail itself had an INTL kludge, it would use the zone information from that, but makenl isn't adding it. So, with Fuzzy Zone behavior, SBBSecho will "guess" the zone information based on the destination net/node/point. It's an arcane feature for old pre-historic "stored messages" and probably should just be removed.
    --
    digital man

    This Is Spinal Tap quote #13:
    Nigel Tufnel: You can't really dust for vomit.
    Norco, CA WX: 81.6øF, 39.0% humidity, 0 mph SW wind, 0.01 inches rain/24hrs
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Ragnarok on Tue Oct 5 12:57:38 2021
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Tue Oct 05 2021 10:01 am

    Looks like Fuzzy Zone operation is enabled.

    I disable the Fuzzy zone option but have same result

    So... Fuzzy Zone operation was enabled previously?

    2021-10-05 09:59:21 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject: /sbbs/fido/makenl/out/net.943
    2021-10-05 09:59:21 Routing NetMail (1.msg) to 4:90/1

    Looks like Fuzzy Zone operation is still enable or the netmail message is from zone 4.
    --
    digital man

    Synchronet "Real Fact" #24:
    1584 Synchronet BBS Software registrations were sold between 1992 and 1996. Norco, CA WX: 81.6øF, 39.0% humidity, 0 mph SW wind, 0.01 inches rain/24hrs
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Wilfred van Velzen@2:280/464 to Digital Man on Tue Oct 5 22:32:31 2021
    Hi Digital,

    On 2021-10-05 12:54:07, you wrote to me:

    I checked a stored message that makenl generates. It has the complete
    4D address of the source and destination in the header (and also the
    source address in the MSGID kludge). A tosser should put those in the
    INTL kludge of the packed message in the .pkt file it generates. The
    Fuzzy Zone setting shouldn't overrule the information in an INTL kludge
    if present. So where does this go wrong?

    The Fuzzy Zone setting instructs SBBSecho to ignore the zone information in
    the netmail message header. If the netmail itself had an INTL kludge, it would use the zone information from that, but makenl isn't adding it. So, with Fuzzy Zone behavior, SBBSecho will "guess" the zone information based on the destination net/node/point. It's an arcane feature for old pre-historic "stored messages" and probably should just be removed.

    Indeed, you probably almost never need it. Maybe with really old software that generates *.msg files. But should you want to use that software?

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Ragnarok@1:103/705 to Digital Man on Tue Oct 5 22:03:37 2021
    El 5/10/21 a las 16:54, Digital Man escribió:
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Wilfred van Velzen to Digital Man on Tue Oct 05 2021 09:45 am

    > Hi Digital,
    >
    > On 2021-10-04 19:06:36, you wrote to Ragnarok:
    >
    > >> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
    > >> so this was ruoted via 4:* (zone was rewrite)
    > >>
    > >> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
    > >> to Coordinator (4:943/100), attr: 0191, subject:
    > >> /sbbs/fido/makenl/out/net.943
    >
    > DM> Looks like Fuzzy Zone operation is enabled.
    >
    > DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
    > DM> netmail with NO international zone information, it will compare
    > DM> the
    > DM> net/node of the destination to the net/node information in your
    > DM> AKAs
    > DM> and assume the (source and destination) zone of a matching AKA.
    > DM> This setting defaults to No.
    >
    > I checked a stored message that makenl generates. It has the complete 4D
    > address of the source and destination in the header (and also the source
    > address in the MSGID kludge). A tosser should put those in the INTL kludge
    > of the packed message in the .pkt file it generates. The Fuzzy Zone setting
    > shouldn't overrule the information in an INTL kludge if present. So where
    > does this go wrong?

    The Fuzzy Zone setting instructs SBBSecho to ignore the zone information in the netmail message header. If the netmail itself had an INTL kludge, it would use the zone information from that, but makenl isn't adding it. So, with Fuzzy Zone behavior, SBBSecho will "guess" the zone information based on the destination net/node/point. It's an arcane feature for old pre-historic "stored messages" and probably should just be removed.

    Yeah this is!!.. i found that notify option on makenl have a INTL
    parameter, if i add this, the @INTL kludge was added to the netmail

    "notify all intl"

    root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -c -b 1.msg
    fmsgdump rev 3.6 - Dump FidoNet Stored Messages

    Opening 1.msg
    Subj: /sbbs/fido/makenl/out/net.943
    Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
    To : Coordinator (39:943/100.0)
    From: MakeNL 3.5.1 (39:943/0.0)
    Time: 05 Oct 21 21:52:18

    -start of message text-
    @INTL 39:943/100 39:943/0
    MSGID: 39:943/0 615908bd
    -end of message text-

    Now, sbbs sent perfect to the z39 node!


    2021-10-05 21:53:34 Packing NetMail (1.msg) from MakeNL 3.5.1 (39:943/0)
    to Coordinator (39:943/100), attr: 0191, subject: /sbbs/fido/makenl/out/net.943
    2021-10-05 21:53:34 Node (39:943/100) successfully locked via: /sbbs/fido/outbound.027/03af0064.bsy
    2021-10-05 21:53:34 File (/sbbs/fido/makenl/out/net.943, 0.7KB) for
    39:943/100 added to BSO/FLO file: /sbbs/fido/outbound.027/03af0064.flo 2021-10-05 21:53:34 Adding NetMail (1.msg) to new packet for 39:943/100: /sbbs/fido/outbound.027/03af0064.out

    This was the correct solution, I had deactivated fuzzy zone, but it
    still did not work until I changed the INTL parameter in the makenl config

    DM and Wilfred! I am very grateful to learn from you!
    You are the best!

    Thanks!

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Wilfred van Velzen on Tue Oct 5 20:22:38 2021
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Wilfred van Velzen to Digital Man on Tue Oct 05 2021 10:32 pm

    Indeed, you probably almost never need it. Maybe with really old software that generates *.msg files. But should you want to use that software?

    Yeah, I don't think so. It's probably like the ArcMail/AttachMail support that remains in SBBSecho: something nobody should be using.
    --
    digital man

    Breaking Bad quote #42:
    We have laws, detective. Have your kindergarten teacher read them to you. Norco, CA WX: 67.5øF, 75.0% humidity, 4 mph NNW wind, 0.01 inches rain/24hrs --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Ragnarok on Tue Oct 5 20:24:40 2021
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm

    This was the correct solution, I had deactivated fuzzy zone, but it
    still did not work until I changed the INTL parameter in the makenl config

    If that is truly the case, then there's a bug - and I would be surprised (since that's some pretty damn old code there). Are you positive? Do you mind retesting, that is, disabling the INTL parameter in your makenl config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is in fact not enabled, and reproducing the problem again?
    --
    digital man

    Synchronet "Real Fact" #9:
    The name "DOVE-Net" comes from: The Beast's DOmain / VErtrauen network.
    Norco, CA WX: 67.4øF, 75.0% humidity, 2 mph ENE wind, 0.01 inches rain/24hrs --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Ragnarok@1:103/705 to Digital Man on Wed Oct 6 10:13:02 2021
    El 6/10/21 a las 00:24, Digital Man escribió:
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm

    > This was the correct solution, I had deactivated fuzzy zone, but it
    > still did not work until I changed the INTL parameter in the makenl config

    If that is truly the case, then there's a bug - and I would be surprised (since that's some pretty damn old code there). Are you positive? Do you mind retesting, that is, disabling the INTL parameter in your makenl config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is in fact not enabled, and reproducing the problem again?

    Yes I can confirm with fuzzy zone is disabled and whitout INTL parameter
    on makenl.ctl, it does not work

    root@scarlet:/sbbs/ctrl# grep Fuzzy sbbsecho.ini
    FuzzyNetmailZones = false

    makenl.ctl file:

    master master
    update update
    mailfiles files_in
    uploads files_out
    badfiles files_bad
    outpath out
    make network 943
    outfile net.943
    submit 39:943/100
    netaddress 39:943/0
    messages msgout
    ; DISABLED notify all intl
    Loglevel 4
    Logfile makenl.log
    minphone 1
    alphaphone 1
    allowunpub 1
    baudrate 300,9600,14400,28800,33600,57600,115200



    2021-10-06 10:06:43 Packing NetMail (2.msg) from MakeNL 3.5.1 (4:943/0)
    to Coordinator (4:943/100), attr: 0191, subject:
    /sbbs/fido/makenl/out/net.943
    2021-10-06 10:06:43 Routing NetMail (2.msg) to 4:90/1
    2021-10-06 10:06:43 Node (4:90/1) successfully locked via: /sbbs/fido/outbound/005a0001.bsy
    2021-10-06 10:06:43 File (/sbbs/fido/makenl/out/net.943, 0.6KB) for
    4:90/1 added to BSO/FLO file: /sbbs/fido/outbound/005a0001.flo
    2021-10-06 10:06:43 Adding NetMail (2.msg) to new packet for 4:90/1: /sbbs/fido/outbound/005a0001.out
    2021-10-06 10:06:43 Deleting /sbbs/fido/netmail/2.msg (from line 5311) 2021-10-06 10:06:43 Touching outgoing semfile: ../data/binkout.now


    thanks!

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Ragnarok on Wed Oct 6 18:17:16 2021
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Wed Oct 06 2021 10:13 am

    El 6/10/21 a las 00:24, Digital Man escribi¢:
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm

    > This was the correct solution, I had deactivated fuzzy zone, but it
    > still did not work until I changed the INTL parameter in the makenl config

    If that is truly the case, then there's a bug - and I would be surprised (since that's some pretty damn old code there). Are you positive? Do you mind retesting, that is, disabling the INTL parameter in your makenl config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is in fact not enabled, and reproducing the problem again?

    Yes I can confirm with fuzzy zone is disabled and whitout INTL parameter
    on makenl.ctl, it does not work

    Okay, thanks for confirming. I see what's going on now: "Fuzzy Zone" operation is for *importing* netmail, which is not what you're having a problem with. Your problem was with *packing* netmail, where the "Fuzzy Zone" feature is not used and instead the zone information from the header of the netmail message is simply discarded. I'll fix that and appreciate you re-testing when you get a chance and letting us know how that worked.
    --
    digital man

    Breaking Bad quote #30:
    Damn, chick's got an ass like an onion - makes me want to cry. - Hank
    Norco, CA WX: 70.1øF, 69.0% humidity, 5 mph N wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Ragnarok@1:103/705 to Digital Man on Thu Oct 7 13:27:24 2021
    El 6/10/21 a las 22:17, Digital Man escribió:
    Re: Re: makenl sbbsecho and netmail and routing issue
    By: Ragnarok to Digital Man on Wed Oct 06 2021 10:13 am

    > El 6/10/21 a las 00:24, Digital Man escribi�:
    > > Re: Re: makenl sbbsecho and netmail and routing issue
    > > By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm
    >
    > > > This was the correct solution, I had deactivated fuzzy zone, but it
    > > > still did not work until I changed the INTL parameter in the makenl
    > > config
    >
    > > If that is truly the case, then there's a bug - and I would be surprised
    > > (since that's some pretty damn old code there). Are you positive? Do you
    > > mind retesting, that is, disabling the INTL parameter in your makenl
    > > config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is
    > > in fact not enabled, and reproducing the problem again?
    >
    > Yes I can confirm with fuzzy zone is disabled and whitout INTL parameter
    > on makenl.ctl, it does not work

    Okay, thanks for confirming. I see what's going on now: "Fuzzy Zone" operation is for *importing* netmail, which is not what you're having a problem with. Your problem was with *packing* netmail, where the "Fuzzy Zone" feature is not used and instead the zone information from the header of the netmail message is simply discarded. I'll fix that and appreciate you re-testing when you get a chance and letting us know how that worked.

    yeah!

    Whitout fuzzy zone and whitout INTL parameter It does work. GReat!

    ---
    ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)