Re: [Nmh-workers] why does mhfixmsg dislike long text lines?

[Ken Hornstein]

>And I won't presume to suggest what nmh should do, but I will point out
>that I recently received a message with a text/html part which was one
>single line of 42027 characters.

Let me ask you a more precise question.

Are you saying you received via SMTP a RFC5322 message where there
was 42027 characters between CR-LF pairs?  Because while I believe
that might happen, I am actually skeptical that's what you received.
Specifically because of this:

>   Content-Transfer-Encoding: quoted-printable

That suggests to me that you in fact received a message that had lines no
greater than 78 characters between CR-LF pairs, and _after you decoded it_
it might have had a very long line.

THAT is completely legal according to the RFCs.  For the most part, it
doesn't matter what it decodes to; what nmh cares about is that the
message it is reading is valid according to RFC 5322.  THAT is where the
998 byte line length limit comes into play.  You could send the entirety
of "War and Peace" in text/plain part all as one line, and as long as it
was encoded properly that would be fine.

>This part is 670 lines before decoding, and exactly one line afterward.
>This arrived before I started using mhfixmsg, but given what I've just
>learned I'd certainly expect mhfixmsg to refuse to decode it.

That's a question for David, since mhfixmsg is his baby.  I would suggest
that was probably an oversight and he might fix it at some point (and
by "fix it" I mean, "refuse to decode it", but that's up to him).  As far
as I know the goal of mhfixmsg is to transform RFC 5322-format messages
from one set of encodings to another, but still produce a valid RFC 5322
formatted message.

>But you're quite right that this code isn't easy to understand.  If I were
>to modify uip/mhfixmsg.c without touching sbr/m_getfld.c, am I risking
>anything other than generating messages that nmh won't be able to read?

Good question!  Your use cases seem to be ... well, I don't understand
them.  Using nmh to produce a message that nmh cannot handle seems
suboptimal at best.  I don't think we will make any guarantees in the
code that we will be able to handle such messages.  Emailing such a
message without encoding it also is not guaranteed to work properly,
and that is outside of nmh's control; I can tell you from personal
experience that some MTAs will insert a '!' at the end of unencoded long
lines like that and force a line break, and that plays hell with HTML.

And might I suggest that if you're going to keep asking us questions
about nmh, you should join the mailing list? :-)

--Ken