Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    BINKD    |    Support for the Internet BinKD mailer    |    8,958 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 6,373 of 8,958    |
|    Oli to Andrew Leary    |
|    Unixtime in M_GOT frames    |
|    09 Nov 19 14:32:23    |
      REPLY: 1:320/219@fidonet 5dc6bc2a       MSGID: 2:280/464.47@fidonet 5dc6c668       CHRS: UTF-8 4       TZUTC: 0100       TID: CrashMail II/Linux 1.7        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        * Origin: * nigirO (2:280/464.47)       SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 227/114 229/101 200       SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854       SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250       PATH: 280/464 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca