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
CS>> is not black and white.
MR> Putting on my software developer hat, I'm quite unhappy with such
MR> undocumented features. I've written a small tool to extract the binkp
MR> nodes from the nodelist. The FTSC documentation states that the IBN flag
MR> should carry a FQDN/IP when binkd is accepting calls only on that FQDN/IP
MR> and it's different from the FQDN/IP in the INA flag. Or in other words,
MR> the FQDN/IP in the IBN flag prevails and no other address should be called
MR> by binkd. In your case the tool would take just shenks.dyndns.org as
MR> explained above. But with the undocumented feature I would have to add a
MR> special case which also takes shenks.synchro.net as second address. The
MR> big problem is that I can't know which nodelist entry follows the FTSC
MR> docs and which one follows the undocumented feature. To resolve this
MR> delemma we would need a new flag indicating which method applies (standard
MR> or undocumented feature). Or we could simply follow the FTSC documented
MR> standard. These are things we have to take into account when creating zone
MR> specific special features. They can lead to unexpected results. In this
MR> case no nodelist-to-binkd converter is able to extract the correct
MR> addresses because there is no way to figure out which "standard" was used
MR> for a specific node.
Yes Markus, we live in an imperfect world. I want to help refine how a dual
adress is listed. To not list the secondary (when outage of the primary) is a
problem.
