= Сообщение: 5140 из 7124 ====================================== FTSC_PUBLIC = От : Andrew Leary 1:320/219 04 Mar 20 02:10:49 Кому : Ozz Nixon 04 Mar 20 02:10:49 Тема : Two changes to BinkP inquiry... FGHI : area://FTSC_PUBLIC?msgid=1:320/219@fidonet+5e5f5eda На : area://FTSC_PUBLIC?msgid=1:1/123.0+5E5CF9D0 = Кодировка сообщения определена как: CP437 ================================== ============================================================================== 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.
