Subj : Two changes to BinkP inquiry... To : Joachim Probst From : Ozz Nixon Date : Mon Mar 09 2020 05:16 am >*.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- 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 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 , 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) .