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.Winikoff@concordia.ca | there."
| - Charles F. Kettering
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers