Subj : Two changes to BinkP inquiry...
To : ALL
From : Ozz Nixon
Date : Mon Mar 02 2020 12:33 pm
Now that my mailer (listener) and poller (client) are in production on
a few sites ~ and I have joined a couple of networks that wish to be
"under the radar". I wanted to check around about 2 possibly changes to
the BinkP protocol.
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.
