= Сообщение: 4082 из 7124 ====================================== FTSC_PUBLIC = От : mark lewis 1:3634/12.73 09 Dec 18 10:28:46 Кому : Markus Reschke 09 Dec 18 10:28:46 Тема : Candidates vision request FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.73+5c0d408b На : area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f70 = Кодировка сообщения определена как: CP437 ================================== Ответ: area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f7c ============================================================================== On 2018 Dec 05 21:10:56, you wrote to Carol Shenkenberger:
CS>> What standards do you show to represent when a site has 2 resolving CS>> addresses, one preferred for IBN but the other for everything? Z1 CS>> practical resolution, yet another thing not documented. The world is CS>> not black and white.
MR> Putting on my software developer hat, I'm quite unhappy with such MR> undocumented features.
what undocumented features? IIRC, binkd was the first to offer this capability... you can easily list multiple semicolon separated domains in the NODE lines...
MR> I've written a small tool to extract the binkp nodes from the MR> nodelist. The FTSC documentation states that the IBN flag should carry MR> a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's MR> different from the FQDN/IP in the INA flag. Or in other words, the MR> FQDN/IP in the IBN flag prevails and no other address should be called MR> by binkd.
that's now how binkd works... it cycles through the presented domains...
MR> In your case the tool would take just shenks.dyndns.org as explained MR> above. But with the undocumented feature I would have to add a special MR> case which also takes shenks.synchro.net as second address.
binkd (and argus/radius/taurus) nodelist tools do this without any problem... i remember when Jerry Schwartz was writing the binkd_nodelister.pl script and how he asked questions of the FTSC about this very thing with multiple domains in a nodelist line... it was decided at that time to list all the domains found in the specified fields and write them in a semicolon separated list to the binkd configuration file like binkd worked with... other nodelist convertors would list the multiple domains in a manner consistent with the mailer(s) they support... if the mailer doesn't have support for multiple domains, then the convertor tool would choose the proper one for that mailer...
MR> The big problem is that I can't know which nodelist entry follows the MR> FTSC docs and which one follows the undocumented feature. To resolve MR> this delemma we would need a new flag indicating which method applies MR> (standard or undocumented feature). Or we could simply follow the FTSC MR> documented standard.
this additional flag thing is overengineering... it isn't needed... mailers use the available domains listed in the specified nodelist fields... they've done this for a long time... i tested argus/radius/taurus with multiple domains and also POTS and they cycled through each domain and the POTS until a connection was made... binkd does the same except that it doesn't do POTS...
MR> These are things we have to take into account when creating zone MR> specific special features. They can lead to unexpected results. In MR> this case no nodelist-to-binkd converter is able to extract the MR> correct addresses because there is no way to figure out which MR> "standard" was used for a specific node.
really??? these 81 multiple domain entries from BINKD.TXT would seem to disagree with you...
the distributed ARGUS.TXT also has multiple domain entries but that convertor script seems to miss the INA entries... maybe it is protocol oriented so it only works with the domains attached to an IP flag?? if that's the case, it also misses the entries with the domain in the system field (not attached to a flag) as well as those attached to the INA flag... i don't know for sure as i've not used the convertor that scott little uses to create said distributed file... scott would have the answer as to why argus.txt has different output than binkd.txt...
Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... In the beginning there was nothing, which exploded. --- * Origin: (1:3634/12.73)
