>> This suggests to me that removing the 998-character limit in mhfixmsg >> (only, and nowhere else) is a reasonable thing to do. > >I think that -decodetext binary would be a better approach,
That worked. And now I understand this excerpt from the man page for mhfixmsg: The -decodetext switch enables a transformation to decode each base64 and quoted-printable text message part to the selected 8-bit, 7-bit, or binary encoding. If 7-bit is selected for a base64 part but it will only fit 8-bit, as defined by RFC 2045, then it will be decoded to 8-bit quoted-printable. Similarly, with 8-bit, if the decoded text would be binary, then the part is not decoded (and a message will be displayed if -verbose is enabled). Note that -decodetext binary can produce messages that are not RFC 2045 compliant. I'd seen that before, but until now I didn't fully understand it. >but note that warning about producing non-compliant messages. The resulting file has these headers: Content-Transfer-Encoding: binary Content-Disposition: inline Content-Type: text/html; charset="UTF-8" MIME-Version: 1.0 So if I correctly understand what I'm learning from you and Ken, this should be compliant. >> (Digression: I'd also prefer to reformat the long lines at the same time. >> I'm seriously considering piping the decoded HTML through something like >> tidy [ http://www.html-tidy.org/ ] before saving it. :-/) > >mhfixmsg -reformat does that. That's the default, but you overrode it >with -noreformat. I originally chose -noreformat deliberately, because I understood (or misunderstood?) that the point of -reformat is to transform the text/html content to text/plain, and I wanted to keep it as HTML (because I don't know how to do the HTML-to-text transformation in a way that doesn't break at least some messages). I tried it just now, and the (expected) result was mhfixmsg: Don't know how to convert /home/smw/Mail/reformatted/17352, there is no mhfixmsg-format-text/html profile entry ...which makes sense because I don't know what to put in that profile entry. >Uh, that's a different issue. -maxunencoded 900 can cause creation of >messages with lines that long, and they wouldn't comply with RFC 5322. I thought Ken said the RFC 5322 limit was 998. But... >Going a little over 78 might not be of a problem in practice, but . . . ...I know that 900 is overboard, but I was frustrated at the time. :-/ That goes back to when nmh-1.6 was a new thing, and I kept seeing messages I sent being encoded with Quoted-Printable for no reason I could see. It took a while before I found the -maxunencoded option and learned that it defaults to 78. I usually try to keep my outgoing messages to 75 or less, but I don't always succeed, and I chose a -maxunencoded value which I was sure I'd never exceed. I suppose I should bring it down to something more reasonable, but I'm not sure what that would be. I occasionally have to send messages with sendmail log excerpts in them... >> For example, I particularly depend on being able to find specific saved >> messages using grep or mairix[**] -- and if the message body is saved in >> base64 encoding, both of those programs fail completely. > >That was the main motivation for creating mhfixmsg. Thank you, I'm very glad you did that! (And I wish I'd discovered it years ago, but I digress. And it's my own fault I didn't read the nmh-1.6 release notes carefully enough. :-/) - Steven -- ___________________________________________________________________________ Steven Winikoff | Concordia University | "My interest is in the future because I Montreal, QC, Canada | am going to spend the rest of my life steven.winik...@concordia.ca | there." | - Charles F. Kettering -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers