So, Lately I've noticed that my BinkD, which is configured with 2 domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to "call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that, for any reason fails, it tries to callout to Z:N/NNN@gatornet, which fails IF it connects because the remote end doesn't have that AKA as @gatornet.

I was having this issue recently, and I'm not really sure how to... Not cause that to happen because, I see it still happening, however, neither @case connects, but in one case (Tommi knows about this, since he was being called to
many times over), one failed, one worked, to resolve, just not establish session. heh

So, how can I... Solve this issue properly? This is a pure binkd+huskytools HUB
server, no BBS, mail only setup.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Hi Eric,

On 27 Mar 20 00:22, Eric Renfro wrote to All:
about: "Issue with BinkD and outbound attempts.":

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as @gatornet.

I was having this issue recently, and I'm not really sure how to...
Not cause that to happen because, I see it still happening, however, neither @case connects, but in one case (Tommi knows about this, since
he was being called to many times over), one failed, one worked, to resolve, just not establish session. heh

So, how can I... Solve this issue properly? This is a pure binkd+huskytools HUB server, no BBS, mail only setup.

Do you have 'node' lines in your config for the destinations? And are the system addresses specified in 5D format?

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

On 03-27-20 00:22, Eric Renfro wrote to All <=-

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as @gatornet.

I had a similar issue. My solution was to go 5D, but that requires a tosser that can do 5D, of course. I don't know whether Husky (hpt) can do 5D, so I can't help there. And I haven't yet struck the case of the remote end not hacing a FTN domain - all of my peers use FTN domains for mailer sessions.


... A University without students is like an ointment without a fly.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

So, Lately I've noticed that my BinkD, which is configured with 2 domains

now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to "call"

Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that, for any reason fails, it tries to callout to Z:N/NNN@gatornet, which fails IF it connects because the remote end doesn't have that AKA as @gatornet.

I was having this issue recently, and I'm not really sure how to... Not

cause that to happen because, I see it still happening, however, neither @case connects, but in one case (Tommi knows about this, since he was being called to
many times over), one failed, one worked, to resolve, just not establish session. heh

So, how can I... Solve this issue properly? This is a pure

binkd+huskytools HUB server, no BBS, mail only setup.


When I tested hpt last year I had the same problem. I didn't like hpt anyway and switched to Crashmail and 5D again. I might be missing something, but for me this behaviour makes sense. There is a .flo file in the outbound of fidonet _and_ gatornet (both domains use the same outbound config) and of course binkd is trying both networks. What is missing in binkd is a way to map zone numbers to domains.

You could try to put the domain in the node line, like

node 1:2/3@fidonet ...

I haven't tried that, but in theory 1:2/3@gatornet shouldn't match 1:2/3@fidonet and if there is no match, there should be no call. I guess binkd would also try to lookup the binkp.net address for the gatornet domain if you have a "defnode *' line in binkd.cfg.

If nothing works you could try a 5D config in binkd and symlinks for the 4D tosser, someting like

./othernet
./gatornet
./outbound
./outbound.002
./outbound.039 -> ./gatornet
./outbound.fff -> ./othernet

Maybe others have better ideas :)

--- gossipEd-linux/arm .0.21-18496a58
* Origin: (2:280/464.47)

Re: Issue with BinkD and outbound attempts.
By: Oli to Eric Renfro on Fri Mar 27 2020 08:28:47

I might be missing something, but for me this behaviour makes sense. There is a .flo file in the outbound of fidonet _and_ gatornet (both domains use the same outbound config) and of course binkd is trying
both networks. What is missing in binkd is a way to map zone numbers
to domains.

that mapping is done by the domain lines... it generally works well except in cases where binkd has to be lied to and told that all domains use zone 1 for their first outbound...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Issue with BinkD and outbound attempts.
By: Oli to Eric Renfro on Fri Mar 27 2020 08:28:47

I might be missing something, but for me this behaviour makes sense.
There is a .flo file in the outbound of fidonet _and_ gatornet (both
domains use the same outbound config) and of course binkd is trying
both networks. What is missing in binkd is a way to map zone numbers
to domains.

that mapping is done by the domain lines... it generally works well except

in cases

where binkd has to be lied to and told that all domains use zone 1 for

their first

outbound...

Not really, you can only define the default zone number for a domain not multiple zones (like 1, 2, 3, 4 for Fidonet). As long as the default domain is the only one with multiple zones it works fine in 5D mode. Appart from the fact
that Binkd also doesn't create standard conformant outbound dirs as defined in fts-5005, e.g. it should look like this

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet.027 (Amiganet Zone 39)
c:\bink\agoranet.02e (Agoranet Zone 46)
c:\bink\dbnet.0c9 (Dbnet Zone 201)

but Binkd is omitting the zone number after the dot.

The 4D workaround is mentioned in the official BINKD FAQ, which suggests that it should work just fine.



--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Hi Oli,

On 2020-03-27 14:15:17, you wrote to mark lewis:

The 4D workaround is mentioned in the official BINKD FAQ, which
suggests that it should work just fine.

It does for me, and probably numerous others...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 27.03.2020 0:22, Eric Renfro wrote:

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1

domain gatornet /bbs/mailer/outbound 1

Just as Wilfred said, make sure that your "address" lines in binkd conf are 5D.

'Tommi

---
* Origin: nntps://news.fidonet.fi (2:221/6.0)

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Fri Mar 27 2020 14:15:17

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet.027 (Amiganet Zone 39)
c:\bink\agoranet.02e (Agoranet Zone 46)
c:\bink\dbnet.0c9 (Dbnet Zone 201)

this is exactly what i'm speaking of... my understanding is that proper 5D BSO for the above should be

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet (Amiganet Zone 39)
c:\bink\agoranet (Agoranet Zone 46)
c:\bink\dbnet (Dbnet Zone 201)

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)


what you posted above is what i'm calling 4.5D since it is a mixture of 4D and 5D...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hi mark,

On 2020-03-27 09:31:33, you wrote to Oli:

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

27 Mar 20 09:31, you wrote to me:

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Fri Mar 27 2020 14:15:17

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet.027 (Amiganet Zone 39)
c:\bink\agoranet.02e (Agoranet Zone 46)
c:\bink\dbnet.0c9 (Dbnet Zone 201)

this is exactly what i'm speaking of... my understanding is that proper 5D

BSO

for the above should be

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet (Amiganet Zone 39)
c:\bink\agoranet (Agoranet Zone 46)
c:\bink\dbnet (Dbnet Zone 201)

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

what you posted above is what i'm calling 4.5D since it is a mixture of 4D

and

5D...

What you call 4.5D is what I know as 5D from the 1990s. IIRC Squish and Binkleyterm use the hex extension for all outbound dirs that are not the default outbound.

The example I posted was a quote from FTS-5005 http://ftsc.org/docs/fts-5005.003

Which tossers do support 5D.nohex binkD style outbound?


--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Fri Mar 27 2020 15:01:22

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

right... that's standard 3D/4D... many tossers only support this format and do not do FTN domains at all...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Fri Mar 27 2020 14:49:49

what you posted above is what i'm calling 4.5D since it is a mixture of 4D and 5D...

What you call 4.5D is what I know as 5D from the 1990s. IIRC Squish and Binkleyterm use the hex extension for all outbound dirs that are not the default outbound.

even when using full 5D? i think you're remembering 3D/4D in which all BSO directories have the same base name...

The example I posted was a quote from FTS-5005

http://ftsc.org/docs/fts-5005.003

it is possible the document is wrong or doesn't explain things clearly...

Which tossers do support 5D.nohex binkD style outbound?

i'm not sure, at this point, and don't have the means to test like i used to have... i just know that the main difference between 3D/4D and 5D is the outbounds for other FTNs have different base names from the main FTN domain... in that case, they do properly have the zone HEX on the additional directories beside the main one /for that domain/ as opposed to doing that for *all* directories except the main outbound... again, that's my understanding even though there are numerous tossers used today that are doing it differently...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Eric Renfro on Fri Mar 27 2020 09:12 am

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as
@gatornet.

Well, kinda sorta yes. I have a nodelist.nl, which is converted from FTN style to BinkD style, and it has everything there as Z:N/NNN@fidonet, for that nodelist. These are converted using the nl2binkd perl script.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Re: Issue with BinkD and outbound attempts.
By: Tony Langdon to Eric Renfro on Fri Mar 27 2020 05:36 pm

On 03-27-20 00:22, Eric Renfro wrote to All <=-

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as
@gatornet.

I had a similar issue. My solution was to go 5D, but that requires a tosser that can do 5D, of course. I don't know whether Husky (hpt) can do 5D, so I can't help there. And I haven't yet struck the case of the remote end not hacing a FTN domain - all of my peers use FTN domains for mailer sessions.

Hmm. Interesting. hpt does seem to support 5D, from what I can tell in the documentation, however, the domain name is not fully supported throughout the fidoconfig itself, so.... Not entirely sure. LOL
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Issue with BinkD and outbound attempts.
By: Tommi Koivula to Eric Renfro on Fri Mar 27 2020 03:23 pm

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1

domain gatornet /bbs/mailer/outbound 1

Just as Wilfred said, make sure that your "address" lines in binkd conf are 5D.

Well, my address lines are indeed 5D:

address 1:135/300@fidonet 1:135/0@fidonet 57:157/1@gatornet 57:157/0@gatornet ===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Fri Mar 27 2020 03:01 pm

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

This is how it's been on my system for quite a while, but lately I notice that it's trying to "dialout" to @fidonet and upon failing that it actually tries to
dialout with @gatornet too. Which... Is... Unusual.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Hi mark,

On 2020-03-27 10:39:05, you wrote to me:

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

right... that's standard 3D/4D... many tossers only support this format

and

do not do FTN domains at all...

I don't feel the need to build it into FMail. As it works fine like this (as long as there are no overlapping Zone numbers between different nets. But I don't know of any)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Eric,

On 2020-03-27 10:50:23, you wrote to me:

So, Lately I've noticed that my BinkD, which is configured with 2
domains now, instead of just one.

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as
@gatornet.

Well, kinda sorta yes. I have a nodelist.nl, which is converted from FTN style to BinkD style, and it has everything there as Z:N/NNN@fidonet, for that nodelist. These are converted using the nl2binkd perl script.

But you also must have some "manual" node lines in your config for your secure links, so you can specify a password for them?

And your 'address' lines are also 5D?


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Eric,

On 2020-03-27 11:02:39, you wrote to me:

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

This is how it's been on my system for quite a while, but lately I notice that it's trying to "dialout" to @fidonet and upon failing that it

actually

tries to dialout with @gatornet too. Which... Is... Unusual.

So it didn't before? So what changed? Something must have! ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 27.3.2020 16:57, Eric Renfro wrote:

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

 TK> Just as Wilfred said, make sure that your "address" lines

in binkd conf are 5D.

Well, my address lines are indeed 5D:

address 1:135/300@fidonet 1:135/0@fidonet 57:157/1@gatornet
57:157/0@gatornet

Strange.. It should work then.

You could try to dump the config with -d and see how it looks.

And update your old -73 to the latest. :)

'Tommi

---
* Origin: nntp://fidonews.mine.nu (2:221/360.0)

Hi Wilfred.

27 Mar 20 16:49:12, you wrote to Eric Renfro:

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

This is causing some interesting issues that, when binkd tries to
"call" Z:N/NNN, it first tries to call Z:N/NNN@fidonet, and if that,
for any reason fails, it tries to callout to Z:N/NNN@gatornet, which
fails IF it connects because the remote end doesn't have that AKA as
@gatornet.

Well, kinda sorta yes. I have a nodelist.nl, which is converted from FTN
style to BinkD style, and it has everything there as Z:N/NNN@fidonet, for
that nodelist. These are converted using the nl2binkd perl script.

But you also must have some "manual" node lines in your config for your

secure

links, so you can specify a password for them?

Passwords can be defined elsewhere.

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/360)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Eric Renfro on Fri Mar 27 2020 04:51 pm

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

This is how it's been on my system for quite a while, but lately I
notice that it's trying to "dialout" to @fidonet and upon failing
that it

actually

tries to dialout with @gatornet too. Which... Is... Unusual.

So it didn't before? So what changed? Something must have! ;)

I added gatornet. That's about it. I guess I never observed it closely until recently. heh
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Issue with BinkD and outbound attempts.
By: Tommi Koivula to Eric Renfro on Fri Mar 27 2020 05:51 pm

domain fidonet /bbs/mailer/outbound 1
domain gatornet /bbs/mailer/outbound 1

 TK>> Just as Wilfred said, make sure that your "address" lines

in binkd conf are 5D.

Well, my address lines are indeed 5D:

address 1:135/300@fidonet 1:135/0@fidonet 57:157/1@gatornet
57:157/0@gatornet

Strange.. It should work then.

So, one thing I did do, was changed my domain line for gatornet to use different values:

domain gatornet /bbs/mailer/gatornet 57

Then in /bbs/mailer I symlinked outbound.039 to gatornet, so now binkd itself at least knows... the difference.. More specifically..

I know that hpt /supports/ 5D, but not completely. Still only allows one outbound directory to be set, otherwise it can use fileboxes (for echomail only).
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

27 Mar 20 10:45, you wrote to me:

what you posted above is what i'm calling 4.5D since it is a mixture of 4D
and 5D...

What you call 4.5D is what I know as 5D from the 1990s. IIRC Squish and
Binkleyterm use the hex extension for all outbound dirs that are not the
default outbound.

even when using full 5D? i think you're remembering 3D/4D in which all BSO directories have the same base name...

I'm pretty sure I used 5D with Squish and BinkleyTerm in the last millennium, because I already knew how it works when I installed Squish last year. I also was surprised that many tossers (hpt, fmail, ...) still don't support 5D outbound.

The example I posted was a quote from FTS-5005
http://ftsc.org/docs/fts-5005.003

it is possible the document is wrong or doesn't explain things clearly...

I think it's very clearly explained and I also doubt the document is wrong.

Which tossers do support 5D.nohex binkD style outbound?

i'm not sure, at this point, and don't have the means to test like i used

to

have... i just know that the main difference between 3D/4D and 5D is the outbounds for other FTNs have different base names from the main FTN

domain...

in that case, they do properly have the zone HEX on the additional

directories

beside the main one /for that domain/ as opposed to doing that for *all* directories except the main outbound... again, that's my understanding

even

though there are numerous tossers used today that are doing it

differently...

This is a quote from the BinkleyTerm 2.40 DOC (from 1990):

"Note that outbound areas for domains other than your own will ALWAYS have a zone extension."

BinkleyTerm is doing it exactly as it is documented by the FTSC.

There is a longer chapter at the end of the BinkleTerm documentation about 5D outbounds: http://www.retroarchive.org/cdrom/nightowl-005/001A/BEXE_240/BINK_240.DOC



--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Issue with BinkD and outbound attempts.
By: Tommi Koivula to Eric Renfro on Fri Mar 27 2020 05:51 pm

And update your old -73 to the latest. :)

Done. 1.1a101 now in use. Thanks to rpm .spec files. :D
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Hi Tommi,

On 2020-03-27 17:56:28, you wrote to me:

Well, kinda sorta yes. I have a nodelist.nl, which is converted from
FTN style to BinkD style, and it has everything there as
Z:N/NNN@fidonet, for that nodelist. These are converted using the
nl2binkd perl script.

But you also must have some "manual" node lines in your config for
your secure links, so you can specify a password for them?

Passwords can be defined elsewhere.

Yes, with overriding node lines, which also must have a 5D address.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Eric,

On 2020-03-27 12:03:15, you wrote to me:

This is how it's been on my system for quite a while, but lately I
notice that it's trying to "dialout" to @fidonet and upon failing
that it actually tries to dialout with @gatornet too. Which... Is...
Unusual.

So it didn't before? So what changed? Something must have! ;)

I added gatornet. That's about it. I guess I never observed it closely until recently. heh

And you already had multiple nets? Or gatornet was your second?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Friday March 27 2020 18:20, Wilfred van Velzen wrote to Tommi Koivula:

But you also must have some "manual" node lines in your config for
your secure links, so you can specify a password for them?

Passwords can be defined elsewhere.

Yes, with overriding node lines, which also must have a 5D address.

Or with an external passwords file:

=== Begin Clipboard ===
#
# t-mail or ifcico (qico) passwords file.
# Format of passwords file:
# [password] <FTN address> <password for the link>
# where:
# [password] optional token "password"
# <FTN address> address of a link in the form 1:2/3.4@domain
# or 1:2/3@domain or 1:2/3 or 1:2/3.4
# <password for the link> secret password (one word, without spaces or tabs) #
passwords \\bbs\\binkd\\passwords.lst

=== End Clipboard ===

'Tommi

---
* Origin: rbb.fidonet.fi (2:221/360)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Tommi Koivula on Fri Mar 27 2020 06:20 pm

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wait a sec.. FMail, for Linux? heh
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Eric Renfro on Fri Mar 27 2020 06:21 pm

This is how it's been on my system for quite a while, but lately I
notice that it's trying to "dialout" to @fidonet and upon failing
that it actually tries to dialout with @gatornet too. Which...
Is... Unusual.

So it didn't before? So what changed? Something must have! ;)

I added gatornet. That's about it. I guess I never observed it
closely until recently. heh

And you already had multiple nets? Or gatornet was your second?

I had added GatorNet as the second, on the HUB anyway. It was primarily just fidonet. I've been setting it up for multiple networks to act as hub for others
as needed/wanted.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Hi Tommi,

On 2020-03-27 19:27:46, you wrote to me:

Yes, with overriding node lines, which also must have a 5D address.

Or with an external passwords file:

=== Begin Clipboard ===
#
# t-mail or ifcico (qico) passwords file.
# Format of passwords file:
# [password] <FTN address> <password for the link>
# where:
# [password] optional token "password"
# <FTN address> address of a link in the form 1:2/3.4@domain # or 1:2/3@domain or 1:2/3 or 1:2/3.4
# <password for the link> secret password (one word, without spaces or tabs) # passwords \\bbs\\binkd\\passwords.lst

That's sort of the same thing, and also must have 5D addresses! ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Eric,

On 2020-03-27 13:38:48, you wrote to me:

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wait a sec.. FMail, for Linux? heh

Well yes, sort of... Of the 3 modules that make up FMail: fmail, ftools, fconfig. Only the first two are converted to linux. So to configure it, you still need to have a windows (virtual), with acces to the linux paths where your fido system runs, to edit the configuration.

But if you can make those conditions happen, it runs very smoothly. For more than 3 years now on my system.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Eric,

On 2020-03-27 13:40:23, you wrote to me:

So it didn't before? So what changed? Something must have! ;)

I added gatornet. That's about it. I guess I never observed it
closely until recently. heh

And you already had multiple nets? Or gatornet was your second?

I had added GatorNet as the second, on the HUB anyway. It was primarily just fidonet. I've been setting it up for multiple networks to act as hub for others as needed/wanted.

My guess is there must be some (subtle) mistake in either the binkd or hpt config, after addind gatornet, because binkd doesn't exibit this "flaw" on mine
or other systems with multiple nets... The problem is finding it. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Eric Renfro on Fri Mar 27 2020 06:49 pm

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Wait a sec.. FMail, for Linux? heh

Well yes, sort of... Of the 3 modules that make up FMail: fmail, ftools, fconfig. Only the first two are converted to linux. So to configure it, you still need to have a windows (virtual), with acces to the linux paths where your fido system runs, to edit the configuration.

Hmmm... 5D support? heh


Drats! I avoid Windows like the plague it is. What about dosemu? LOL My HUB server runs on AWS EC2, so it's not exactly going to have easy access to Windows anyway.

And, why hasn't fconfig been ported over yet? ;)
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to Eric Renfro on Fri Mar 27 2020 06:58 pm

So it didn't before? So what changed? Something must have! ;)

I added gatornet. That's about it. I guess I never observed it
closely until recently. heh

And you already had multiple nets? Or gatornet was your second?

I had added GatorNet as the second, on the HUB anyway. It was
primarily just fidonet. I've been setting it up for multiple
networks to act as hub for others as needed/wanted.

My guess is there must be some (subtle) mistake in either the binkd or hpt config, after addind gatornet, because binkd doesn't exibit this "flaw" on mine or other systems with multiple nets... The problem is finding it. ;)

The only thing I can think on is the possability of not using 5D addresses in hpt, but doing so in BinkD.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Re: Re: Issue with BinkD and outbound attempts.
By: Eric Renfro to Wilfred van Velzen on Fri Mar 27 2020 03:49 pm

My guess is there must be some (subtle) mistake in either the
binkd or hpt config, after addind gatornet, because binkd
doesn't exibit this "flaw" on mine or other systems with
multiple nets... The problem is finding it. ;)

The only thing I can think on is the possability of not using 5D addresses in hpt, but doing so in BinkD. ---

Then again, I just checked..
My fidoconf.cfg is 5D....

Address 1:135/300@fidonet
Address 1:135/0@fidonet
Address 57:157/1@gatornet
Address 57:157/0@gatornet

Though that's the only place 5D addresses seem to be documented to be allowed... Specifically.. Not in ourAka for links or anything.
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

Hi Eric,

On 2020-03-27 15:44:54, you wrote to me:

Wait a sec.. FMail, for Linux? heh

