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

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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 ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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