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

[David Levine]

Ken wrote:

> [Steven wrote:]
> >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).

I thought that mhfixmsg DID refuse to decode it:

   mhfixmsg: /tmp/msg, will not decode text/html;  charset="UTF-8" because it 
is binary (line length > 998)

I'll assume that Steven wasn't asking a question above, but just noting
that his expectations have been corrected.  If that's not the case, please
let me know what's broken.

> > ...so it was clearly marked as text.  If a sender packages a binary
> > file but describes it as text/html, it's already broken, and I really
> > don't care if mhfixmsg "damages" it even further. :-/

It's not necessarily broken.  Binary text/html can certainly be encoded as
base64, for example.  See Ken's description that includes the "War and Peace"
example.

Now in regards to mhfixmsg decoding text that RFC 2045 defines as binary,
please see the description of the -decodetext switch in the man page
(8bit is the default):

    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.

So, it sounds like -decodetext binary will get mhfixmsg to do what you
want(ed).  But, you might be left with messages that nmh programs can't
ingest.

David