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