= Сообщение: 5147 из 7128 ====================================== FTSC_PUBLIC = От : Joachim Probst 2:240/6309 07 Mar 20 10:59:22 Кому : Ozz Nixon 07 Mar 20 10:59:22 Тема : Two changes to BinkP inquiry... FGHI : area://FTSC_PUBLIC?msgid=2:240/6309+5e637427 На : area://FTSC_PUBLIC?msgid=1:1/123.0+5E62C9A0 = Кодировка сообщения определена как: LATIN1 ================================= Ответ: area://FTSC_PUBLIC?msgid=1:1/123.0+5E65CECF ============================================================================== 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.
