AL>>> I have recently noticed that some versions of BinkD are listing
 AL>>> a 64-bit value for the Unixtime sent in M_GOT frames
 AL>>> acknowledging received files.

 Ol>> Which versions do this and what bit width is used with the M_FILE
 Ol>> command?

 AL> Here is the log from an example session:

 AL> === Cut ===
 AL>   09-Nov-2019 05:40:20 mbcico[11948] MBCICO v1.0.7.13
 AL>   09-Nov-2019 05:40:20 mbcico[11948] Cmd: mbcico f126.n1.z21.fsxnet
 [...]
 AL> Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" + 09-Nov-2019
 AL> 05:40:22 mbcico[11948] Binkp: unexpected M_GOT "SIOREG.ZIP"
 AL> === Cut ===

That is an interesting unix timestamp, which doesn't fit into a 64-bit signed
integer.

18446744073453975120 / 2 -> November 16, 219250464

Even if this were in nanoseconds it would be a date far in the future:
July 21, 2554

 AL> I need to add logging of the sent M_FILE messages to confirm that
 AL> mbcico is sending a 32-bit value in the M_FILE.  You can see that the
 AL> remote (binkd 1.1a-99/Linux) is sending a 64-bit value for the
 AL> Unixtime in the M_GOT frame.

Looks like a bug to me that needs fixing. Are you sure that binkd sends this
number?

 Ol>> Does it break compatibility with any mailer? You didn't mention
 Ol>> any specific example.

 AL> mbcico (the mailer included with MBSE BBS) rejects the M_GOT with the
 AL> 64-bit value and ends up trying to send the file again in the next
 AL> session.  I suspect that ifcico (which mbcico was based on) will do
 AL> the same, although I haven't tested it yet.

Every mailer should reject that M_GOT, the value doesn't make any sense.

--- GoldED+/LNX 1.1.5-b20180707