REPLY: 1613.fido-binkd@3:633/410 22e560ff   
   MSGID: 2:280/464.47@fidonet 5e807101   
   CHRS: UTF-8 4   
   TZUTC: 0200   
   TID: CrashMail II/Linux 1.7   
    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.   
      
    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   
      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)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 226/30 227/114 229/101   
   SEEN-BY: 229/200 426 1014 240/5832 249/109 307 317 280/464 5003 5555   
   SEEN-BY: 288/100 292/854 310/31 342/200 396/45 423/120 712/848 770/1   
   SEEN-BY: 2452/250   
   PATH: 280/464 229/426