Date: Mon, 12 May 2014 10:54:33 -0400
From: Ken Hornstein <kenh(_at_)pobox(_dot_)com>
Message-ID:
<201405121453(_dot_)s4CErcOQ002049(_at_)hedwig(_dot_)cmf(_dot_)nrl(_dot_)navy(_dot_)mil>
| but it seems that this is used in
| these weird corner cases by MUAs when the proper character set cannot
| be determined).
It could perhaps justify the choice in a legalistic argument (nit picking
about whether the standards are being followed or not), but that wouldn't
really make it the right choice. I'm not sure I quite agree with Ralph -
just doing just what the RFCs say is not necessarily enough to be able to
say that you're doing the right thing. In some cases the right thing might
actually be do do exactly what the RFCs say not to do (while they're usually
reasonable, becoming an RFC does not guarantee that there are no errors).
We really need to look at the causes and effects, and see what solution is
all around best. Here, as you (or maybe someone else) said in an earlier
message (and again below), using "unknown-8bit" (whether technically
permitted or not) just shifts the burden onto the mail reader - think of
what we do when receiving a message that has a charset set that way. How
are we supposed to correctly display that message to the user? How is
anyone else? This cannot possibly be the right thing to do.
So the effect of that isn't desirable. Now for the cause - that's someone
creating 8 bit characters, and claiming they're US-ASCII - which is a
nonsense combination. At that point you're looking for some way to
automate fixing it (supposedly helping the user deal with sending their
mail) and after all, what else could the code generate? unknown-8bit
is about the only honest value that could be given.
But that's all based on the assumption that actually delivering the
message is the right thing to do. It isn't - whoever gets it has no
rational way to display it (as above), so delivering it isn't very useful
(of course, the receiving mailer is probably also going to be "helpful"
and just guess at an encoding, and display something - even if incorrect.)
Much better is to simply force the local user to correct their configuration.
If they're going to be sending 8 bit characters, they have to set their
environment to indicate just what charset those characters are in (since
we know it cannot be US-ASCII). Initially the user might bitch a bit
about how some other mailer would have sent the message, but once they
discover that fixing their config isn't really all that hard, and that
having done it (just once) recipients of their messages will all be able
to display them as intended, they will eventually come to appreciate having
been coerced to actually address the underlying problem, rather than just
ignore it.
This is a general principle that applies everywhere - well, almost
everywhere, it seems to be often forgotten in the software industry.
But for most things, the accepted principle is, that if it is broken,
fix it, and fix it properly. (In software, the principle is often
"document it, and claim it is a feature" ...)
| It's not clear what happens if we get unknown-8bit, though
exactly.
| (we should probably put something in there to deal with that).
Yes, since it can happen, nmh should deal with it - but please don't
just guess - refuse to display such messages (just as it would if the
message is in a charset that the local system cannot handle). Allow
the message (or message part) to be saved into a file, of course, and then
for the user to use whatever other tools they may have available to
find out what is in there. Then after doing all that work, they can
complain to the sender of the message about the useless encoding info,
and ask them to please not do it again.
This is doing things the right way, never taking the easy way out, and
helping users process their messages by helping them get their messages
all correct - that's the way to really help, the "just do something with
anything so no-one knows we failed, and comlains" just proliferates the
mess.
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers