Hi, mark!

On Fri, 10 Jan 2020 19:51:55 +0200 mark lewis writes:

 ZK>> In case of subject longer then allowed 71 + NUL bytes HPT
 ZK>> send the whole PKT with the incorrect message to bads.

 ml> what FTN software is creating and/or passing on messages with
 ml> subject lines longer than the spec for packed messages allows???
 ml> whichever software that is needs to be fixed to stop the defective
 ml> pkts from being generated and sent out in the first place...

No doubts. No arguments against that.

But software may have bugs and it's sad to lose otherwise valid data
because of that.

But I understand the general attitude, thanks you for the input.

BTW, in RFC world it's pretty different. Ex.: rfc2045

```
    (5)   Encoded lines must not be longer than 76 characters,
          not counting the trailing CRLF. If longer lines are
          found in incoming, encoded data, a robust
          implementation might nevertheless decode the lines, and
          might report the erroneous encoding to the user.
```
which looks more human friendly for me.

And the original question can be splitted basically into 2:

- is it ok to handle the situation without failing the pkt?
- is it ok to make the pkt standard complied?


I got your answers, thanks a lot!


--- Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)