@MSGID: 2:5030/723 67090986
@REPLY: 2:5030/1997@fidonet 6708f507
@CHRS: CP866 2
@TZUTC: 0300
Здраствуйте, Alexey!

11 окт 24 12:51, Alexey Fayans -> Alexey Khromov:

 AF> выдал сразу после того, как я к нему подключился телнетом и ничего не
 AF> отправил:
 AF> В этой простыне в том числе и твой адрес. Были бы прописаны ака - тоже
 AF> были бы предъявлены сразу.

Именно. Читаем стандарт binkp1.0 и пропозал binkp1.1 :

======================================================
http://ftsc.org/docs/fts-1026.001

Binkp uses only one synchronization point during session startup,
   that is password exchange.

 Session setup stage: M_ADR (MUST be sent by both sides), M_PWD
      (MUST NOT be sent by the Answering side), M_OK (MUST NOT be sent
      by the Originating side).
      These commands MUST NOT be sent during the file transfer stage.

   +----------------------------------------------------------------+
   | Originating side               | Answering side                |
   |--------------------------------+-------------------------------|
   | M_NUL "SYS ..."                | M_NUL "SYS ..."               |
   | M_NUL "ZYZ ..."                | M_NUL "ZYZ ..."               |
   | M_NUL "LOC ..."                | M_NUL "LOC ..."               |
   | M_NUL "VER ..."                | M_NUL "VER ..."               |
   | M_NUL "OPT ..."                | M_NUL "OPT ..."               |
   | M_ADR "1:1/1.1@fidonet"        | M_ADR "2:2/2.2@fidonet"       |
   | M_PWD "password"               | (waiting for a password from  |
   |                                | remote)                       |
   |--------------------------------+-------------------------------|
   | (waiting for password          | M_OK "secure"                 |
   | acknowledgement)               |                               |
   |--------------------------------+-------------------------------|
   | (got M_OK)                     | M_FILE "file2 200 42342434 0" |
   |--------------------------------+-------------------------------|
   | M_FILE "file1 100 423424244 0" | data                          |
   |--------------------------------+-------------------------------|
   | data                           | data                          |
   |--------------------------------+-------------------------------|

http://ftsc.org/docs/fts-1027.001

  1.7 Example of Frame Exchange During CRAM Authentication
   --------------------------------------------------------

     Originating :
     send M_NUL and M_ADR messages
     wait for first M_NUL and/or M_ADR message

     Answering   :
     send M_NUL "OPT xx xx CRAM-MD5-f0315b074d728d483d6887d0182fc328"
     send M_ADR message
     and other messages
     wait for M_PWD
   Note: xx means other optional extensions thay are supported.



BinkP 1.1
http://ftsc.org/docs/fsp-1024.000

   NOTE: Modify the table slightly to show one of the sides goes into
   waiting after receiving M_EOB. Not showing this is confusing.

   +-----------------------------------------------------------------+
   | Originating side               | Answering side                 |
   |--------------------------------+--------------------------------|
   | M_NUL "SYS ..."                | M_NUL "SYS ..."                |
   | M_NUL "ZYZ ..."                | M_NUL "ZYZ ..."                |
   | M_NUL "LOC ..."                | M_NUL "LOC ..."                |
   | M_NUL "VER ..."                | M_NUL "VER ..."                |
   | M_NUL "OPT ..."                | M_NUL "OPT ..."                |
   | M_ADR "1:1/1.1@fidonet"        | M_ADR "2:2/2.2@fidonet"        |
   | M_PWD "password"               | (waiting for a password from   |
   |                                | remote)                        |
   |--------------------------------+--------------------------------|
   | (waiting for password          | M_OK "" (or M_ERR "Bad         |
   | acknowledgement)               | password")                     |
   |--------------------------------+--------------------------------|

======================================================================

 Как видишь, в стандарте *не определено* ожидание M_ADR одной из
сторон - только синхронизация на сверке пароля, о чем явно указано в FTS.
 Однако, технически *возможно* и *не противоречит* стандарту, если в
мейлер добавить выдачу своего адреса только после представления вызывающей
стороны, о чем я ранее и написал.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309
 * Origin:  - Вы в опасности! Вы окружены роботами! -  (2:5030/723)
SEEN-BY: 50/109 104/117 221/6 240/1120 301/1 341/66
450/210 451/31 452/28 166
SEEN-BY: 455/19 463/68 467/888 4500/1 5000/111
5001/100 5005/49 5015/42 46
SEEN-BY: 5019/40 400 5020/113 545 620 715 828 830
846 848 1042 2992 4441
SEEN-BY: 5020/12000 5022/128 5030/49 87 115 671
722 723 1081 1115 1474
SEEN-BY: 5053/51 55 5054/8 89 5058/104 5060/900
5061/133 5066/18 5068/45
SEEN-BY: 5083/1 444 6083/11 6090/1
@PATH: 5030/723 1115 115 5020/1042 4441