MV>> Can you tell us according to what part(s) of which FTSC standard(s) MV>> this nodelist entry contains information that is never used by a MV>> properly configured mailer?
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.
Putting on my software developer hat, I'm quite unhappy with such undocumented features. I've written a small tool to extract the binkp nodes from the nodelist. The FTSC documentation states that the IBN flag should carry a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's different from the FQDN/IP in the INA flag. Or in other words, the FQDN/IP in the IBN flag prevails and no other address should be called by binkd. In your case the tool would take just shenks.dyndns.org as explained above. But with the undocumented feature I would have to add a special case which also takes shenks.synchro.net as second address. The big problem is that I can't know which nodelist entry follows the FTSC docs and which one follows the undocumented feature. To resolve this delemma we would need a new flag indicating which method applies (standard or undocumented feature). Or we could simply follow the FTSC documented standard. These are things we have to take into account when creating zone specific special features. They can lead to unexpected results. In this case no nodelist-to-binkd converter is able to extract the correct addresses because there is no way to figure out which "standard" was used for a specific node.
