Hello Ozz!

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

 ON> b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
 ON> poll. If LEN>1 then its a CVS string of 1 or more requests. And to
 ON> keep with security (.REQ lacks) if the M_REQ file is passworded, the
 ON> system cound using the same MD5-CRAM logic for the individual
 ON> 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
 ON> binkp
 >> port? Why would this be needed over just connecting to a different
 >> port that serves EMSI?

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

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

 ON> Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303