Subj : Re: Issue with BinkD and outbound attempts. To : Oli From : Tony Langdon Date : Sun Mar 29 2020 02:07 pm -=> 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 * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410) .