= Сообщение: 5141 из 7128 ====================================== FTSC_PUBLIC = От : Joachim Probst 2:240/6309 04 Mar 20 18:15:34 Кому : Ozz Nixon 04 Mar 20 18:15:34 Тема : Two changes to BinkP inquiry... FGHI : area://FTSC_PUBLIC?msgid=2:240/6309+5e5fe4fb На : area://FTSC_PUBLIC?msgid=1:1/123.0+5E5CF9D0 = Кодировка сообщения определена как: LATIN1 ================================= Ответ: area://FTSC_PUBLIC?msgid=1:1/123.0+5E62CF02 ============================================================================== 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?
