Is binkit binkp 1.1 compliant?

I'm tracking down why my session with clrghouz are finishing failed - and it appears only with Synchronet binkit.

I think its because binkit advertises 1.1, but it doesnt send a final round of EOB and wait for EOB.

In the following outbound session:

root@alterant:/opt/sbbs# jsexec -L10 binkit -l 516:1/0

JSexec v3.21a-Linux master/b7d3db6c3 - Execute Synchronet JavaScript Module
Compiled Sep 28 2025 18:57 with GCC 10.2.1
...
Connection to clrghouz.bbs.dege.au:24564 successful
Sending M_NUL command args: OPT CRYPT
Sent M_NUL command
Sending M_NUL command args: SYS Alterant
Sent M_NUL command
Sending M_NUL command args: ZYZ deon
Sent M_NUL command
Sending M_NUL command args: LOC Parkdale, VIC
Sent M_NUL command
Sending M_NUL command args: NDL 115200,TCP,BINKP
Sent M_NUL command
Sending M_NUL command args: TIME Tue Mar 24 2026 15:34:07 GMT+1100 (AEDT)
Sent M_NUL command
Sending M_NUL command args: VER BinkIT/2.41,JSBinkP/4,sbbs3.21a/Linux binkp/1.1
Sent M_NUL command
...
Sending file: ../fido/outbound.204/69c2140e.pkt (0.5KB)
Sending M_FILE command args: 69c2140e.pkt 529 1774326798 0
Sent M_FILE command
Sending 529 bytes of data
Sent file: ../fido/outbound.204/69c2140e.pkt (0.5KB)
Sending M_EOB command args:
Sent M_EOB command
Got M_NUL command args: OPT NR MB EXTCMD NZ BZ2 GZ ZSTD BROTLI CRC
Got M_EOB command args:
We got an M_EOB, but there are still 1 files pending M_GOT
Got M_GOT command args: 69c2140e.pkt 529 1774326798
Deleted file: /opt/sbbs/fido/outbound.204/00010000.clo
Got M_FILE command args: 000e5343.pkt 1937 1774326849 0
Receiving file: /opt/sbbs/temp/000e5343.pkt (1.9KB)
Got data frame length 1937
Received file: /opt/sbbs/temp/000e5343.pkt (1.9KB)
Moving '/opt/sbbs/temp/000e5343.pkt' to '../fido/inbound/000e5343.pkt'.
Sending M_GOT command args: 000e5343.pkt 1937 1774326849
Sent M_GOT command
Got M_EOB command args:
...

Since it received a file from me 000e5343.pkt shouldnt it have sent another S_EOB indicating that there is nothing else (in case it processed that file)? (This is what I see other BINKP implementations do - I always see two EOBs from the remote).

I see the same problem on an inbound session - binkit tears down the session before sending a final round of EOBs.

From: FSP-1024 The binkp/1.1 protocol defines multiple batches, this means that after a batch ends (M_EOB frame sent) the mailer checks the outbound for new files and starts a new batchs if files are found.