[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhshow complaints

From: Ken Hornstein
Subject: Re: [Nmh-workers] mhshow complaints
Date: Mon, 21 Apr 2014 09:41:15 -0400

Geez Eric, you could have brought this all up when during all of the
thrashing around about mhshow changes BEFORE 1.6 was branched ...

>#: mhshow sucks; I'll run it by hand if I need to
>showmimeproc: mhl

I'm surprised you just dont do:

show: -nocheckmime

But, whatever.

>mhshow: extraneous trailing ';' in message 132's Content-Type: parameter list
>mhshow: extraneous trailing ';' in message 132's Content-Type: parameter list
>mhshow: extraneous trailing ';' in message 186's Content-Type: parameter list
>mhshow: extraneous trailing ';' in message 186's Content-Type: parameter list
>mhshow: message 593 has multiple MIME-Version: fields
>Why the heck should I care about that?  Complaining multiple
>times, too!  Just tolerate it and get on with it.

Sigh.  I'll let you fight that one out with the greybeards here; there
is a constant battle between the "deal with it camp" and the "a single
misplaced semicolon should cause a core dump and immediately execute rm
-rf /". Okay, perhaps I'm exaggerating the last one.  I will note that
a semicolon at the end of the parameter list does violate the BNF for
MIME parameters, but it strikes me as something that really doesn't harm
anything (and it's not like there's really any confusion about what to
do).  But I'll be honest; I have never in my life seen a message like
that.  I don't know why that message is happening twice; I'd like to
figure that out, if nothing else.  This may be complicated by the issue
that get_ctinfo() (the guy who is calling parse_header_attrs(), which is
the function issuing that warning) does double-duty in terms of parsing
MIME headers and the mhbuild directives.

Messages containg multiple MIME-Versions are pretty much bogus; I think
it's okay to issue a warning about that.  It seems like something has
gone wrong there.

>It refuses to show plain text parts it doesn't think are text
>based on the media type:
>mhshow: don't know how to display content
>        (content message/delivery-status in message 641, part 2)

Well, um, yeah ... I mean, that's what we're supposed to do.  How
are we supposed to know that it's text?  From RFC 2046, 5.2.4:

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

For once we get that right.  Just assuming that an unknown message type
is text isn't right.  Now, creating a list of message types we know are
text isn't hard.  In terms of officially recognized media types, there
are only 21 message types, and not many of them would be relevant to
email.  I really only see a few we need to add.

>And then there's this weirdness (from the same delivery-status message):
>mhshow: Can't convert unicode-1-1-utf-7 to UTF-8
>mhshow: unable to convert character set of part 1 to unicode-1-1-utf-7, 
>As far as I can tell, it actually did decode and show the
>content.  So what is it complaining about?

I thought that charset was mega-bogus, but it turns out that's wrong.
It's defined in RFC 2152.  We simply pass those strings directly to
iconv(), and the iconv on my system claims that it can handle that.
Although from what I read, "unicode-1-1-utf-7" is the old charset name
used in RFC 1642; RFC 2152 says you should use utf-7.  But anyway,
technically it didn't convert that character set; when you get that
message, the content just gets displayed without running it through
iconv.  That's a warning that we couldn't perform the character set

>The delivery-status message is a "mailbox full" message from AOL.
>Surprisingly, at least one person still uses AOL, and they
>probably have some crazy small mailbox size.  I can forward it to
>Ken or anyone else who wants a look at it, but would rather not
>post it to the list.

I am interested in looking at that message, and any others you find
that mhshow doesn't deal with well.  I'm not sure we can get that all
fixed for 1.6, but we can at least do better for 1.7.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]