Re: NMH mail package utility "inc" aborts before incorporating first new email into an NMH folder

>> I do feel like we have to ultimately deal with longer lines.
>
>Ah, our old argument...  :-)
>
>That would be accepting Garbage In, and then presumably spewing Garbage
>Out into inbox/42 where other programs, not necessarily nmh ones, expect
>a valid message format.

I know we're not going to convince each other, and that's fine.  I just
want to state my line of thinking for everyone.

In _this_ specific case, I am persuaded that we should deal with it by
two facts:

1) It seems that everybody else handles this just fine.  Or at least
   they don't abort.  I realize there is probably some line length limit
   that will cause some percentage of email programs to fail, but I suspect
   it's probably on the order of some number of megabytes.

2) There doesn't seem to be any ambiguity on _what_ you need to do: just
   write the line out as-is.  Sure, that will result in a mailbox that
   doesn't meet the standards, but (1) seems to make that a non-issue.
   If there truely was some protocol issue where the correct course of
   action was unclear then I might feel differently, but that doesn't
   apply here.

>Code is moving towards ever more tight specifications and compliance
>because AI can find exploits through multiple layers of software from
>different sources.  In the Bitcoin world, after the recent Coldcard
>debacle, the Kimi K3 LLM AI found many significant flaws in software which
>was already carefully inspected by hand many times.  (The USA's AI models
>refuse to search for these flaws; Kimi, from the Chinese, does not.)

I can appreciate this sentiment, but it seems that in the specific case
here of email messages the cat's already out of the bag and the the
prevailing sentiment is that if you get a line that's bigger than the
permitted limit you should just deal.

--Ken