= Сообщение: 4047 из 7124 ====================================== FTSC_PUBLIC = От : Carol Shenkenberger 1:275/100 06 Dec 18 20:13:18 Кому : Markus Reschke 06 Dec 18 20:13:18 Тема : Candidates vision request FGHI : area://FTSC_PUBLIC?msgid=6863.ftsc_pub@1:275/100+206f19fd На : area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f70 = Кодировка сообщения определена как: ASCII ================================== ============================================================================== Re: Candidates vision request By: Markus Reschke to Carol Shenkenberger on Wed Dec 05 2018 09:10 pm
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.
