Binkp/1.1

1. The previous binkp/1.0-compatible mailers could send a message M_NUL of the type "VER mailer-version binkp/1.0". Binkp/1.1 suggests that any mailer compatible with binkp version 1.1 and higher will form and parse such a message (in the format "VER mailer-version binkp/1.1") after receiving it at the other side.
   This message should have been sent up to the moment when the server and the client exchange with password and login acknowledgement. If the message has not been received up to the moment we can consider the protocol version of the opposite side to be equal 1.0

2. One more M_NUL message, which one should understand as far as possible is M_NUL "OPT XXX YYY ...".  It is a way to send arbitrary options (the list of option names is case sensitive and delimited by spaces). Binkd/0.9 understands "NR" option: a request to change to NR mode (an example of the request: M_NUL "OPT NR"). Generally speaking we cannot be sure that the remote side will comply with our request after we have sent such a command and in general we have no way to know its decision (except we stipulate especially for necessity to send back a reply for the XXX option).  In case of NR any behavior of the remote side should not confuse us (see below).

3. In order to have a possibility to receive requests (in particular file requests) and to send the results back during the same session in case the other side runs binkp/1.1 or higher, binkd 0.9 follows such an agreement: when both sides have exchanged with EOB the session does not finish but it restarts by resetting binkp to the state it had just after login (i.e. a rescan is made and sending of the found files starts). The session is considered successfully finished, if between two consecutive exchanges with EOF the sides did not send and did not receive a binkp command.

4. One must react correctly to M_FILE "name size time -1" that is to reply with an appropriate M_GET (see below).

5. Previously binkd always started to send every new file from the offset 0. The other side could make a new request for the file with another offset, if it had found a partially received file in its inbound directory. The problem is that such an optimization makes a link absolutely unable to work if timeouts are frequent: at the moment, when the sender gets M_GET its buffer and TCP window are already overfilled with the data of the same file being sent from 0 and they do not have time to free for the data from a new offset before the connection fails. Now the senders have an option at unreliable links only (since such a behavior is nevertheless really ineffective) to request really necessary to the receiver offset in the transmitted file using M_FILE "name size time -1" before sending every new file. No preliminary agreement with the opposite side is necessary before sending the command (besides the confidence that the remote side has binkp version > 1.0).
   I call it "NR mode" (i.e. "Not Reliable link"). Thus we can at any moment switch to the NR mode on our own or we can at any moment ask the remote side to switch to the NR mode by M_NUL "OPT NR" command.