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_ 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.

Andrew

--- GoldED+/LNX 1.1.5-b20180707