AL>> Incidentally, I discovered that the timestamp of that file on
 AL>> disk was showing as November 25, 1961, so it should be a negative
 AL>> value. Converting the decimal to hex yields FFFF FFFF F0C4 3650,
 AL>> which in 2's complement notation is -255576496.  A quick Unix
 AL>> time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC.
 AL>> Therefore, it appears that the value is a correct 64-bit Unixtime
 AL>> for the file timestamp as it was on disk.

 Ol> I polled your system with tcpdump running and sent a .pkt from 1966.
 Ol> It looks like a binkd bug to me:

 Ol> M_FILE 7eee1e8f.pkt 450 18446744073609551616 0
 Ol> instead of
 Ol> M_FILE 7eee1e8f.pkt 450 -100000000 0

The Binkp/1.0 spec (FTS-1026) says:

    In the basic implementation: size, unixtime and offset
    MUST be positive numbers or zero.

What is the "basic implementation"? binkp/1.0 without any OPTs?
binkp/1.1 allows a "-1" offset.

The spec also states:
    File_size, unixtime and file_offset are decimal integers.
    Implementation note: mailer MUST check received string to
    prevent number overflow and skip file if overflow.

What to do with the situation now? We have one implemenation that sends a
negative unixtime and another implementation that returns a timestamp that is
584 biliion years in the future.

I wish a negative unixtime were allowed by the specification in the first
place.

--- GoldED+/LNX 1.1.5-b20180707