Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    BINKD    |    Support for the Internet BinKD mailer    |    8,958 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 6,707 of 8,958    |
|    Oli to Tony Langdon    |
|    Issue with BinkD and outbound attempts.    |
|    28 Mar 20 12:54:59    |
      REPLY: 1606.fido-binkd@3:633/410 22e468e1       MSGID: 2:280/464.47@fidonet 5e7f3fdd       CHRS: UTF-8 4       TZUTC: 0100       TID: CrashMail II/Linux 1.7        Ol>>> but Binkd is omitting the zone number after the dot.               TL>> Unless you use the same default zone (for most people, your Fidonet zone)        TL>> for all domain entries.               Ol>> But it's a workaround with side effects. Why do we have a default zone        Ol>> number in the first place, when the only way to get standard conformat        Ol>> 5D BSO directories is by deliberately putting wrong zone numbers in the        Ol>> config?               TL> 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/f       n/binkd/binkd.cfg        12:59 [16912] creating a poll for 39:15/0@amiganet (`d' flavour)               TL> And I note that the FTSC document you referenced only talks        TL> about "the default zone", but doesn't qualify it as being for a domain       (which        TL> you would expect). So there's assumptions there.              If binkd's |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca