Hi All,

HPT, and the other Husky tools...

For those who are using them on Linux (intel), did you install pre-built binaries, or did you manage to build from sources?

I'm trying the latter, but I'm clearly missing something.

I've got the huskymak.cfg file updated and in the base directory as per the destructions, but when I jump into the smapi directory and run "make clean" (GNU make), it fails saying there's no target "clean".

I'm loosely familiar with Makefiles, but I can't see how this build system they've got going picks up the variables defined in the huskymak.cfg file, or really how this build system works at all. Trying the old Makefiles (make -f makefile.lnx clean) just yields other, different, problems.

I've currently got fidoconf, hpt, huskybse, huskylib, msged, and smapi unpacked into subdirectories of the base directory. All were git clones from the github repo (master branch, the others are prehistoric).

I can't help thinking it shouldn't be this hard. Can anyone tell me what totally obvious thing I'm missing? :-)

Cheers.

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)

I can't help thinking it shouldn't be this hard. Can anyone tell me what totally obvious thing I'm missing? :-)

I built a fresh husky a week ago following the instructions here..

https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

They are using a new build system these days and you are right, it seems to be harder than it needs to be.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

I built a fresh husky a week ago following the instructions here..

https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

Doh!

So those instructions are different to what's in the "INSTALL" file, but the "doh!" bit is that line 4 of the INSTALL file says to read INSTALL.asciidoc.

Let's see how it goes when I follow the right instructions...

Thanks for the pointer - much appreciated!

Cheers.

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)

https://github.com/huskyproject/huskybse/blob/master/INSTALL.asciidoc

Confirmed - read that version of the INSTALL doc and it builds fine. Doh!

Thankyou!

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)

Re: HPT
By: tassiebob to All on Thu Jul 07 2022 08:07 pm

HPT, and the other Husky tools...

For those who are using them on Linux (intel), did you install pre-built binaries, or did you manage to build from sources?

So I run Hub 3 with binkd and hpt - all in a docker container.

You are welcome to use that container - or look at my build (Dockerfile) here: https://dev.leenooks.net/bbs/fidohub

The runner has the build output if that helps.


...����
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

So I run Hub 3 with binkd and hpt - all in a docker container.

You are welcome to use that container - or look at my build (Dockerfile) here: https://dev.leenooks.net/bbs/fidohub

The runner has the build output if that helps.

I'll definitely take a look at that after work - I'll most likely run it natively, but there will be many useful pointers in the way you've got it all set up I'm sure.

Cheers,
Bob.

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: TassieBob BBS, Hobart, Tasmania (21:3/169)

here: https://dev.leenooks.net/bbs/fidohub

The runner has the build output if that helps.

I'll definitely take a look at that after work - I'll most likely run it natively, but there will be many useful pointers in the way you've got it all set up I'm sure.

binkd question...

Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

Presumably this is why it doesn't match the node line for 1337:2/100?

node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

Clues most welcome :-)

Cheers.

--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob BBS (21:3/169)

Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

It is the tosser that prepares the netmail to be sent, so I would look there and also check your golded.cfg (if you use that).

I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

Those are 5D node lines. I am using 3D node lines in binkd.conf like this..

domain fidonet /home/bbs/ftn/outbound 1 domain fsxnet /home/bbs/ftn/outbound 1

Presumably this is why it doesn't match the node line for 1337:2/100?

Actually that will work with binkd although you tosser needs to support 5D also.

I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

binkd will use binkp.net by default. There is another for fsxnet that Avon setup but I forget the details ATM.

We'll have to ask him the details.

I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

No, perl doesn't come into this.

Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

Yes, binkd will get node info from your node lines and use binkp.net otherwise if defnode is setup.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Hello TassieBob!

On 10 Jul 2022, TassieBob said the following...

node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

Try changing this to 21:3/100@fsxnet and 1337:2/100@tqwnet, and also make sure to include the domain in your address lines if you haven't already, e.g.:

address 21:3/169@fsxnet
address 1337:2/<your node number>@tqwnet

...to see if that makes any difference, as one blurb in the config says that:

# If the first address is specified as a 3D/4D address, its domain will be
# taken from the domain defined in the first "domain" line. If more addresses
# are specified as 3D/4D ones, their domain will be taken from the first
# address.

The last part there might be why it "borrows" the fsxnet domain for your additional addresses (1337:2/<your node number>).

I note that for Fidonet, I could specify a root-domain (binkp.net typically) on the node line and it'll do the FTN to hostname resolution that way. I haven't seen evidence of a root-domain I can use for fsxnet or tqwnet...

I have added "fsxnet.nz" to my config, although I see now that it doesn't seem to resolve my address:

host n202.n1.z21.fsxnet.nz
Host n202.n1.z21.fsxnet.nz not found: 3(NXDOMAIN)

...so maybe Avon will have to chime in on the details here. :)

I don't have the Perl nodelist stuff setup for binkd at the moment - is that the fix?

No, that should not be needed.

Am I wrong in assuming I should be able to send netmail to a node listed in a node line without needing a binkp.net style lookup or nodelist?

Yes, I think so.

And if you want binkd to be able to send to any node (e.g. for crashmail), you would add something like:

defnode *

...at the end. But this of course requires that the root domain has been set for each network so that it can resolve the FTN address to an IP number.

Hope this helps!

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Hey Al,

Sending a netmail to 1337:2/100, binkd tries to call
1337:2/100@fsxnet...

It is the tosser that prepares the netmail to be sent, so I would look there and also check your golded.cfg (if you use that).

I'm not seeing any trace of '@fsxnet' in the .cut file in the outbound directory, and the source/destination zone/net/node look to be right. I looked here earlier and that's what led me to the conclusion it was probably binkd doing it..

Presumably this is why it doesn't match the node line for 1337:2/100?

Actually that will work with binkd although you tosser needs to support 5D also.

I thought HPT did, but I may still have its config wrong...

I note that for Fidonet, I could specify a root-domain (binkp.net
typically) on the node line and it'll do the FTN to hostname resolution
that way. I haven't seen evidence of a root-domain I can use for fsxnet
or tqwnet...

binkd will use binkp.net by default. There is another for fsxnet that Avon setup but I forget the details ATM.

Ah - I had a quick poke around earlier and couldn't get anything obvious to resolve under fsxnet.nz. Hopefuly he'll chime in when he has a chance (I know he's off travelling at the moment).

I don't have the Perl nodelist stuff setup for binkd at the moment - is
that the fix?

No, perl doesn't come into this.

Sweet - I hate Perl... LoL.

Am I wrong in assuming I should be able to send netmail to a node
listed
in a node line without needing a binkp.net style lookup or nodelist?

Yes, binkd will get node info from your node lines and use binkp.net otherwise if defnode is setup.

That's about what I thought.

Thanks for the suggestions - I will indeed go back through my GoldED & HPT configurations, and do some comparisons between the packets that get generated for fsxnet vs those for tqwnet to see what, if any, obvious differences there are.

Cheers.


--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob BBS (21:3/169)

Hey Zip,

node 21:3/100 -4 n3.z21.bbs.leenooks.net:24554 pass,pass,pass -
node 1337:2/100 -4 n2.z1337.bbs.leenooks.net:24554 pass,pass,pass -

Try changing this to 21:3/100@fsxnet and 1337:2/100@tqwnet, and also make sure to include the domain in your address lines if you haven't already, e.g.:

address 21:3/169@fsxnet
address 1337:2/<your node number>@tqwnet

Tried that (but tried it again, just in case I pooched it up the first time). I didn't have any luck, but I'll do some more fiddling...

...to see if that makes any difference, as one blurb in the config
says
that:

# If the first address is specified as a 3D/4D address, its domain will be # taken from the domain defined in the first "domain" line. If more addresses # are specified as 3D/4D ones, their domain will be taken from the first # address.

The last part there might be why it "borrows" the fsxnet domain for your additional addresses (1337:2/<your node number>).

Yeah, that's what made me try it originally.

I have added "fsxnet.nz" to my config, although I see now that it
doesn't
seem to resolve my address:

host n202.n1.z21.fsxnet.nz
Host n202.n1.z21.fsxnet.nz not found: 3(NXDOMAIN)

:-(

Am I wrong in assuming I should be able to send netmail to a node
listed in a node line without needing a binkp.net style lookup or
nodelist?

Yes, I think so.

And if you want binkd to be able to send to any node (e.g. for crashmail), you would add something like:

defnode *

...at the end. But this of course requires that the root domain has been set for each network so that it can resolve the FTN address to an IP number.

I have defnode setup, but not the root-domain bit.

Hope this helps!

Has given me some pointers towards things to look at - muchly appreciated.

Cheers,
Bob.

--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob BBS (21:3/169)

Hello TassieBob,

It is the tosser that prepares the netmail to be sent, so I would
look there and also check your golded.cfg (if you use that).

I'm not seeing any trace of '@fsxnet' in the .cut file in the outbound directory, and the source/destination zone/net/node look to be right.
I looked here earlier and that's what led me to the conclusion it was probably binkd doing it..

I don't see it either here. Mind you I setup hpt years ago when there was no 5D support. That may have changed now but I am not sure.

I thought HPT did, but I may still have its config wrong...

I don't think so but I have not looked into 5D support.

Thanks for the suggestions - I will indeed go back through my GoldED &
HPT configurations, and do some comparisons between the packets that
get generated for fsxnet vs those for tqwnet to see what, if any,
obvious differences there are.

No worries. Hollar if you have issues or questions and we'll try to help you get things in order.

Ttyl :-),
Al

... This message has been UNIXized for your protection.
--- GoldED+/LNX 1.1.5-b20220504
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106.1)

