Re: Two changes to BinkP inquiry...
  By: Ozz Nixon to ALL on Mon Mar 02 2020 12:33 pm

Hey Ozz,

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

 ON> accepts a connection and sends the MD5 CRAM and waits. If I do not
 ON> receive a MsgHdr Len M_ then I assume (a) User, (b) port
 ON> 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?

 ON> The other part of the workflow change is not to present all M_ADR as a
 ON> couple networks I have joined prefer to be a little more under the
 ON> radar ~ the easy way to help improve this would be to require the
 ON> client (polling process) to share the address(es) associated with the
 ON> connection it is expecting (incase we share two or more networks and
 ON> 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