Subj : Issue with BinkD and outbound attempts.
To   : Tony Langdon
From : Oli
Date : Sun Mar 29 2020 11:57 am

 Ol>> If binkd's <default-zone> 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.

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

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

 TL> 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).

 TL> BinkD is behaving as though the author has made assumption #2 (but 
incorrectly
 TL> drops the hex extension on the outbound).  The way we've configured BinkD 
makes
 TL> it follow assumption #1.  And from what I can tell, other software seems 
to be
 TL> 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)

.