>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 -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