Well yes, sort of... Of the 3 modules that make up FMail: fmail,
ftools, fconfig. Only the first two are converted to linux. So to
configure it, you still need to have a windows (virtual), with acces
to the linux paths where your fido system runs, to edit the
configuration.

Hmmm... 5D support? heh

Why? 4D works fine.

Drats! I avoid Windows like the plague it is. What about dosemu?

FConfig is a win32 console program, so it won't run under dosemu. I tried wine,
but the keyboard handling seems different from the real windows, because it wouldn't function propperly.

LOL My HUB server runs on AWS EC2, so it's not exactly going to have
easy access to Windows anyway.

And, why hasn't fconfig been ported over yet? ;)

Because I'm lazy. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

27 Mar 20 15:54, you wrote to Wilfred van Velzen:

My guess is there must be some (subtle) mistake in either the
binkd or hpt config, after addind gatornet, because binkd
doesn't exibit this "flaw" on mine or other systems with
multiple nets... The problem is finding it. ;)

The only thing I can think on is the possability of not using 5D addresses
in hpt, but doing so in BinkD. ---

Then again, I just checked..
My fidoconf.cfg is 5D....

Address 1:135/300@fidonet
Address 1:135/0@fidonet
Address 57:157/1@gatornet
Address 57:157/0@gatornet

Though that's the only place 5D addresses seem to be documented to be

allowed...

Specifically.. Not in ourAka for links or anything.

hpt has no support for 5D addresses, but the domain in the Address line could be used by other programs that read fidoconf.cfg. For hpt and binkd it shouldn't make any difference if you use a 4D or a 5D address in fidoconf.cfg.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Fri Mar 27 2020 16:44:56

right... that's standard 3D/4D... many tossers only support this format and do not do FTN domains at all...

I don't feel the need to build it into FMail. As it works fine like this

(as long as there are no overlapping Zone numbers between different nets.

But I don't know of any)

you don't? let me help you with that, then...

this is my binkd-networks.inc include file...


########################################################################
# FTN BSO FTN DNS #
# domain outbound dir Zone lookup domain zones# ########################################################################
[...]
domain survnet /sbbs/ftn/out/survnet 1 # 9
domain virnet /sbbs/ftn/out/virnet 1 # 9
domain winsnet /sbbs/ftn/out/winsnet 1 # 9
domain araknet /sbbs/ftn/out/araknet 1 # 10
domain league10 /sbbs/ftn/out/league10 1 # 10
[...]
domain fsxnet /sbbs/ftn/out/fsxnet 1 fsxnet.nz # 21
domain usenet /sbbs/ftn/out/usenet 1 # 21
domain zone21 /sbbs/ftn/out/zone21 1 # 21
[...]
domain sfnet /sbbs/ftn/out/sfnet 1 # 42
domain unionnet /sbbs/ftn/out/unionnet 1 # 42
[...]
domain anet /sbbs/ftn/out/anet 1 # 92
domain zenet /sbbs/ftn/out/zenet 1 # 92
[...]
domain wennet /sbbs/ftn/out/wennet 1 # 316
domain whisper /sbbs/ftn/out/whisper 1 # 316
[...]



)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Re: Issue with BinkD and outbound attempts.
By: mark lewis to Wilfred van Velzen on Fri Mar 27 2020 05:25 pm

I don't feel the need to build it into FMail. As it works fine like

this WvW> (as long as there are no overlapping Zone numbers between different nets. WvV> But I don't know of any)

you don't? let me help you with that, then...

this is my binkd-networks.inc include file...

########################################################################
# FTN BSO FTN DNS #
# domain outbound dir Zone lookup domain zones# ######################################################################## [...]
domain survnet /sbbs/ftn/out/survnet 1 # 9
domain virnet /sbbs/ftn/out/virnet 1 # 9
domain winsnet /sbbs/ftn/out/winsnet 1 # 9
domain araknet /sbbs/ftn/out/araknet 1 # 10
domain league10 /sbbs/ftn/out/league10 1 # 10
[...]

Well.... I believe, pwned, is the right word for that? ;)
===
)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

On 03-27-20 10:52, Eric Renfro wrote to Tony Langdon <=-

Hmm. Interesting. hpt does seem to support 5D, from what I can tell in
the documentation, however, the domain name is not fully supported throughout the fidoconfig itself, so.... Not entirely sure. LOL

Many tossers support only what I would call "4.5D", meaning they do support FTN domains, but they may not support the case where two different domains have the same zone - for example, SBBSEcho seems to use a zone to domain mapping, which would preclude this scenario, although 5D is supposed to be there to deal with that situation. But that's sufficient for our purposes here. :) I haven't tested the extent of Mystic's 5D support at this time. Maybe one day I should configure a dummy FTN with the same zone and different domain as one of my FTNs and see what happens. :)

As long as hpt can support having separate outbound directories for each FTN domain, it should work with binkd in 5D mode.


... We are the very model of cartoon individuals.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 03-27-20 14:15, Oli wrote to mark lewis <=-

in cases

where binkd has to be lied to and told that all domains use zone 1 for

their first

outbound...

That's what I do, except that my default zone is zone 3, rather than 1. So all of my domains in binkd have 3 as the default zone in binkd.conf.

Not really, you can only define the default zone number for a domain
not multiple zones (like 1, 2, 3, 4 for Fidonet). As long as the
default domain is the only one with multiple zones it works fine in 5D mode. Appart from the fact that Binkd also doesn't create standard conformant outbound dirs as defined in fts-5005, e.g. it should look
like this

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\amiganet.027 (Amiganet Zone 39)
c:\bink\agoranet.02e (Agoranet Zone 46)
c:\bink\dbnet.0c9 (Dbnet Zone 201)

That's what my outbound tree looks like, except for the details - my domains are largely different, and I'm on Linux, but the structure is broadly the same, as you'd expect.

but Binkd is omitting the zone number after the dot.

Unless you use the same default zone (for most people, your Fidonet zone) for all domain entries.


... Spelling is a sober man's game
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 03-27-20 14:49, Oli wrote to mark lewis <=-

What you call 4.5D is what I know as 5D from the 1990s. IIRC Squish and Binkleyterm use the hex extension for all outbound dirs that are not
the default outbound.

The example I posted was a quote from FTS-5005 http://ftsc.org/docs/fts-5005.003

Which tossers do support 5D.nohex binkD style outbound?

I haven't encountered one yet. Both SBBSecho and mutil (Mystic) will put the hex extension on othernet domain outbound directories.


... Years of development: We finally got one to work.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 03-27-20 10:39, mark lewis wrote to Wilfred van Velzen <=-

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Fri Mar 27 2020 15:01:22

4D BSO would have ALL of them named "outbound.xxx" like this...

c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.027 (Amiganet Zone 39)
c:\bink\outbound.02e (Agoranet Zone 46)
c:\bink\outbound.0c9 (Dbnet Zone 201)

This is how it works on my system...

right... that's standard 3D/4D... many tossers only support this format and do not do FTN domains at all...

That's how I did it back in the day. Only BinkleyTerm fully understood 5D on my system then. Today, I use 5D outbound directories.


... I'm pretty sure that none of us are here.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

What you call 4.5D is what I know as 5D from the 1990s. IIRC Squish and
Binkleyterm use the hex extension for all outbound dirs that are not
the default outbound.

