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

[Steven Winikoff]

>> 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
address@hidden   |  there."
                               |                  - Charles F. Kettering