Subj : Two changes to BinkP inquiry...
To : Ozz Nixon
From : Andrew Leary
Date : Wed Mar 04 2020 02:10 am
Hello Ozz!
02 Mar 20 12:33, you wrote to all:
ON> Now that my mailer (listener) and poller (client) are in production on
ON> a few sites ~ and I have joined a couple of networks that wish to be
ON> "under the radar". I wanted to check around about 2 possibly changes
ON> to the BinkP protocol.
You are free to implement your changes in your software, although you should
attempt to do so in a manner that will not affect compatibility with existing
mailers.
ON> Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
ON> Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
ON> Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2
ON> Optional support for .REQ files could stay for backward compatability.
.REQ files are currently the standard method of requesting files in FTN
networks, used by both POTS mailers (ie. FTS-6 and EMSI) and most BinkP
mailers. In some cases the mailer may rely on an external request processor
to handle received .REQ files; binkd is an example of such a mailer. It
should also be noted that you cannot assume a node supports file requests
unless it flies a FREQ flag (XA/XB/XC/XP/XR/XW/XX) in the nodelist. You also
don't indicate if your proposal will include any support for update requests
as defined in FTS-6 (WaZOO) and FTS-8 (Bark).
ON> The other change to the BinkP protocol - really applies to the
ON> workflow of the protocol ~ for example, if you telnet to my BinkP
ON> mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
ON> do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
ON> port scanner, (c) EMSI Session (because I could send **REQ before the
ON> CRAM).
As binkd is the reference implementation (and most widely used) of the BinkP
protocol, this should really be discussed with the binkd developers. I can
tell you that if your change is not added to binkd, it is highly unlikely that
it will ever meet the "widespread use" requirement for documentation as a
FidoNet Technical Standard by the FTSC.
ON> The other part of the workflow change is not to present all M_ADR as a
ON> couple networks I have joined prefer to be a little more under the
ON> radar ~ the easy way to help improve this would be to require the
ON> client (polling process) to share the address(es) associated with the
ON> connection it is expecting (incase we share two or more networks and
ON> said connection is my uplink/downlink). This tweak of course is
ON> optional for products still in development ~ but adds a small layer of
ON> anonymity for said networks.
Some BinkP mailers already can be configured to selectively choose which AKAs
to present to the remote system. binkd has the hide-aka and present-aka
keywords in the configuration file.
ON> I am in the process of implementing these changes to the systems
ON> running my mailer, so we can iron out any quirks. However, it was
ON> suggested that I present my thoughts in FTSC_PUBLIC.
You need to test your changes thoroughly to ensure that they do not cause any
issues for other software used in FidoNet.
