• Two changes to BinkP inquiry...

    From Ozz Nixon@1:1/123 to ALL on Monday, March 02, 2020 12:33:36
    Now that my mailer (listener) and poller (client) are in production on
    a few sites ~ and I have joined a couple of networks that wish to be
    "under the radar". I wanted to check around about 2 possibly changes to
    the BinkP protocol.

    Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

    Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3

    Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

    Optional support for .REQ files could stay for backward compatability.
    However, this approach would help define an M_REQ means a POLL request,
    instead of how it is documented now, as a if you didn't get any M_FILE
    from the client, it must be assumed as being a POLL.

    The other change to the BinkP protocol - really applies to the workflow
    of the protocol ~ for example, if you telnet to my BinkP mailer, it
    accepts a connection and sends the MD5 CRAM and waits. If I do not
    receive a MsgHdr Len M_<command> then I assume (a) User, (b) port
    scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

    The other part of the workflow change is not to present all M_ADR as a
    couple networks I have joined prefer to be a little more under the
    radar ~ the easy way to help improve this would be to require the
    client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
    said connection is my uplink/downlink). This tweak of course is
    optional for products still in development ~ but adds a small layer of anonymity for said networks.

    I am in the process of implementing these changes to the systems
    running my mailer, so we can iron out any quirks. However, it was
    suggested that I present my thoughts in FTSC_PUBLIC.

    Ozz Nixon
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Deon George@3:633/509 to Ozz Nixon on Wednesday, March 04, 2020 14:11:53
    Re: Two changes to BinkP inquiry...
    By: Ozz Nixon to ALL on Mon Mar 02 2020 12:33 pm

    Hey Ozz,

    Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

    This sounds OK to me - how is it different to REQ, ie: why is it better, or why
    does it need to change?

    accepts a connection and sends the MD5 CRAM and waits. If I do not
    receive a MsgHdr Len M_<command> then I assume (a) User, (b) port
    scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

    What happens when it is a) User or c) EMSI - is it your intention that binkp becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch the BBS login screen. For the later, C) EMSI, is it enabling EMSI on the binkp port? Why would this be needed over just connecting to a different port that serves EMSI?

    The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
    radar ~ the easy way to help improve this would be to require the
    client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
    said connection is my uplink/downlink). This tweak of course is

    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)?

    Maybe I dont understand the value..?

    I like the ideas though - we should see more of them ... :)
    ...deon


    ... Liberals are a Labour-saving device.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Alexey Vissarionov@2:5020/545 to Ozz Nixon on Wednesday, March 04, 2020 07:22:22
    Good ${greeting_time}, Ozz!

    02 Mar 2020 12:33:36, you wrote to ALL:

    Now that my mailer (listener) and poller (client) are in production
    on a few sites ~ and I have joined a couple of networks that wish
    to be "under the radar". I wanted to check around about 2 possibly
    changes to the BinkP protocol.

    Proposals for the binkp protocol should be filed as a pull request for its' reference implementation - the binkd mailer.

    If something is not in the binkd, it's not in the binkp.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... god@universe:~ # cvs up && make world
    --- /bin/vi
    * Origin: http://openwall.com/Owl (2:5020/545)
  • From Ward Dossche@2:292/854 to Ozz Nixon on Wednesday, March 04, 2020 06:00:35
    I wanted to check around about 2 possibly changes to the BinkP protocol.

    Are you certain you're barking up the right tree ?

    \%/@rd

    --- D'Bridge 4
    * Origin: If you build it he will come (2:292/854)
  • From Andrew Leary@1:320/219 to Ozz Nixon on Wednesday, March 04, 2020 02:10:49
    Hello Ozz!

    02 Mar 20 12:33, you wrote to all:

    Now that my mailer (listener) and poller (client) are in production on
    a few sites ~ and I have joined a couple of networks that wish to be "under the radar". I wanted to check around about 2 possibly changes
    to the BinkP protocol.

    You are free to implement your changes in your software, although you should attempt to do so in a manner that will not affect compatibility with existing mailers.

    Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

    Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3

    Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

    Optional support for .REQ files could stay for backward compatability.

    .REQ files are currently the standard method of requesting files in FTN networks, used by both POTS mailers (ie. FTS-6 and EMSI) and most BinkP mailers. In some cases the mailer may rely on an external request processor to handle received .REQ files; binkd is an example of such a mailer. It should also be noted that you cannot assume a node supports file requests unless it flies a FREQ flag (XA/XB/XC/XP/XR/XW/XX) in the nodelist. You also don't indicate if your proposal will include any support for update requests as defined in FTS-6 (WaZOO) and FTS-8 (Bark).

    The other change to the BinkP protocol - really applies to the
    workflow of the protocol ~ for example, if you telnet to my BinkP
    mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
    do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
    port scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

    As binkd is the reference implementation (and most widely used) of the BinkP protocol, this should really be discussed with the binkd developers. I can tell you that if your change is not added to binkd, it is highly unlikely that it will ever meet the "widespread use" requirement for documentation as a FidoNet Technical Standard by the FTSC.

    The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
    radar ~ the easy way to help improve this would be to require the
    client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
    said connection is my uplink/downlink). This tweak of course is
    optional for products still in development ~ but adds a small layer of anonymity for said networks.

    Some BinkP mailers already can be configured to selectively choose which AKAs to present to the remote system. binkd has the hide-aka and present-aka keywords in the configuration file.

    I am in the process of implementing these changes to the systems
    running my mailer, so we can iron out any quirks. However, it was suggested that I present my thoughts in FTSC_PUBLIC.

    You need to test your changes thoroughly to ensure that they do not cause any issues for other software used in FidoNet.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Joachim Probst@2:240/6309 to Ozz Nixon on Wednesday, March 04, 2020 18:15:34
    Hello Ozz!

    02 Mar 20 12:33, you wrote to all:

    Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
    Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
    Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

    Optional support for .REQ files could stay for backward compatability. However, this approach would help define an M_REQ means a POLL
    request, instead of how it is documented now, as a if you didn't get
    any M_FILE from the client, it must be assumed as being a POLL.

    Could you please elaborate in the advantage of this? As far as I see the FTS for binkp, both sides send their files, ready for sending, after the session setup is finished with M_OK. After that part is does not matter if it was a poll or a dialout. The only advantage I see, is the receiving mailer does not have to check for *.req naming of the file, for serving the file request within
    the same session, but can deceide on the command. I am not sure, if that would initiate me to think about a protocol change.

    The other change to the BinkP protocol - really applies to the
    workflow of the protocol ~ for example, if you telnet to my BinkP
    mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
    do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
    port scanner, (c) EMSI Session (because I could send **REQ before the CRAM.

    I go along with the comment of why wanting to turn the mailer into a frontdoor as IP with it ports does not need such a mechanism to allow multiple services on the same machine.

    One advantage I see in the binkp protocol is that it is so very simple.

    The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
    radar ~ the easy way to help improve this would be to require the
    client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
    said connection is my uplink/downlink). This tweak of course is
    optional for products still in development ~ but adds a small layer of anonymity for said networks.

    Nice idea, like that part, but I do not see the necessaty of a protocol change.
    FTS does not request that you show all addresses you have. It just requests that the originating side does not wait for any response before sending M_PWD and that for password checking all presented addresses (by the originating side, no other makes sense) are using the same password, if any.

    The originating side could just present the networks it wants to present (hiding akas is already sugested in the FTS for the purpose of working with different passwords on different akas). If the answering side only presents 'public' akas and akas fitting to those presented by the originating side, I do
    not see any violence of the current binkp protocol and can see no harm to the network, too. Maybe I am overlooking something?

    Ozz Nixon
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

    Greetings,
    Joachim

    --- GoldED+/LNX 1.1.5--b20170303
    * Origin: ----> FidoPI (2:240/6309)
  • From Ozz Nixon@1:1/123 to Deon George on Friday, March 06, 2020 22:19:48
    Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

    This sounds OK to me - how is it different to REQ, ie: why is it better, or >why does it need to change?

    a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.

    So, yes, I am more FrontDoor oriented in my head. So, instead of
    dropping a <unique>.REQ - my poll command can also act as a REQ
    command. We are using it for software updates ~ and I pondered, as a
    n00b reading the specs, and implementing them over the past 2 years ~
    that it helps clarify what the original draft has about doing a FREQ
    during the negotiation phase. And as a n00b looking at the specs and
    the workflow of the BSO environments ~ why would I receive an empty pkt
    from a system that was forcing a poll. * Not all systems do this, but,
    a couple have.

    b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
    poll. If LEN>1 then its a CVS string of 1 or more requests. And to keep
    with security (.REQ lacks) if the M_REQ file is passworded, the system
    cound using the same MD5-CRAM logic for the individual file
    password(s). Why? Security.

    What happens when it is a) User or c) EMSI - is it your intention that binkp >becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch >the BBS login screen. For the later, C) EMSI, is it enabling EMSI on the
    binkp
    port? Why would this be needed over just connecting to a different port that >serves EMSI?

    * For systems that the Mailer/BBS work as one ~ yes, I let the user
    login - like a "FroDo" design (and MANY other systems).

    One port vs multiple ports. Security acceptance. The companies I have
    worked for over the years, network CISO do not like to open multiple
    ports for any reason. And while many may run a BBS at home ~ in the
    corporate world, it would be nice to see the BBS and the MAILER serve a
    purpose again.

    So part of my question/inquiry was to see if anyone sees a value or
    not for the protocol itself. I do, but, I am that American guy who
    develops on his production system... ;-)

    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Ozz Nixon@1:1/123 to Deon George on Friday, March 06, 2020 22:26:57
    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.

    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Ozz Nixon@1:1/123 to Joachim Probst on Friday, March 06, 2020 22:35:46
    Nice idea, like that part, but I do not see the necessaty of a protocol >change. FTS does not request that you show all addresses you have. It just >requests that the originating side does not wait for any response before >sending M_PWD and that for password checking all presented addresses (by the >originating side, no other makes sense) are using the same password, if any.

    The originating side could just present the networks it wants to present >(hiding akas is already sugested in the FTS for the purpose of working with >different passwords on different akas). If the answering side only presents >'public' akas and akas fitting to those presented by the originating side, I >do not see any violence of the current binkp protocol and can see no harm to >the network, too. Maybe I am overlooking something?

    * Okay, it may not be a protocol improvement ~ however, as you see, it introduces a little layer of security ~ which they want to achieve.
    However, if it was mentioned in the specification that you do not have
    to present all of your addresses (to me AKAs is wrong wording) you
    could simply reply wiht the matching zones ~ so M_PWD can proceed as
    planned. And a snoopy nose does not see, oh, he's a member of 666
    network.

    Now you mention matching passwords ~ I will ask a OPT MPWD question.

    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Ward Dossche@2:292/854 to Ozz Nixon on Saturday, March 07, 2020 10:21:29
    a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.

    With all due respect, are you not in the wrong echo ?

    \%/@rd

    --- D'Bridge 4
    * Origin: If you build it he will come (2:292/854)
  • From Joachim Probst@2:240/6309 to Ozz Nixon on Saturday, March 07, 2020 10:59:22
    Hello Ozz!

    06 Mar 20 22:19, you wrote to Deon George:

    b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
    poll. If LEN>1 then its a CVS string of 1 or more requests. And to
    keep with security (.REQ lacks) if the M_REQ file is passworded, the system cound using the same MD5-CRAM logic for the individual
    file password(s). Why? Security.

    *.req files follow the FTS-0006.002 guideline of file requests. That file format is supporting passwords. Each line in the *.req file starts with the filename of the requested file and may be followed by a blank, an exclamation mark and the password.

    Following you line with M_REQ and line length 1 or more, or no line. This would
    mean, you do not only use M_REQ just for a file request, but also for initiating a general poll. THIS is - I think - no good, as it clutters a fairly
    simple protocol with some implicit stuff.

    I can understand (even so I think it is not needed) to have M_REQ to superceed the old *.req file. But in that case it should be only file requests and not a hidden mechanism on top.

    What happens when it is a) User or c) EMSI - is it your intention
    that binkp becomes a "frontdoor", and if it isnt a mail (in the case
    of a) - you launch the BBS login screen. For the later, C) EMSI, is
    it enabling EMSI on the
    binkp
    port? Why would this be needed over just connecting to a different
    port that serves EMSI?

    * For systems that the Mailer/BBS work as one ~ yes, I let the user
    login - like a "FroDo" design (and MANY other systems).

    One port vs multiple ports. Security acceptance. The companies I have worked for over the years, network CISO do not like to open multiple
    ports for any reason. And while many may run a BBS at home ~ in the corporate world, it would be nice to see the BBS and the MAILER serve
    a purpose again.

    I might be not in my master part of competance, but security should be much better with a single protocol on a single port. Why? I can watch the port traffic and easily see a protocol misuse. When running multiple protocols on the same port I lack the posibility. Having the FrontDoor mechanism and EMSI headers and so on is a relict of having only one physical port so that you had to split for different protocols later. So here I clearly would vote against supporting this. Once for security reasons, second not to make the protocol more complicated.

    Ozz

    Joachim


    --- GoldED+/LNX 1.1.5--b20170303
    * Origin: ----> FidoPI (2:240/6309)
  • From Joachim Probst@2:240/6309 to Ozz Nixon on Saturday, March 07, 2020 11:16:22
    Hello Ozz!

    06 Mar 20 22:35, you wrote to me:

    Nice idea, like that part, but I do not see the necessaty of a
    protocol change. FTS does not request that you show all addresses you
    have. It just requests that the originating side does not wait for
    any response before sending M_PWD and that for password checking all
    presented addresses (by the originating side, no other makes sense)
    are using the same password, if any.

    The originating side could just present the networks it wants to
    present (hiding akas is already sugested in the FTS for the purpose
    of working with different passwords on different akas). If the
    answering side only presents 'public' akas and akas fitting to those
    presented by the originating side, I do not see any violence of the
    current binkp protocol and can see no harm to the network, too. Maybe
    I am overlooking something?

    * Okay, it may not be a protocol improvement ~ however, as you see, it introduces a little layer of security ~ which they want to achieve. However, if it was mentioned in the specification that you do not have
    to present all of your addresses (to me AKAs is wrong wording) you
    could simply reply wiht the matching zones ~ so M_PWD can proceed as planned. And a snoopy nose does not see, oh, he's a member of 666
    network.

    So, we just told the same. And I do not see, where it is a change in protocol. As origin and answering side are not doing anything with akas they can not match, it is no problem not presenting these akas. That means, we do not have a
    change in protocol, but only a more sofisticated handling of akas by the software. I like it. I would not have a use case for that upto now, but I like it.

    Ozz

    Joachim


    --- GoldED+/LNX 1.1.5--b20170303
    * Origin: ----> FidoPI (2:240/6309)
  • From Ozz Nixon@1:1/123 to Joachim Probst on Monday, March 09, 2020 05:16:41
    *.req files follow the FTS-0006.002 guideline of file requests. That file >format is supporting passwords. Each line in the *.req file starts with the >filename of the requested file and may be followed by a blank, an exclamation >mark and the password.

    M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure
    protocol over insecure sessions. The HMAC repliy from the originator
    makes it next to impossible for MTM packet snooping like you have
    mentioned to monitor how a protocol is working (which only happens over insecure sessions), thus your *.REQ file with its antiquated !pwd would
    allow MTM attacks to see a password in plain text. My concept avoids
    this, as the M_REQ password on a HMAC session cannot be "replayed", it
    was only valid for that session.

    Having multiple handshakes on a single port, I understand can muddy the
    water, however, the companies I have worked for, getting more than one
    protocol port open on the front-end firewall is a challenge let along
    security compliance requirements for auditing the need for multiple
    ports.

    I have successfully communicated with a FroDo 2.33ml using the
    **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still
    receive my BinkP mail also. So, it does not seem to "break" either
    protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
    or EMSI, or whatever else may still be in operation. Ports can trigger
    off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
    the BinkP only environments that may or may not be running a BBS.

    We have implemented the M_REQ string on 6 systems and as of 0000 GMT
    today, I have released the next Alpha round of my software to those 6,
    and 10+ systems are scheduled to go inline this week ~ if I see a
    problem, I will note it here, however, so far so good. ;-)

    Thank you for your eyes/thoguhts!
    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Ozz Nixon@1:1/123 to Ward Dossche on Monday, March 09, 2020 05:20:40
    With all due respect, are you not in the wrong echo ?

    I do not know - am I in the wrong echo for acking something that is
    related to FTSC documents, may require some wording changes, etc.? Its
    not an FTSC submission, it is not a BINKD patch, it is not a BinkP (oh
    no echo for this) topic yet, and my NET_DEV echo has been empty for
    almost 2 years. ~~ so I assumed this would be the best place to get
    all the kickback on a change ~~~ ;-)

    Ozz
    --- Legacy/X FTN Tosser/JAM v1-Alpha6
    * Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)
  • From Alexey Vissarionov@2:5020/545 to Ozz Nixon on Tuesday, March 10, 2020 12:36:24
    Good ${greeting_time}, Ozz!

    09 Mar 2020 05:20:40, you wrote to Ward Dossche:

    I do not know - am I in the wrong echo for acking something that is related to FTSC documents, may require some wording changes, etc.?
    Its not an FTSC submission, it is not a BINKD patch, it is not a
    BinkP (oh no echo for this)

    The binkp protocol is discussed in RU.Binkd
    Obviously, only in Russian: this safely keeps away people like you.

    topic yet, and my NET_DEV echo has been empty for almost 2 years.
    so I assumed this would be the best place to get all the kickback
    on a change

    You could notice that nobody of binkd|binkp developers answered you.
    Guess why :-)


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... that's why I really dislike fools.
    --- /bin/vi
    * Origin: http://openwall.com/Owl (2:5020/545)
  • From Deon George@3:633/509 to Alexey Vissarionov on Tuesday, March 10, 2020 21:35:02
    Re: Two changes to BinkP inquiry...
    By: Alexey Vissarionov to Ozz Nixon on Tue Mar 10 2020 12:36 pm

    The binkp protocol is discussed in RU.Binkd
    Obviously, only in Russian: this safely keeps away people like you.
    You could notice that nobody of binkd|binkp developers answered you.
    Guess why :-)

    Why?
    ...deon


    ... If you think education is expensive, try ignorance.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Joachim Probst@2:240/6309 to Ozz Nixon on Thursday, March 12, 2020 17:21:58
    Hello Ozz!

    09 Mar 20 05:16, you wrote to me:

    *.req files follow the FTS-0006.002 guideline of file requests. That
    file format is supporting passwords. Each line in the *.req file
    starts with the filename of the requested file and may be followed by
    a blank, an exclamation mark and the password.

    M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure protocol over insecure sessions. The HMAC repliy from the originator
    makes it next to impossible for MTM packet snooping like you have mentioned to monitor how a protocol is working (which only happens
    over insecure sessions), thus your *.REQ file with its antiquated !pwd would allow MTM attacks to see a password in plain text. My concept
    avoids this, as the M_REQ password on a HMAC session cannot be
    "replayed", it was only valid for that session.

    Yes, see that. Ok, that would be a pro to have file requests within the sesison
    scope of the transmission for this reason!

    Having multiple handshakes on a single port, I understand can muddy
    the water, however, the companies I have worked for, getting more than
    one protocol port open on the front-end firewall is a challenge let
    along security compliance requirements for auditing the need for
    multiple ports.

    I have successfully communicated with a FroDo 2.33ml using the **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still receive my BinkP mail also. So, it does not seem to "break" either protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
    or EMSI, or whatever else may still be in operation. Ports can trigger
    off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
    the BinkP only environments that may or may not be running a BBS.

    I did not think about possibilities. I had been using FroDo in my former Fido time on calling lines. As I said, there it was even necessary to get it working
    at all.

    For today on IP lines, I just do not see the advantage for the more complex (it
    is more complex) and more implicit asumptions to the nodelist. It's - in my eyes - a protocol change for personal view to a topic without getting an objective advantage for everyone.

    So I still will keep not going along with you in this part. You see more advantages, I see no advantages being worth a protocol change :)

    Thank you for your eyes/thoguhts!
    Ozz

    Joachim


    --- GoldED+/LNX 1.1.5--b20170303
    * Origin: ----> FidoPI (2:240/6309)
  • From Joachim Probst@2:240/6309 to Alexey Vissarionov on Thursday, March 12, 2020 17:30:06
    Hello Alexey!

    10 Mar 20 12:36, you wrote to Ozz Nixon:

    The binkp protocol is discussed in RU.Binkd
    Obviously, only in Russian: this safely keeps away people like you.

    Will not say anything to that part ...

    topic yet, and my NET_DEV echo has been empty for almost 2 years.
    so I assumed this would be the best place to get all the kickback
    on a change

    You could notice that nobody of binkd|binkp developers answered you.
    Guess why :-)

    ... but, as binkp is part of the ftsc, THAT more looks like (as long as you don't know of active developers on binkp due to no international echo) no one is caring about it any more.

    I'm not with all of his points, but some make sens as far as I can see or follow his arguments. If not, well, if there ARE developers on binkp currently,
    it may be good to here them on international ground, as the protocol is used internationally. Wouldn't it?

    Joachim

    --- GoldED+/LNX 1.1.5--b20170303
    * Origin: ----> FidoPI (2:240/6309)