Subj : Two changes to BinkP inquiry...
To : Ozz Nixon
From : Joachim Probst
Date : Wed Mar 04 2020 06:15 pm
Hello Ozz!
02 Mar 20 12:33, you wrote to all:
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.
ON> However, this approach would help define an M_REQ means a POLL
ON> request, instead of how it is documented now, as a if you didn't get
ON> any M_FILE from the client, it must be assumed as being a POLL.
Could you please elaborate in the advantage of this? As far as I see the FTS
for binkp, both sides send their files, ready for sending, after the session
setup is finished with M_OK. After that part is does not matter if it was a
poll or a dialout. The only advantage I see, is the receiving mailer does not
have to check for *.req naming of the file, for serving the file request within
the same session, but can deceide on the command. I am not sure, if that would
initiate me to think about a protocol change.
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.
I go along with the comment of why wanting to turn the mailer into a frontdoor
as IP with it ports does not need such a mechanism to allow multiple services
on the same machine.
One advantage I see in the binkp protocol is that it is so very simple.
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.
Nice idea, like that part, but I do not see the necessaty of a protocol change.
FTS does not request that you show all addresses you have. It just requests
that the originating side does not wait for any response before sending M_PWD
and that for password checking all presented addresses (by the originating
side, no other makes sense) are using the same password, if any.
The originating side could just present the networks it wants to present
(hiding akas is already sugested in the FTS for the purpose of working with
different passwords on different akas). If the answering side only presents
'public' akas and akas fitting to those presented by the originating side, I do
not see any violence of the current binkp protocol and can see no harm to the
network, too. Maybe I am overlooking something?