Hello TassieBob!

On 10 Jul 2022, TassieBob said the following...

Tried that (but tried it again, just in case I pooched it up the first time). I didn't have any luck, but I'll do some more fiddling...

OK!

Has given me some pointers towards things to look at - muchly
appreciated.

You're very welcome! Hoping you'll be able to solve it.

As a sidenote, when I think of it, my outbound has one primary subdirectory (fsxnet), and the others are adjacent to it:

# NOTE: Specifying a matching (21 = 21) default zone will cause the outbound
# directory to become /mnt/bbs/echomail/out/fsxnet in practice
domain fsxnet /mnt/bbs/echomail/out/fsxnet 21 fsxnet.nz

# NOTE: Specifying a non-matching (21 != 2) default zone will cause the
# outbound directory to become /mnt/bbs/echomail/out/fidonet.002 in practice domain fidonet /mnt/bbs/echomail/out/fidonet 21 binkp.net

(I'm in FidoNet zone 2.)

So, I specify 21 as the default domain for all my FTN networks, and hence get .<number> suffixes to the outbound directory names for all but fsxNet.

Of course, having a subdirectory for each network eases things for binkd, but I think your setup with one outbound with all in it (right?) *should* work as well. As 3D setups do exist (for older software), and binkd *should* be able to find out from the outgoing packet filenames which node is the recipient...

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

As a sidenote, when I think of it, my outbound has one primary subdirectory
(fsxnet), and the others are adjacent to it:

# NOTE: Specifying a matching (21 = 21) default zone will cause the outbound # directory to become /mnt/bbs/echomail/out/fsxnet in
practice domain fsxnet /mnt/bbs/echomail/out/fsxnet 21 fsxnet.nz

# NOTE: Specifying a non-matching (21 != 2) default zone will cause the
# outbound directory to become /mnt/bbs/echomail/out/fidonet.002 in practice domain fidonet /mnt/bbs/echomail/out/fidonet 21 binkp.net

When I was first cutting the config for binkd I did configure it this way but I couldn't find the required HPT directives to make HPT use the separate outbound directories. The documentation suggested it only supported Binkley-style outbound directories (so a base directory for the primary zone, and .xxx hex encoded subdirectories for other zones).

So, I specify 21 as the default domain for all my FTN networks, and
hence
get .<number> suffixes to the outbound directory names for all but fsxNet.

What I have now is both fsx & tqw using a common outbound path, with fsx using the path as-is (it's primary), and tqw using <path>.539/ (hex encoded 1337).

Even though the outbound packets is in <path>.539/, binkd still thinks it needs to place an outbound call to 1337:2/100@fsxnet, which I have no node line for because, well, it should be 1337:2/100@tqwnet (which I do have a node line for).

but I think your setup with one outbound with all in it (right?)

Basically as described above, but for the avoidance of doubt/confusion:

drwxrwxr-x 3 bbs bbs 4096 Jul 10 19:47 outbound <- fsxnet
drwxr-xr-x 3 bbs bbs 4096 Jul 10 19:52 outbound.539 <- tqwnet

With binkd configured:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

I don't have any specific HPT config for this - it seems smart enough to put mail for my primary/first listed address in outbound, and for zone 1337 into outbound.539

There was a comment earlier that maybe my GoldED config might be the issue, so I tried sending a zone 1337 netmail from Mystic and had the same result. Possible they're both wrong of course, but I'm leaning towards thinking they're both OK and the problem is with either HPT or binkd - the latter feels more likely from what I'm seeing...

--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob's BBS (21:3/169)

Hello TassieBob!

On 10 Jul 2022, TassieBob said the following...

way but I couldn't find the required HPT directives to make HPT use the separate outbound directories. The documentation suggested it only supported Binkley-style outbound directories (so a base directory for
the primary zone, and .xxx hex encoded subdirectories for other zones).

OK! So no mention of domains (4D or even 5D) there?

Even though the outbound packets is in <path>.539/, binkd still thinks
it needs to place an outbound call to 1337:2/100@fsxnet, which I have no node line for because, well, it should be 1337:2/100@tqwnet (which I do have a node line for).

Yep, sounds like binkd believes the "outbound.539" directory is for a different zone but for the same domain (fsxNet) then...

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named "outbound". Which would then collide with the fsxNet outbound (which also uses the "outbound" directory).

Did you try changing this to:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 21

...or even something more apparent like:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 999

...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look for tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

The old documentation reference link I have for this would be:

https://web.archive.org/web/20171117081757/http://old.vk.pp.ru/docs/binkd/index .htm#config.domain

I believe this would be "Example 2".

Sorry if you already tried that. :)
This is interesting but intriguing stuff. :)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Hello again, TassieBob!

