Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Ken Hornstein]

>Well, whether you intentionally type any and whether some happen to creep
>into your email are two different things.  As an example: I am suspicious
>now that my problem really stemmed from exmh choosing to use both -push
>and -forward; the latter is documented as "If -forward is given, then a
>copy of the draft will be attached to this failure notice."  So I am
>thinking that it stuck the UTF8-containing text onto the failure notice,
>and then that send attempt failed for exactly the same reason, ie it was
>rejected by the character set strictness check.  Even if you're right that
>there was no send attempt at all, I'm expecting that once it's there
>it will fail like this :-(

Well, I looked.  It's important to understand the workflow here, and how
things have evolved over time.

First, you have to have special handling to handle -push in send; I didn't
implement that for mhbuild.  So yeah, mhbuild failing and not sending a
notification email is a bug.  At least if that had worked, you would have
gotten something in dead.letter if it couldn't send it.

So, current workflow.  A user creates a "draft file" by whatever means.
Then it gets passed to send(1).  send's job is to turn the draft file
into a RFC 5322-compliant message and then send it to post(8).  That is
done by calling mhbuild(1) on the draft.  This used to be optional; the
result was that nmh users could very easily be sending out messages that
weren't MIME compliant (and that happened a lot).

>So basically the problem here is one of robustness.  Yeah, it would be
>nice to be sure that what you are sending is 100% valid.  But I don't
>really agree with the tradeoff that's been made of failing when you
>can't be sure of that.  Especially since, if you think you know what
>non-ASCII encoding a bit of text is in, you're just fooling yourself
>anyway.  It's impossible to distinguish the ISO 8859 variants from
>each other, and at best heuristic to tell whether text is in UTF-8
>or an ISO 8859 variant.

I agree that we can't reasonably know what the character set is supposed
to be in that case.  But I would say that given the choice between
sending 'something wrong' and 'erroring out', 'erroring out' is the more
correct option.  But I would be interested in hearing what other people
think.

>Maybe we could just leave off the character set spec if it turns out to
>be definitely wrong?

As Ralph pointed out, that means the same as us-ascii ... and we know
that's wrong.  Before, it looks like we would generate a character set
of x-unknown; I'm not in love with that either.  Really, it seems like
this exposes something wrong that the user should correct.  Also, if
your forwarding messages with 8-bit characters, you should really be
using forw -mime.

--Ken