Synchronet and SBBSecho has always treated the to, from, and subject fields
in FidoNet "Stored Messages" (*.msg files) and "Packed
Messages" (those contained in type 2 packets) as null-terminated
strings with a maximum *usable* length of 35 characters for the
"to" and "from" and a maximum *usable* length of 71
characters for the "subject".

However, in reviewing FTS-1 (http://ftsc.org/docs/fts-0001.016) my/our
interpretatoin may be wrong.

FTS-1 is ambiguous about whether or not the last character of these fields
may be used or not. In other words, if a "to" or "from"
name is exactly 36 characters, is it legal to use all 36 characters and
*not* include a null terminator in a stored message? It is a fixed-length
field after-all, so a terminator should not be needed if all 36 characters
are used. Similarly, would it be possible to use all 72 characters for a
message subject? This would be consistent with how the "password"
field in a packet header is stored (no null terminator included for
full-length passwords).

"Packed Messages" use variable length header fields, so even
full-length header fields (e.g. a 36-character to or from name) would still
require a null terminator. But the spec is not clear:

              |                    subject                    |
              ~                  max 72 bytes                 ~
              |                null terminated                |

It's not clear if that "null" is *included* in the max 72 bytes,
or not. :-(

How does *your* implementation handle these fields? What would happen if
you received a Stored Message where byte 71 (the 72nd byte) of the
"subject" was non-null? Or if you received a packet that included
a 72-character subject followed by a null? Both of these conditions do not
appear to violate FTS-1, but I'm not sure how other programmers have
interpetted these specs over the years.

It seems wasteful to have critical bytes in a packet header that are
*always* zero, so if we could agree that byte 71 (couting from 0) of a
subject and byte 35 (again, counting from 0) of to/from names are *usable*,
that would make these message/packet formats a little more sane.

But in any case, the spec (FTS-1) needs clarification: I can easily justify
either interpration, which could lead to wildly-incompatible
implementations of FTN message/packet generating and parsing software.
--- SBBSecho 3.08-Linux