Hi Carol!

Dec 04 21:46 2018, Carol Shenkenberger wrote to Michiel van der Vlist:

 MV>> 300,XX,CM,INA:shenks.synchro.net,IBN:shenks.dyndns.org

 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.

ciao,
Markus

---