On 10 Jul 2022, Zip said the following...

Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named

(cut)

...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look
for tqwnet things in the "outbound.1337" directory rather than in the

Of course I meant "outbound.539" (the hex value of 1337) and not "outbound.1337". :-)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

On 10 Jul 2022, TassieBob said the following...

way but I couldn't find the required HPT directives to make HPT use
the separate outbound directories. The documentation suggested it
only supported Binkley-style outbound directories (so a base directory
for the primary zone, and .xxx hex encoded subdirectories for other
zones).

OK! So no mention of domains (4D or even 5D) there?

There's mention of 4D, and some mention of 5D (although with a warning that the domain name is not supported everywhere in the HPT config).

Yep, sounds like binkd believes the "outbound.539" directory is for a different zone but for the same domain (fsxNet) then...

Yeah, this appears to be the case. I'm just not sure why it's picking up the wrong domain.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

Did you try changing this to:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 21

...or even something more apparent like:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 999

I didn't, and I will, although I'd argue that's a pretty crappy/unintuitive way to have to configure it if that's what it needs to work. I suspect in doing so it'll not even realise outbound.539 is supposed to exist, and won't scan it.

Update: Did this while I was typing the reply, and confirmed, binkd doesn't even look at outbound.539 when configured this way.

default zone specified on the domain line, so that binkd knows to look
for
tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

...and continuing on from above, I can't specify /home/bbs/ftn/outbound.539 as the outbound directory as binkd flags the directory extension as invalid and refuses to use the config (tried that bit earlier).

The old documentation reference link I have for this would be: https://web.archive.org/web/20171117081757/http://old.vk.pp.ru/docs/bi nkd/index .htm#config.domain

I believe this would be "Example 2".

Will check that out in a sec.

This is interesting but intriguing stuff. :)

I'll bet it's going to end up something very simple. Maybe it's just me, but the documentation for these things seems to be sorely out of date in many cases. I remember the docco being much better in the late 80's :-)

Thanks for the ongoing suggestions!


--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob's BBS (21:3/169)

Update: Did this while I was typing the reply, and confirmed, binkd doesn't even look at outbound.539 when configured this way.

OK, so I might have been a bit hasty there - it is scanning outbound.539 now.

Might have made some progress - more testing to be done.


--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob's BBS (21:3/169)

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

Still wondering a little about that 1337 there, as specifying it should make binkd believe that anything for zone 1337 shouldn't be placed in a directory named "outbound.1337", but rather in the directory named "outbound". Which would then collide with the fsxNet outbound (which also uses the "outbound" directory).

Did you try changing this to:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 21

...or even something more apparent like:

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 999

...just so that you get a non-match (21 != 1337 and 999 != 1337) for the default zone specified on the domain line, so that binkd knows to look for tqwnet things in the "outbound.1337" directory rather than in the "outbound" directory?

OK, so I was too hasty.

Good news is YOU NAILED IT! I can send netmail for both zones now.

Using "the wrong" zone number on the subsequent entry is very unintuitive, and seems to go against the examples further down in the config file, but it absolutely works, and is totally in line with the info in that link you sent.

THANKYOU!


--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob's BBS (21:3/169)

Re: HPT
By: TassieBob to tassiebob on Sun Jul 10 2022 04:48 pm

Sending a netmail to 1337:2/100, binkd tries to call 1337:2/100@fsxnet...

I assume it's defaulting to fsxnet, since that's first listed in my binkd config file.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

A trap that gets everybody :)

The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

Its normal to use the same "outbound" for all your zones (/home/bbs/ftn/outbound) in your case, and the number on the end should be what it represents by default. If that is zone 21, then *every* domain line should have 21 for each different domain.

This helps binkd determine which outbound to put "other zone" mail in.

IE:

having:

domain fsxnet /home/bbs/ftn/outbound 21, and
domain tqwnet /home/bbs/ftn/outbound 21

Means:

* /home/bbs/ftn/outbound is the path prefix for my outgoing mail
* zone 21 mail will go it it directly
* zone 1337 mail will go in it with the hex 539 appended (ie: /home/bbs/ftn/outbound.539

Hope that makes sense :)


...����
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

Re: HPT
By: deon to TassieBob on Sun Jul 10 2022 10:38 pm

This helps binkd determine which outbound to put "other zone" mail in.

Errr. "find", not "put"...


...����
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

I assume it's defaulting to fsxnet, since that's first listed in my
binkd config file.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

A trap that gets everybody :)

Doh!

The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

Yeah, and if I re-read the comment in the binkd config file with that in mind, it kind of, sort of, says that. I was thrown by the example further down that showed two different zone numbers :-(

having:

domain fsxnet /home/bbs/ftn/outbound 21, and
domain tqwnet /home/bbs/ftn/outbound 21

Means:

* /home/bbs/ftn/outbound is the path prefix for my outgoing mail
* zone 21 mail will go it it directly
* zone 1337 mail will go in it with the hex 539 appended (ie: /home/bbs/ftn/outbound.539

Hope that makes sense :)

It does, but I still maintain the configuration is unintuitive :-)

Cheers.


--- GoldED+/LNX 1.1.5-b20220504
* Origin: TassieBob's BBS (21:3/169)

Hello TassieBob!

On 10 Jul 2022, TassieBob said the following...

Good news is YOU NAILED IT! I can send netmail for both zones now.

That's great news!

Using "the wrong" zone number on the subsequent entry is very
unintuitive, and seems to go against the examples further down in the

Yes, I also think it is very counterintuitive...

When I think about it, domains can probably simply be seen as yet another layer of addressing, allowing for different FTNs to use the same zone numbers without colliding. Or some kind of separation mechanism in general.

Given that, the default domain of a "domain" keyword is really only valid in practice if the outbound directories -- with or without zone numbers -- have unique names, identifying the FTNs (the domains).

So "Example 2" kind of nullifies one of the needs for domains in that respect...

At least they could have some kind of "NULL" keyword if one doesn't want a "default domain" for a domain (meaning that it should always create .<zone number> suffixes on the outbound directories)...

THANKYOU!

You're very welcome! :-D

It might also have been possible to add the "d" (direct) flavor to the node line, meaning that it should not send packets for that node through any other system. But in general that should not be needed; anything that should not be routed through another system should be marked as direct already by the tosser, by it (the tosser) assigning the flow files "*.d??" filenames. Which of course is common for flow files for polling ("*.dlo").

Anyway, glad that you got it working! :)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/07/07 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Re: HPT
By: TassieBob to deon on Sun Jul 10 2022 10:58 pm

It does, but I still maintain the configuration is unintuitive :-)

It probably is!

Ideally you only need to specify "the outbound" and assume its for the first aka, but it hasnt been coded that way :(


...����
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

It does, but I still maintain the configuration is unintuitive :-)

