>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
>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.
Nmh-workers mailing list