= Сообщение: 5143 из 7128 ====================================== FTSC_PUBLIC = От : Ozz Nixon 1:1/123 06 Mar 20 22:26:57 Кому : Deon George 06 Mar 20 22:26:57 Тема : Two changes to BinkP inquiry... FGHI : area://FTSC_PUBLIC?msgid=1:1/123.0+5E62CCBF На : area://FTSC_PUBLIC?msgid=1441.fdn_ftscpubl@3:633/509+22c4581a = Кодировка сообщения определена как: ASCII ================================== ============================================================================== >I'm not sure I understand the value of this one - if the server wants to not >reveal who it is first (because the sysop doesnt want the connect mailer to >know it is part of secret network), is it possible that the client would want >that as well (not to reveal which network its a part of until the server >reveals itself)?
I am replying to this as a different line of thought. Per the "M_ADR", when a client is polling, sending a file, requesting a file.
1. If I am polling, then I should present first "whom" I think I am polling in my M_ADR list... as 99.9% of the time its to pickup mail. 2. If I am sending a file, then I would present my M_ADR of the network I am part of that is relative to the receiver... 99.9% of the time sending my outbound mail. 3. If I am requesting a file, then I would present first "whom" I think I am polling (meaning NETWORK not their ADR).
With that in mine, then the listener would not send any M_ADR information until the client has presented it's networks that it thinks or knows we have in common. Even in the original BInkP proposal it does address in one of the state machine examples ~ waiting for the M_ADR from the originator. My thought is ~ why not have an option that the answering side only presents "matching" zones in it's M_ADR reply. Again, for security reasons ~ it's not "scientific" but every level of prevention and protection helps.
