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

 TL> Side effects?

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

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

 Ol> I thought binkd wouldn't be able to figure out which zone number maps
 Ol> 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.

 Ol> If binkd's  parameter is intented to have the same
 Ol> meaning as "the default zone" in FTS-5005 than using the same zone
 Ol> number for all "domain" lines is the right configuration (and not a
 Ol> workaround). It is counterintuitive though and the example binkd.cfg
 Ol> 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