nmh-workers
[Top] [All Lists]

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

2016-10-17 16:26:00
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>