It is. There is a write up about all this in the Binkd FAQ but I think it gets forgotten about.. :)

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

deon wrote (2022-07-10):

Re: HPT
By: TassieBob to tassiebob on Sun Jul 10 2022 04:48 pm

Sending a netmail to 1337:2/100, binkd tries to call
1337:2/100@fsxnet...

I assume it's defaulting to fsxnet, since that's first listed in my
binkd config file.

domain fsxnet /home/bbs/ftn/outbound 21
domain tqwnet /home/bbs/ftn/outbound 1337

A trap that gets everybody :)

The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound" represents.

Are your sure? If I create a poll for 21:3/100 binkd uses the zone number to figure out the domain.

Its normal to use the same "outbound" for all your zones (/home/bbs/ftn/outbound) in your case, and the number on the end should
be what it represents by default. If that is zone 21, then *every* domain line should have 21 for each different domain.

Which is only a workaround and I saw weird things happening. binkd is a 5D mailer that doesn't implement 5D BSO correctly. It's just a mess.

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (21:3/102)

Re: HPT
By: Oli to deon on Sat Jul 23 2022 08:25 am

The number at the end (21 and 1337) is *not* the zone number for the domain, it is the zone number that this "outbound"
represents.

Are your sure? If I create a poll for 21:3/100 binkd uses the zone number to figure out the domain.

Yes.

If you have:

domain fsxnet /home/bbs/ftn/outbound 21

Binkd knows to find any outbound files in /home/bbs/ftn/outbound for that zone, named 00030064.*

If you were sending to 22:3/100, then binkd would look in /home/bbs/ftn/outbound.016 named 00030064.*

It actually makes sense to me why it was implemented this way, but it isnt an obvious conclusion for the newby.


...����
--- SBBSecho 3.15-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

deon wrote (2022-07-23):

Re: HPT
By: Oli to deon on Sat Jul 23 2022 08:25 am

The number at the end (21 and 1337) is *not* the zone number for
the domain, it is the zone number that this "outbound"
represents.

Are your sure? If I create a poll for 21:3/100 binkd uses the zone
number to figure out the domain.

Yes.

If you have:

domain fsxnet /home/bbs/ftn/outbound 21

Binkd knows to find any outbound files in /home/bbs/ftn/outbound for that zone, named 00030064.*

If you were sending to 22:3/100, then binkd would look in /home/bbs/ftn/outbound.016 named 00030064.*

It actually makes sense to me why it was implemented this way, but it
isnt an obvious conclusion for the newby.

If binkd is configured for 4D, which means using the wrong zone number for all other domains, you might be right. In proper 5D setup it also defines the default domain for the zone number. Not only for files in the outbound, but also for addresses in the config files (address, node keyword).

Let's say I have

domain fidonet /ftn/fidonet 2
domain dognet /ftn/dognet 6
domain fleanet /ftn/fleanet 6

address 2:...
address 6:100/200
node 6:100/232 ...
node 6:50/40@fleanet ...

binkd appends @dognet to all adresses that don't have a domain and start with the zone number "6:".

"binkd -P 6:100/232" polls node 6:100/232@dognet and send the aka 6:100/200@dognet.
"binkd -P 6:50/40" creates a poll for 6:50/40@dognet, but there would be no node to poll.
"binkd -P 6:50/40@fleanet" polls 6:50/40@fleanet, but there is no AKA defined for the network.


Yes. it is not wrong that

the number at the end
- is *not* (necessarily) the zone number for the domain
- it is the zone number that the outbound (without extension) represents

but

- every zone number has also a default domain. Which is kind of the zone number for the domain in 5D, but not exactly.

binkd somehow uses the domain in the configured AKAs too, to figure out the domain part. I don't know what has precedence over what. It's indeed a bit unintuitive.

Btw, if you want to use standard conform 5D BSO, you also have to use the wrong zone number workaround. Something like:

domain fidonet /ftn/fidonet 2
domain fsxnet /ftn/fsxnet 2

or

domain fidonet /ftn/fidonet 2
domain fsxnet /ftn/fsxnet 65535

(binkd allows even bigger zone numbers than 2¹⁶ in the config)



⁂

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (21:3/102)