@TID: FMail-W32 2.3.0.1-B20240319
@
RFC-X-No-Archive: Yes
@TZUTC: 0200
@CHRS: UTF-8 4
@MSGID: 2:280/5555 6a998b74
Hello Eugene,

=== quote ===


Header fields are cut where the standard ends them, on a character
boundary. FTS-0001 sizes toUserName and fromUserName at 36 bytes and
subject at 72, and says of each that it is null terminated, so what may
be written in them is 35 and 71. That is the field a type-2 packet
carries, out of whatever base the mail was written in. Whatever packs
the mail copies those bytes knowing nothing of charsets, and in UTF-8
the 36th byte lands inside a letter as often as not; a base with room
for more only moves the cut, since JAM gives these fields 100 bytes and
the packer still takes 36. GoldED+ now makes the cut itself, once the
export charset is settled and a character can still be seen whole.


=== end quote ===

 Perhaps you should make this configurable. For the future. Jam
allows 100 bytes you say. (I didn`t check). So if you make a switch that
allows making use of all 100 bytes (while still truncating on a character
boundery in case of unicode) we may entice tosser developers to do the
correct truncation when applicable. In the specific case of Fmail I see
possibilities. We may see an update of the PKT 2+ specification that allows more
space for the header. Say PkT 2++. The tosser kan then use PKT 2++ to
send to nodes that support it. That we way can introduce larger headers
in a downward compatible way.

 Maybe this will work, maybe it will not. But if you make it
configurable with a simple on/off switch at least Golded is ready for the
future.

LargeHeaderToBase  yes|no   (default no)


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20260830
 * Origin: Nieuw Schn├╕├╕rd (2:280/5555)
SEEN-BY: 154/10 203/0 240/5832 280/464 5003 5555
292/789 301/1 310/31 341/66
SEEN-BY: 460/58 5001/100 5015/46 5019/40 5020/715
1042 1146 5452 9696 5023/24
SEEN-BY: 5030/1081 5051/44 5075/35 6035/3
@PATH: 280/5555 5020/715