Re: [Nmh-workers] mhshow complaints

[epg]

Ken Hornstein <address@hidden> writes:

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

Heh, I admitted as much.  I don't have as much time as I'd like
to spend on such things.  Sorry.

> But I'll be honest; I have never in my life seen a message like
> that.

Looks like these are mostly from mailchimp.

> 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.

> For once we get that right.  Just assuming that an unknown message type
> is text isn't right.

On another message mhshow writes this to my pager:

[ 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.

mutt does a nice job, btw:

[-- Attachment #2 --]
[-- Type: message/delivery-status, Encoding: 7bit, Size: 0.2K --]

Reporting-MTA: dns;mail2world.com
Received-From-MTA: dns;emde02oc.mail2world.com
Arrival-Date: Thu, 6 Mar 2014 09:56:45 -0800

Final-Recipient: rfc822;address@hidden
Action: failed
Status: 4.4.7

But, if nmh just wrote [ part 1.2 - message/delivery-status ]
that would be fine with me; I doubt I'd even check the raw
message in this case.

Gmail, oddly, takes the second block (Final-Recipient and on) and
displays it in-line without indicating it was in a separate MIME
part.  It doesn't display the first block.

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.

If a message is so broken that nmh can't interpret it without
making an unholy mess of the code, then of course I would not
argue with just bailing out and giving up.

But I disagree that nmh should so loudly complain about a message
that it demonstrably has no trouble interpreting.

Is nmh primarily trying to help users file bugs in other mail
programs, or trying to help users deal with their email?  I say
it's primarily the latter.

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.

Anyway, I do appreciate all the volunteer effort.  Thanks!