Re: Bug #66407: POP client cannot handle long lines in message

[Ken Hornstein]

>> As for nmh being wrong, well ... it cannot handle email that it seems
>> literally every other piece of email software seems to handle just fine.
>> What does that tell you?
>
>I've been thinking more about this... dangerous, I know.
>
>I'm not sure we  know what "handle just fine" means for  the rest of the
>world. Some  of the reports I've  seen that are similar  to mine suggest
>that their mail system handles it  by truncating the line thus rendering
>the attachment garbage (if it's an  attachment). I don't know what those
>others are running, but I'm pretty confident it's not nmh.

Well, hm, good question.  The OVERWHELMING impression I get is that
the vast majority of the email world seems to read and deal with those
multi-megabyte messages that appear as a single line just fine.  But
if you could provide some context about these reports where people
experience this truncation it sure would be useful.

>Is truncating the line the appropriate thing to do? What should nmh do?
>
>In another thread we're discussing a patch that will make inc handle the
>long  lines, but  what should  inc  do with  the long  lines? Should  it
>actually make those long lines conform by folding them?

Well, in the admittedly rare case of binary content which is exempt
from the line length requirement (I believe nmh can read those messages
correctly but probably cannot generate them, or store them correctly if
they are on a POP server), you can't fold that content at all.  I cannot
come up with a reason that we should not just store that message as it
is presented to us and simply handle it.

--Ken