Re: [EAI] Body parts

[John C Klensin <klensin at jck.com>]

--On Sunday, 13 July, 2008 09:21 +0200 Arnt Gulbrandsen
<arnt at oryx.com> wrote:

> John C Klensin writes:
>> ... send MIME content-type information and file names that
>> are  inconsistent with each other.
> 
> Or content-type information which doesn't describe the
> charset(s) actually used.

My intent was to cover that case too without going into great
detail.  But you are, of course, correct.

> In my experience (I get to analyze
> those things when they arrive, and guess what happened at the
> sender) it happens when two pieces of software don't talk to
> each other enough. Consider typical webmail: A browser
> delivers the body text and some header fields, some
> advertising system delivers a spamfooter, and the webmail
> backend makes the rest of the header and glues it all
> together. Lots of opportunities for misunderstanding.

Indeed.  The problem is aggravated by something else, which has
turned out to be one of the bigger problems in handling
international character sets in MIME:  Suppose someone sends a
message in charset X to a user whose environment is normally set
up for charset Y.  That second user is able to read messages
marked as being in charset X (which isn't always true).  But, if
the second user then excerpts a piece of the message and
replies, the reply typically goes out in charset Y, especially
if some of the second user's characters are needed in the reply.
In general, unless Y is UTF-8, whatever happens next is bad news
-- the message goes out labeled as charset=Y, it contains some
characters that are really in charset X, but the MUA belonging
to the recipient of the reply has no clue about what is going on
and the original characters are displayed as trash, even if that
recipient is perfectly capable of handling charset X.

It may be that we should have including charset-switching tags
in enriched text, but that format is so little used (as a
percentage of total legitimate messages sent) that it might have
made little difference.  The problem will presumably go away as
more and more of us switch to UTF-8, but that doesn't seem to be
happening quickly... and I don't see a changed default in a
standard as accelerating it very much, even if we were in a
position to do that.

> IMO a UTF8SMTP would make things worse, not better, since
> there would be one more thing to get wrong.

Maybe.  On the other hand, the drafts permit one, and only one,
charset to be used in headers and that is UTF-8.  There is no
mechanism to say "my headers are really in Slobbovian Alphabet
4" and that omission is deliberate.   So we won't have problems
of someone identifying one charset and sending another, headers
with mixed charsets, etc.  While I believe it will be some years
before we can formally deprecate all of the sundry [older]
methods for encoding non-ASCII characters into headers, I do
think that, if and when those standards are updated, it is time
to attach a "SHOULD use encoded UTF-8 and UTF-8 only" to them,
which would be, IMO, a big step in the right direction.

But _any_ extension, to anything, creates more opportunities for
the careless, stupid, or malicious to get things wrong.  It is
the price one pays.

   john




_______________________________________________
IMA mailing list
IMA at ietf.org
https://www.ietf.org/mailman/listinfo/ima