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)