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_<command> 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 * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