The example I posted was a quote from FTS-5005
http://ftsc.org/docs/fts-5005.003

Which tossers do support 5D.nohex binkD style outbound?

I haven't encountered one yet. Both SBBSecho and mutil (Mystic) will put

the

hex extension on othernet domain outbound directories.

I wonder why the default behaviour of BinkD isn't compatible with any other software and you always need some config workaround.

Because of the weird 4D / 5D BSO issues in binkd, I switched to Amiga-Style-Outbound (aso / amiga_4d_outbound) in 5D mode. I had to change a few lines in the Crashmail code, but that was trivial and ASO is a much nicer outbound format.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

but Binkd is omitting the zone number after the dot.

Unless you use the same default zone (for most people, your Fidonet zone)

for

all domain entries.

But it's a workaround with side effects. Why do we have a default zone number in the first place, when the only way to get standard conformat 5D BSO directories is by deliberately putting wrong zone numbers in the config?

I call it a bug, not a feature.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Hi mark,

On 2020-03-27 17:25:59, you wrote to me:

I don't feel the need to build it into FMail. As it works fine like
this (as long as there are no overlapping Zone numbers between
different nets. But I don't know of any)

you don't? let me help you with that, then...

this is my binkd-networks.inc include file...

########################################################################
# FTN BSO FTN DNS #
# domain outbound dir Zone lookup domain zones# ######################################################################## [...]
domain survnet /sbbs/ftn/out/survnet 1 # 9 domain virnet /sbbs/ftn/out/virnet 1 # 9 domain winsnet /sbbs/ftn/out/winsnet 1 # 9 domain araknet /sbbs/ftn/out/araknet 1 # 10 domain league10 /sbbs/ftn/out/league10 1 # 10 [...]
domain fsxnet /sbbs/ftn/out/fsxnet 1 fsxnet.nz # 21 domain usenet /sbbs/ftn/out/usenet 1 # 21 domain zone21 /sbbs/ftn/out/zone21 1 # 21 [...]
domain sfnet /sbbs/ftn/out/sfnet 1 # 42 domain unionnet /sbbs/ftn/out/unionnet 1 # 42 [...]
domain anet /sbbs/ftn/out/anet 1 # 92 domain zenet /sbbs/ftn/out/zenet 1 # 92 [...]
domain wennet /sbbs/ftn/out/wennet 1 # 316 domain whisper /sbbs/ftn/out/whisper 1 # 316 [...]

Are those active nets? I only recognise fsxnet...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 03-28-20 10:52, Oli wrote to Tony Langdon <=-

I wonder why the default behaviour of BinkD isn't compatible with any other software and you always need some config workaround.

Well, it certainly doesn't meet FTSC standards as documented, weird.

Because of the weird 4D / 5D BSO issues in binkd, I switched to Amiga-Style-Outbound (aso / amiga_4d_outbound) in 5D mode. I had to
change a few lines in the Crashmail code, but that was trivial and ASO
is a much nicer outbound format.

The little I've seen of ASO, it does look quite good.


... Borrow a few lines = Plagiarism. Steal *volumes* = Research.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 03-28-20 10:53, Oli wrote to Tony Langdon <=-

but Binkd is omitting the zone number after the dot.

Unless you use the same default zone (for most people, your Fidonet zone)

for

all domain entries.

But it's a workaround with side effects. Why do we have a default zone number in the first place, when the only way to get standard conformat
5D BSO directories is by deliberately putting wrong zone numbers in the config?

Side effects? And I note that the FTSC document you referenced only talks about "the default zone", but doesn't qualify it as being for a domain (which you would expect). So there's assumptions there.

... Amiga: The Computer They Couldn't Kill
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

but Binkd is omitting the zone number after the dot.

Unless you use the same default zone (for most people, your Fidonet zone)
for all domain entries.

But it's a workaround with side effects. Why do we have a default zone
number in the first place, when the only way to get standard conformat
5D BSO directories is by deliberately putting wrong zone numbers in the
config?

Side effects?

You are right, it doesn't make any difference in my setup. This works fine:

domain fidonet /srv/ftn/outbound/fidonet 2
domain fsxnet /srv/ftn/outbound/fsxnet 2
domain amiganet /srv/ftn/outbound/amiganet 2

I thought binkd wouldn't be able to figure out which zone number maps to which domain, but it doesn't seem to be a problem.

$ poll 39:15/0
12:59 [16912] BEGIN, binkd/1.1a-101/Linux -p -P 39:15/0 /srv/ftn/binkd/binkd.cfg
12:59 [16912] creating a poll for 39:15/0@amiganet (`d' flavour)

And I note that the FTSC document you referenced only talks
about "the default zone", but doesn't qualify it as being for a domain

(which

you would expect). So there's assumptions there.

If binkd's <default-zone> parameter is intented to have the same meaning as "the default zone" in FTS-5005 than using the same zone number for all "domain"
lines is the right configuration (and not a workaround). It is counterintuitive
though and the example binkd.cfg files suggests you should use the zone number of the network.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Sat Mar 28 2020 11:48:12

this is my binkd-networks.inc include file...
[...]

Are those active nets? I only recognise fsxnet...

AFAIK, they are... they've been gleaned from my mailer logs as presented by systems connecting here or connected to from here... they match pretty well with FTNs listed in other FTN lists, too...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hi mark,

On 2020-03-28 11:32:38, you wrote to me:

Are those active nets? I only recognise fsxnet...

AFAIK, they are... they've been gleaned from my mailer logs as presented

by

systems connecting here or connected to from here... they match pretty

well

with FTNs listed in other FTN lists, too...

That they are in systems configurations doesn't mean they are active...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Re: Issue with BinkD and outbound attempts.
By: Oli to Tony Langdon on Sat Mar 28 2020 12:54:59

If binkd's <default-zone> parameter is intented to have the same
meaning as "the default zone" in FTS-5005 than using the same
zone number for all "domain" lines is the right configuration
(and not a workaround).

don't get confused by the chicken and the egg syndrome... binkd came first and the FTSC documents came after ;)

It is counterintuitive though and the example binkd.cfg files
suggests you should use the zone number of the network.

exactly why using the same default zone for all domains is a workaround which also leads to all domain directories having the hex zone extension on them...

i had several discussions with a few of the binkd devs in here some years back when i was working on my 4DOS/4OS2 BSO scripts... i was told that for proper 5D, only the first directory for each FTN domain's outbound directory has no hex zone extension on it... all the others do...

then there's this from the binkd FAQ... this quote is from one i saved back in 2017 so the question number may be off but anyway, it is #22 here...


----->8 snip 8<-----

22. Different FTN Domains in binkd And a Tosser Without 5D Support

Suppose there are two domains (with different zone numbers though it
does not matter). Mail can be successfully sent to the first domain but
not to the second one. This situation may arise if the tosser, the tracker
and the other your FTN programs do not support 5D BSO.

This is a typical binkd configuration for two FTN domains and 5D
outbound:

domain fidonet c:\\ftn\\outbound\\fidonet 2
domain omeganet c:\\ftn\\outbound\\omeganet 11
address 2:5070/222@fidonet 11:58/6@omeganet

One must configure not the zone of your own address for 'domain'
keyword as one might think but the zone that should not be appended to the outbound name (i.e. the outbound subdirectory extensions are not processed
for the zone denoted in the 'domain' line).

If your tosser would create bundles for omeganet in the omeganet
directory then you should write as indicated above. But since it does not
work with 5D and it creates the bundles in fidonet.00b then you should
write this way:

domain fidonet c:\\ftn\\outbound\\fidonet 2
domain omeganet c:\\ftn\\outbound\\fidonet 2
address 2:5070/222@fidonet 11:58/6@omeganet

It is obligatory to configure all your addresses with domains. The
outbound directory and the path should be the same everywhere (4D tosser considers all addresses to belong to one domain).

----->8 snip 8<-----


i did (finally) find the text of a message where stas replied to me in reference to my questions about 5D while working on my 4DOS/4OS2 scripts... i think this was back in about 2011 going by the version of his golded... unfortulately i cannot currently get to the actual header of his message...


----->8 snip 8<-----

Hello mark.

25 Jul 12 17:04, you wrote to me:

eg:
domain fidonet x:\\bink\\outbound\\fidonet 1
domain quartz x:\\bink\\outbound\\quartz 123

X:\BINK\OUTBOUND\FIDONET
X:\BINK\OUTBOUND\FIDONET .002
X:\BINK\OUTBOUND\FIDONET .003
X:\BINK\OUTBOUND\FIDONET .004
X:\BINK\OUTBOUND\FIDONET .005
X:\BINK\OUTBOUND\FIDONET .006

OK

X:\BINK\OUTBOUND\QUARTZ .07B

Invalid, should be:
X:\BINK\OUTBOUND\QUARTZ

X:\BINK\OUTBOUND\QUARTZ .07C
X:\BINK\OUTBOUND\QUARTZ .07D

OK

the above indicates fidonet is zones 1,2,3,4,5,6 and quartz is 123,124,125??

Zone 123 specified as "default for the domain quartz" and outbound directory for 123:*@quartz should be without number in suffix.

and if i have foobar net with zone 124 (duplicate zone, different
domain) then...

domain fidonet x:\\bink\\outbound\\fidonet 1
domain quartz x:\\bink\\outbound\\quartz 123
domain foobar x:\\bink\\outbound\\foobar 124

X:\BINK\OUTBOUND\FIDONET
X:\BINK\OUTBOUND\FIDONET .002
X:\BINK\OUTBOUND\FIDONET .003
X:\BINK\OUTBOUND\FIDONET .004
X:\BINK\OUTBOUND\FIDONET .005
X:\BINK\OUTBOUND\FIDONET .006

OK

X:\BINK\OUTBOUND\FOOBAR .07C
X:\BINK\OUTBOUND\QUARTZ .07B

Invalid, should be:
X:\BINK\OUTBOUND\FOOBAR
X:\BINK\OUTBOUND\QUARTZ

X:\BINK\OUTBOUND\QUARTZ .07C
X:\BINK\OUTBOUND\QUARTZ .07D

OK

the above indicates fidonet is zones 1,2,3,4,5,6... foobar is 124... quartz is 123,124,125???

Stas
Jabber-ID: grumbler@grumbler.org
GPG key 0x72186DB9 (keyserver: hkp://wwwkeys.eu.pgp.net)
.!. Golded+, Husky & RNTrack maintainer, Binkd developer&webmaster
-!- GoldED+/LNX 1.1.5-b20110302
! Origin: Grumbler at home (2:5080/102.1)

----->8 snip 8<-----


i've taken and used the above as the definitive format for a proper 5D outbound
directory layout ever since... specifically, the *default outbound for each domain has no hex zone extension* on it while all the others do...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Re: Issue with BinkD and outbound attempts.
By: Wilfred van Velzen to mark lewis on Sat Mar 28 2020 17:16:52

Are those active nets? I only recognise fsxnet...

AFAIK, they are... they've been gleaned from my mailer logs as presented
by systems connecting here or connected to from here... they match pretty
well with FTNs listed in other FTN lists, too...

That they are in systems configurations doesn't mean they are active...

TBH, that's someone else's problem... that they are defined and presented is what i care about... defining them in my setup also prevents (or seems to prevent) stray

ftn/outbound/fidonet.042

type directories from being created whether mail is received from zone 66 or not...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

On 03-28-20 12:54, Oli wrote to Tony Langdon <=-

Side effects?

You are right, it doesn't make any difference in my setup. This works fine:

domain fidonet /srv/ftn/outbound/fidonet 2
domain fsxnet /srv/ftn/outbound/fsxnet 2
domain amiganet /srv/ftn/outbound/amiganet 2

I thought binkd wouldn't be able to figure out which zone number maps
to which domain, but it doesn't seem to be a problem.

Yeah I was wondering, since I've run this way for years and no issues. Only difference is a matter of detail - my default zone is 3, rather than 2, but the principle is the same.

If binkd's <default-zone> parameter is intented to have the same
meaning as "the default zone" in FTS-5005 than using the same zone
number for all "domain" lines is the right configuration (and not a workaround). It is counterintuitive though and the example binkd.cfg
files suggests you should use the zone number of the network.

That's how I read the FTSC document myself (taking the wording literally), but it is open to interpretation, because there's a little ambiguityin the way it's written. A lot of writers make unstated assumptions that, if not addressed, can cause confusion. The ambiguity comes from which of two assumptions is intended:

1. There is one "default zone", global to your configuration.

2. There is one default zone per domain.

BinkD is behaving as though the author has made assumption #2 (but incorrectly drops the hex extension on the outbound). The way we've configured BinkD makes it follow assumption #1. And from what I can tell, other software seems to be fine with that.


... Save fuel. Get cremated with a friend.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

Hello mark!

i did (finally) find the text of a message where stas replied to me in reference to my questions about 5D while working on my 4DOS/4OS2 scripts... i think this was back in about 2011 going by the version of
his golded... unfortulately i cannot currently get to the actual
header of his message...

----->8 snip 8<-----

Hello mark.

25 Jul 12 17:04, you wrote to me:

eg:
domain fidonet x:\\bink\\outbound\\fidonet 1
domain quartz x:\\bink\\outbound\\quartz 123

X:\BINK\OUTBOUND\FIDONET
X:\BINK\OUTBOUND\FIDONET .002
X:\BINK\OUTBOUND\FIDONET .003
X:\BINK\OUTBOUND\FIDONET .004
X:\BINK\OUTBOUND\FIDONET .005
X:\BINK\OUTBOUND\FIDONET .006

OK

X:\BINK\OUTBOUND\QUARTZ .07B

Invalid, should be:
X:\BINK\OUTBOUND\QUARTZ

X:\BINK\OUTBOUND\QUARTZ .07C
X:\BINK\OUTBOUND\QUARTZ .07D

OK

the above indicates fidonet is zones 1,2,3,4,5,6 and quartz is
123,124,125??

Zone 123 specified as "default for the domain quartz" and outbound directory for 123:*@quartz should be without number in suffix.

and if i have foobar net with zone 124 (duplicate zone, different
domain) then...

domain fidonet x:\\bink\\outbound\\fidonet 1
domain quartz x:\\bink\\outbound\\quartz 123
domain foobar x:\\bink\\outbound\\foobar 124

X:\BINK\OUTBOUND\FIDONET
X:\BINK\OUTBOUND\FIDONET .002
X:\BINK\OUTBOUND\FIDONET .003
X:\BINK\OUTBOUND\FIDONET .004
X:\BINK\OUTBOUND\FIDONET .005
X:\BINK\OUTBOUND\FIDONET .006

OK

X:\BINK\OUTBOUND\FOOBAR .07C
X:\BINK\OUTBOUND\QUARTZ .07B

Invalid, should be:
X:\BINK\OUTBOUND\FOOBAR
X:\BINK\OUTBOUND\QUARTZ

X:\BINK\OUTBOUND\QUARTZ .07C
X:\BINK\OUTBOUND\QUARTZ .07D

OK

the above indicates fidonet is zones 1,2,3,4,5,6... foobar is
124... quartz is 123,124,125???

Stas
Jabber-ID: grumbler@grumbler.org
GPG key 0x72186DB9 (keyserver: hkp://wwwkeys.eu.pgp.net)
.!. Golded+, Husky & RNTrack maintainer, Binkd developer&webmaster
-!- GoldED+/LNX 1.1.5-b20110302
! Origin: Grumbler at home (2:5080/102.1)

----->8 snip 8<-----

i've taken and used the above as the definitive format for a proper 5D outbound directory layout ever since... specifically, the *default outbound for each domain has no hex zone extension* on it while all
the others do...

This is how MBSE works with a BSO outbound as well.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

If binkd's <default-zone> parameter is intented to have the same
meaning as "the default zone" in FTS-5005 than using the same zone
number for all "domain" lines is the right configuration (and not a
workaround). It is counterintuitive though and the example binkd.cfg
files suggests you should use the zone number of the network.

That's how I read the FTSC document myself (taking the wording literally),

but

it is open to interpretation, because there's a little ambiguityin the way

it's

written. A lot of writers make unstated assumptions that, if not

addressed,

can cause confusion. The ambiguity comes from which of two assumptions is intended:

1. There is one "default zone", global to your configuration.

2. There is one default zone per domain.

I don't see the ambiguity. The FTS-5005 is very clear about it:

How should Outbound Areas be named when domains are used?
As always, the outbound area for your primary address (including
domain) is the default outbound.

Separate Outbound Areas are needed for each Zone in each Domain.
These take an identical stem path to the primary outbound, except
that the name of the last sub-directory is changed to the
<abbreviation> parameter, plus the zone extension.

For example, if your default outbound is C:\BINK\OUTBOUND
for the outbound holding area (and you are in FidoNet), Amiganet
(zone 39) outbound mail would be held in the C:\BINK\AMIGANET.027
directory instead. Note that outbound areas for domains other than
your primary will ALWAYS have a zone extension, and that zone
extensions are always specified in Hexadecimal, up to .FFF (4095).

BinkD is behaving as though the author has made assumption #2 (but

incorrectly

drops the hex extension on the outbound). The way we've configured BinkD

makes

it follow assumption #1. And from what I can tell, other software seems

to be

fine with that.

There might be some use cases where #2 could be useful. Like having seperat tosser config for every domain/network (but then I would expect seperate inbounds too). I'm not sure this was the intention of the binkd developers or why they decided to do it differently than any other software.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

If binkd's <default-zone> parameter is intented to have the same
meaning as "the default zone" in FTS-5005 than using the same
zone number for all "domain" lines is the right configuration
(and not a workaround).

don't get confused by the chicken and the egg syndrome... binkd came first

and the

FTSC documents came after ;)

Before BinkD and FTS-5005 there was the original BinkleyTerm mailer that defined BSO in 1990. The FTSC documented the original BSO de facto standard. I wonder why the Binkd developers decided that they don't have to follow that standard in the sample binkd.cfg that is distributed with binkd.

i did (finally) find the text of a message where stas replied to me in

reference to

my questions about 5D while working on my 4DOS/4OS2 scripts... i think

this was

back in about 2011 going by the version of his golded... unfortulately i

cannot

currently get to the actual header of his message...

[...]

Hello mark.

25 Jul 12 17:04, you wrote to me:

Thanks, I found the thread, it starts here:

From : mark lewis 18 Jun 12 20:52:55
To : all
Subj : found something else...

some replies later I found this info:

binkd checks outbound/quartz.7B and outbound/quartz if both are exists.

So even if binkd creates a "othernet" directory it also checks "othernet.xxx" (if I understand it correctly).

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Re: Issue with BinkD and outbound attempts.
By: Tony Langdon to Oli on Sun Mar 29 2020 14:07:00

That's how I read the FTSC document myself (taking the wording
literally), but it is open to interpretation, because there's a
little ambiguityin the way it's written. A lot of writers make
unstated assumptions that, if not addressed, can cause confusion.
The ambiguity comes from which of two assumptions is intended:

1. There is one "default zone", global to your configuration.

this is standard 3D/4D... why? because there's only one base directory name used for the entire outbound directory structure...

2. There is one default zone per domain.

this is full/proper 5D... why? because each domain has its own base directory name for its outbound directories...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Issue with BinkD and outbound attempts.
By: Oli to Tony Langdon on Sun Mar 29 2020 11:57:21

I don't see the ambiguity. The FTS-5005 is very clear about it:

How should Outbound Areas be named when domains are used?
As always, the outbound area for your primary address (including
domain) is the default outbound.

Separate Outbound Areas are needed for each Zone in each Domain.
These take an identical stem path to the primary outbound, except
that the name of the last sub-directory is changed to the
<abbreviation> parameter, plus the zone extension.

For example, if your default outbound is C:\BINK\OUTBOUND
for the outbound holding area (and you are in FidoNet), Amiganet
(zone 39) outbound mail would be held in the C:\BINK\AMIGANET.027
directory instead. Note that outbound areas for domains other than
your primary will ALWAYS have a zone extension, and that zone
extensions are always specified in Hexadecimal, up to .FFF (4095).

this last paragraph is wrong for full and proper 5D BSO... what is described here is what i've been calling 4.5D (meaning four and a half dimension)...

i've already posted a binkd FAQ Q&A about this as well as one of the binkd developers' comments on how proper 5D is done in binkd...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Sun Mar 29 2020 12:50:11

don't get confused by the chicken and the egg syndrome... binkd
came first and the FTSC documents came after ;)

Before BinkD and FTS-5005 there was the original BinkleyTerm
mailer that defined BSO in 1990.

yes... this is true...

The FTSC documented the original BSO de facto standard.

document number, please... i'm unable to find any such document aside from FSP-1034/FRL-1034 which was the first attempt at documenting BSO back in like 2005... it wasn't picked up and anything done with it until 2014...

I wonder why the Binkd developers decided that they don't have
to follow that standard in the sample binkd.cfg that is
distributed with binkd.

what standard? please provide the document number...

also remember that binkleyterm is POTS while binkd is internet and the only thing common between them is the BSO...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

don't get confused by the chicken and the egg syndrome... binkd
came first and the FTSC documents came after ;)

Before BinkD and FTS-5005 there was the original BinkleyTerm
mailer that defined BSO in 1990.

yes... this is true...

The FTSC documented the original BSO de facto standard.

document number, please... i'm unable to find any such document aside from FSP-1034/FRL-1034 which was the first attempt at documenting BSO back in

like

2005... it wasn't picked up and anything done with it until 2014...

The document number is in the paragraph you've quoted

http://ftsc.org/docs/fts-5005.003

I wonder why the Binkd developers decided that they don't have
to follow that standard in the sample binkd.cfg that is
distributed with binkd.

what standard? please provide the document number...

also remember that binkleyterm is POTS while binkd is internet and the

only thing

common between them is the BSO...

POTS or TCP/IP, the only thing that matters is that BinkleTerm is the reference
implementation for 4D and 5D BSO.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Good ${greeting_time}, mark!

29 Mar 20 08:15, you wrote to me:

Re: Issue with BinkD and outbound attempts.
By: Oli to Tony Langdon on Sun Mar 29 2020 11:57:21

I don't see the ambiguity. The FTS-5005 is very clear about it:

How should Outbound Areas be named when domains are used?
As always, the outbound area for your primary address (including
domain) is the default outbound.

Separate Outbound Areas are needed for each Zone in each Domain.
These take an identical stem path to the primary outbound, except
that the name of the last sub-directory is changed to the
<abbreviation> parameter, plus the zone extension.

For example, if your default outbound is C:\BINK\OUTBOUND
for the outbound holding area (and you are in FidoNet), Amiganet
(zone 39) outbound mail would be held in the C:\BINK\AMIGANET.027
directory instead. Note that outbound areas for domains other than
your primary will ALWAYS have a zone extension, and that zone
extensions are always specified in Hexadecimal, up to .FFF (4095).

this last paragraph is wrong for full and proper 5D BSO... what is

described here

is what i've been calling 4.5D (meaning four and a half dimension)...

There is no such thing as 4.5D BSO. This is exactly what 5D BSO is, nothing wrong there. Just because some binkd developers decided that they have to invent their own flavor doesn't make the original format less 5D.

i've already posted a binkd FAQ Q&A about this as well as one of the binkd developers' comments on how proper 5D is done in binkd...

This wouldn't be the first developer that insists that their (flawed) interpretation and implementation of a (de facto or FTSC) standard is perfect and everyone else is wrong.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Sun Mar 29 2020 15:45:25

The FTSC documented the original BSO de facto standard.

document number, please... i'm unable to find any such document
aside from FSP-1034/FRL-1034 which was the first attempt at
documenting BSO back in like 2005... it wasn't picked up and
anything done with it until 2014...

The document number is in the paragraph you've quoted

then one of us is confused because BSO was never documented by the FTSC until starting in ~2005 while binkd was first released before 1997... binkd 0.9.2 was
released about then and i'm sure there were other earlier versions but that's the oldest one i have record of here...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Re: Issue with BinkD and outbound attempts.
By: Oli to mark lewis on Sun Mar 29 2020 15:57:21

this last paragraph is wrong for full and proper 5D BSO... what is
described here is what i've been calling 4.5D (meaning four and a
half dimension)...

There is no such thing as 4.5D BSO.

no shit... i'm calling it that BECAUSE it is half way between 4D and 5D...

This is exactly what 5D BSO is,

i'm sorry but you and the documentation are wrong... there is absolutely no reason for

1. hex zone on the default outbound directory per domain.
it is not needed on the global one in 3D/4D so why use
it in 5D?

2. having to lie to the most commonly used mailer to make
it work properly with broken software.


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

On 03-29-20 08:01, mark lewis wrote to Tony Langdon <=-

1. There is one "default zone", global to your configuration.

this is standard 3D/4D... why? because there's only one base directory name used for the entire outbound directory structure...

Yep, no argument on 3D/4D, used to run that way back in the day.

2. There is one default zone per domain.

this is full/proper 5D... why? because each domain has its own base directory name for its outbound directories...

And therein lies the issue, there seems to be no agreement as to whether domains other than the primary have a default zone. BinkD definitely recognises that, the FTSC apparently don't. Never having run 5D back in the day, I don't know how mailers like BinkleyTerm handled the situation, because I only ran 4D.


... I wondered why the baseball was getting bigger. Then it hit me!
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 03-29-20 10:41, mark lewis wrote to Oli <=-

then one of us is confused because BSO was never documented by the FTSC until starting in ~2005 while binkd was first released before 1997... binkd 0.9.2 was released about then and i'm sure there were other
earlier versions but that's the oldest one i have record of here...

BinkleyTerm still preceeds all of this. I was using it in 1992, and it was an established mailer back then (and it had 5D capabilities then too). So, one would logically assume that BinkleyTerm effectively contains the reference implementation of BSO.


... Bugs come in through open Windows.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

There is no such thing as 4.5D BSO.

no shit... i'm calling it that BECAUSE it is half way between 4D and 5D...

But what you call 4.5D BSO is what everyone else calls 5D BSO.

This is exactly what 5D BSO is,

i'm sorry but you and the documentation are wrong...

No, you are wrong :-P

there is absolutely no reason for

1. hex zone on the default outbound directory per domain.
it is not needed on the global one in 3D/4D so why use
it in 5D?

There are arguments for and against the hex extension / default zones per domain. I don't think that one is better than the other. The most important thing is that developers agree on one format. BinkleyTerm introduced that format and it was the reference implementation. Other software that was developed (long before Binkd was a thing) also implemented BinkleyTerm Style Outbound as later documented by the FTSC. There is no point in arguing today that it should be different. It is like it is.

2. having to lie to the most commonly used mailer to make
it work properly with broken software.

That's Binkd's problem ... Other software don't become broken just because Binkd invented its own BSO flavor.

--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

2. There is one default zone per domain.

this is full/proper 5D... why? because each domain has its own base
directory name for its outbound directories...

And therein lies the issue, there seems to be no agreement as to whether domains other than the primary have a default zone. BinkD definitely recognises that, the FTSC apparently don't. Never having run 5D back in

the

day, I don't know how mailers like BinkleyTerm handled the situation,

because I

only ran 4D.

There is broad agreement. Every other mailer and tosser software that supports 5D BSO uses the BinkleyTerm Outbound Style format described by FTS-5005. I used
BinkleyTerm and Squish with 5D BSO and I don't remember any difference to what we use today (with the expception of binkd).

I think the idea was that a 5D outbound is always in the format

domain.zzz/nnnnffff.xxx

and the only exception is the outbound for the default zone and domain, which follows the 2D/4D convention for compatibility reasons.


--- GoldED+/LNX 1.1.5-b20180707
* Origin: kakistocracy (2:280/464.47)

On 03-30-20 12:25, Oli wrote to Tony Langdon <=-

There is broad agreement. Every other mailer and tosser software that supports 5D BSO uses the BinkleyTerm Outbound Style format described by FTS-5005. I used BinkleyTerm and Squish with 5D BSO and I don't
remember any difference to what we use today (with the expception of binkd).

I do know Mystic works as you describe, and that's how I confirmed the binkd issue, when I was having trouble getting SBBSecho and binkd working together, so I looked to see what Mystic was doing, to get an idea how another (this time integrated) package was doing BSO.

I think the idea was that a 5D outbound is always in the format

domain.zzz/nnnnffff.xxx

and the only exception is the outbound for the default zone and domain, which follows the 2D/4D convention for compatibility reasons.

There certainly seems to be dispute, but this is how both of my systems are running.


... Paradox: We have more degrees but less sense.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)