Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2
Optional support for .REQ files could stay for backward compatability. However, this approach would help define an M_REQ means a POLL request, instead of how it is documented now, as a if you didn't get any M_FILE from the client, it must be assumed as being a POLL.
The other change to the BinkP protocol - really applies to the workflow of the protocol ~ for example, if you telnet to my BinkP mailer, it accepts a connection and sends the MD5 CRAM and waits. If I do not receive a MsgHdr Len M_<command> then I assume (a) User, (b) port scanner, (c) EMSI Session (because I could send **REQ before the CRAM).
The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the radar ~ the easy way to help improve this would be to require the client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and said connection is my uplink/downlink). This tweak of course is optional for products still in development ~ but adds a small layer of anonymity for said networks.
I am in the process of implementing these changes to the systems running my mailer, so we can iron out any quirks. However, it was suggested that I present my thoughts in FTSC_PUBLIC.
