Subj : Candidates vision request
To   : Markus Reschke
From : Carol Shenkenberger
Date : Thu Dec 06 2018 08:13 pm

  Re: Candidates vision request
  By: Markus Reschke to Carol Shenkenberger on Wed Dec 05 2018 09:10 pm

 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
 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.

Like 'MOB' we have an undocumented difference.

  xxcarol
  
--- SBBSecho 2.12-Win32
 * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

.