[OT] Charset encoding was Re: Can't connect to port 25 from another system
Ed Greshko
Ed.Greshko at greshko.com
Tue Apr 25 07:33:20 UTC 2006
Tim wrote:
> On Tue, 2006-04-25 at 08:55 +0800, Ed Greshko wrote:
>> There is no issue with UTF-8. There may be problems with someones
>> implementation...and that goes for any charset encoding...but there is
>> absolutely no issues with UTF-8. Anyone that tell you this is blowing
>> smoke, spreading FUD, and just plain wrong.
>
> Sending anything that requires 8-bit data through e-mail *can* be a
> problem, this is *real*, whether you like it or not. It's not usually a
> problem, but it does occasionally crop up.
Not with modern email clients. They all work in MIME and encode in
base64 or QP. All recent MTA's are 8-bit clean.
> Various mail systems will transcode 8-bit data to 7-bit, and some *will*
> screw that up. With more chance of that happening if your mail client
> doesn't identify what it's doing (i.e. it doesn't say it used UTF-8, or
> ISO-8859-1, or something else), and the transcoding client assumes
> something else.
Poor implementation. If you have this problem...you need to change your
email client. Gmail does a good job.... Thunderbird is wonderful...
> Sometimes, sending your mail as 7-bit avoids that happening (UTF-7 is
> just one attempt at trying to get Unicode through e-mail systems).
> Sometimes sending as 7-bit it will not help, and some mail systems will
> transcode 7-bit into 8-bit, doing so because they think there's some
> advantage in it. Again, mistakes can happen with unidentified mail.
UTF-7 is very uncommon. It was designed for use in ASCII environment
that could not handle 8-bit. But this was back in the "old days".
UTF-7 was never part of the Unicode standard. It was published as RFC
2152. But, it is pretty much supplanted by MIME and base64.
> In either case, mail systems can translate any message content, if they
> feel there's some advantage in doing so (some list servers are notorious
> for doing this, very badly). If you look through the headers of some
> messages, you can see servers noting that they've translated 7-bit into
> 8-bit, then another doing the converse.
More poor implementations...but nothing to do with the use of UTF-7. If
you were to look at most messages I doubt you'd find many...if any using
UFT-7.
> Sending Unicode mail, whether as UTF-7 or UTF-8 can be a problem.
> Probably not so much for this list, as few probably use MS clients. But
> there are plenty of mail clients that don't handle Unicode. UTF-7 is
> much more unusual than UTF-8, so even less clients handle it.
You are very wrong in this regard.
> A point in case about not identifying content properly; many of the Red
> Hat / Fedora announcement list messages do not have headers stating the
> content encoding, and the pages have strange characters splattered
> through them as the content isn't the same as my mail client's default
> (use when guessing) settings. Such messages going through systems that
> translate are prime candidates for further mangling. Changing my
> default encoding is no answer either, because the same problem will
> occur with some other unidentified message content that's not encoded
> the same way.
You are mixing issues.
> At any rate, the original issue came up because of base64 encoded
> message content. Someone's client didn't display it, or someone looked
> at the source code and asked why binary was being posted. Sending text
> that requires 8 bits is one way to trigger an agent into using base64,
> and switching over to a 7-bit encoding is one way to try stopping the
> message getting base64 encoding. I'd try it as an *experiment*, but
> don't see much real point in doing so. Most clients can handle base64
> encoded content. Though it does make messages a bit bigger, but nothing
> like HTML.
It is silly to try to stop mail clients from do these things....
You are right about one thing... Someone's email client didn't display
a message properly. BUT, it wasn't the problem of the sender...it is
the problem of the receiver. The sender need not change anything.
エド
More information about the fedora-list
mailing list