RS> FTS-1 is ambiguous about whether or not the last character of these RS> fields may be used or not. In other words, if a "to" or "from" name is RS> exactly 36 characters, is it legal to use all 36 characters and *not* RS> include a null terminator in a stored message? It is a fixed-length RS> field after-all, so a terminator should not be needed if all 36 RS> characters are used. Similarly, would it be possible to use all 72 RS> characters for a message subject? This would be consistent with how RS> the "password" field in a packet header is stored (no null terminator RS> included for full-length passwords).
RS> "Packed Messages" use variable length header fields, so even full-length RS> header fields (e.g. a 36-character to or from name) would still require a RS> null terminator. But the spec is not clear:
RS> It's not clear if that "null" is *included* in the max 72 bytes, or not. RS> :-(
I think it is clear, and included in the 72 bytes.
RS> How does *your* implementation handle these fields? What would happen RS> if you received a Stored Message where byte 71 (the 72nd byte) of the RS> "subject" was non-null? Or if you received a packet that included a RS> 72-character subject followed by a null? Both of these conditions do RS> not appear to violate FTS-1, but I'm not sure how other programmers RS> have interpetted these specs over the years.
I checked the fmail source: it reads a maximum of 72 bytes (untill and including a NULL) from the pkt file for the subject. It doesn't care if byte 71 isn't a NULL (when the maximum of 72 bytes are read), but it forces it to NULL before further processing. So effectively limiting the subject to 71 characters. If the byte after 72 subject characters would be NULL, it regards that as the 1st byte of the next field. So that would mean a message body of 0 characters.
Bye, Wilfred.
--- FMail-lnx64 2.1.0.18-B20170815 * Origin: FMail development HQ (2:280/464)