Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 4083 из 7124 ====================================== FTSC_PUBLIC =
От   : mark lewis                       1:3634/12.73       09 Dec 18 11:19:28
Кому : Michiel van der Vlist                               09 Dec 18 11:19:28
Тема : Candidates vision request
FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.73+5c0d424e
На   : area://FTSC_PUBLIC?msgid=2:280/5555+5c0865ed
= Кодировка сообщения определена как: CP437 ==================================
==============================================================================
 On 2018 Dec 06 00:38:36, you wrote to Carol Shenkenberger:

MV> From FTS-5001.006:

MV>   INA           This flag sets a default server address used
MV>                  for any Internet Protocol Flag that does not
MV>                  specify its own.

MV> So, a properly configured binkp mailer will see that the IBN flag
MV> carries a server address. It will use that and nothing alse to
MV> connect.

i think you mean a properly programmed binkp mailer...

MV> A binkp mailer will NOT look at the INA flag since that is to be used
MV> for any other protocol who's flag has no server address of its own.

binkd doesn't know anything about nodelist flags... it (mainly) depends on its
nodelist... a nodelist that is created by some convertor tool... the most
commonly used tool pulls and lists all the domains from the proper fields and
flags and lists them in the NODE lines... multiple domains separated by
semicolons are no problem for binkd...

MV> But there are no other IP protocol flags. So no mailer will ever use
MV> the server address from the INA flag. The INA flag is dead wood. It is
MV> "unreachable code".

sorry but it is not...

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.

MV> It /IS/ documented. FTS-5001.006:

MV>   Multihomed systems
MV>   ------------------

MV>   Multihomed systems or systems that are otherwise reacheable by more
MV>   than one address, may - instead of adding another A or AAAA record
MV>   to the DNS zone of the host name - repeat the flag(s) carrying the
MV>   address with another address.

MV>   Example: IBN:host1.example1.tld,IBN:host2.example2.tld
MV>   Or:      INA:host1.example1.tld,INA:host2.example2.tld,IBN

well, there ya go... there's nothing wrong with xxcarol's nodelist line...

MV> This was discussed by the FTSC members in the Private FTSC area in 2017.
MV> You are an FTSC member, you were there. Apparently you did not pay
MV> attention.

or maybe she didn't retain that just like you don't always remember things...
or have you also not been paying attention in the past? like maybe back in
2005-2007 when Jerry Schwartz was working on the binkd_nodelister.pl script
which is now the standard conversion script from the St.Louis nodelist format
to the binkd node list format??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Buy a rope and shoot yourself where the water is deepest.
---
* Origin:  (1:3634/12.73)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.056050 секунды