Re: [Nmh-workers] mhshow complaints

[Ken Hornstein]

>> 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.
>
>I'm curious: how is this worse than the extra semi-colon?
>They both violate a standard, but neither are so corrupt as to be
>un-displayable by nmh, mutt, or Gmail.

Oh, sure, make me try to explain this in intelligent words.

Alright, I had to think about this, but here's the best I can come up
with.  The extra semicolon is merely a small violation of the parameter
BNF; there's no ambiguity here.  It's not like there's anything after
the semicolon for us to interpret.

Now, we're supposed to be looking at the MIME-Version header (we don't,
but hey, nobody else does either).  Since there are two, which one are
we supposed to pay attention to?  It's the same problem we have with
multiparts that are marked as quoted-printable; not only is that violation
of the standard, it's _wrong_; those multiparts aren't actually encoded
using quoted-printable, which means there is an ambiguity in terms of
what we're supposed to do.  If we did respect the q-p CTE, we'd get errors
since the multiparts don't have that encoding.

>[ part 1.2 - image/png - image001.png ]
>[ part 2 - application/pdf - Preapp disclosures.pdf  ]
>[ part 3 - application/pdf - Preapplication documents.pdf  ]
>
>At the very least, all unknown types should be handled that way,
>rather than writing a message to stderr that is overlooked at
>best and interferes with the pager at best.

Hm, actually, I am surprised that doesn't happen, now that you mention
it.  If you can send me that message I'll work on that; I would have
thought it wouldn't have displayed it.  That might be a bug we should
fix for 1.6.

>Ralph Corderoy <address@hidden> writes:
>
>> No, that's the way to a world full of crap.
>
>Ralph, the world is already full of crap, and no one cares.
>If all 2 dozen nmh users complained to every broken mail
>provider, they still wouldn't care.

I have sympthathy for you; my personal feelings are closer to yours.
We're trying to make things better, honest!

>Maybe turn this error logging off by default, with a profile
>entry for sending it to stderr or even a log file?  And to
>let people who care know, you already have a place to write a
>quick note:  mhshow writes this to the pager:
>
>part 1.1.1 text/html                  10K
>
>You could add a small note to that line that errors have been
>logged for that part.

Architecturally, this is hard.  In general we are lousy when it comes
to error handling; inside of the library we do a lot of logging to
stderr.  We'd need to think carefully about how we want to handle the
case of non-critical MIME errors; how do we pass them up to callers
so they can deal with them?  It's not insolvable, but it will take some
thinking.

--Ken