Re: [exim] Valid Chars in Headers of Emails

Tony Finch wrote:

> On Fri, 4 Aug 2006, Philip Hazel wrote:
>
>>On Fri, 4 Aug 2006, W B Hacker wrote:
>>
>>
>>>I'd far rather see UTF-8 compatibility than a breakup of top-level
>>>routers into, for example, Chinese encoding and ASCII.
>>
>>Me too!
>
>
> I've been following the Email Address Internationalization discussions,
> and the direction they have chosen is to extend SMTP to allow UTF8 local
> parts, domains, and message headers. I think this is great. (Exi18n,
> anyone?)
>
> It probably wasn't possible to do this much before now, because it can't
> be done without a universal character set - imagine having to tag email
> addresses with charsets, as you currently have to do with RFC 2047
> encoding of non-ASCII header text. Yuck. (Charset tags are less of a
> problem when they are much smaller than the data they are tagging, as is
> the case for MIME message parts.)

I've been involved in this - in one way or another - since before ASCII came on
the scene, and everything tried has meant one compromise or many.

To date, UTF8 seems to be the least-evil of such compromises, partly because
ASCII and several other common legacy encodings can function as reasonably
complete subsets, and partly because it doesn't 'waste' more bytes than
necessary on what are, after all, usually 'minority' national-language charsets.

Plan 9 may not be remembered for much else, but UTF8 is a fine legacy for it to
have introduced to the world. Almost enough to forgive Ken for 'ed'

;-)


>
> UTF8SMTP is also being done based on the successful experience of MIME and
> ESMTP, which by now have pretty much completely displaced flat ASCII email
> and non-extensible SMTP. Part of the hope is that, although we'll have to
> start off with support for downgrading from UTF8SMTP to 7 bit SMTP,
> eventually we should be able to just-send-8 - which is what most MTAs
> currently do for 8BITMIME.
>
> Speaking of which, there are currently three levels of transparency in
> SMTP: 7 bit, 8BITMIME and BINARYMIME. The difference between the last two
> is that 8BITMIME is allowed to have restrictions on line lengths and
> control characters, and in particular it may screw up line endings - for
> example, Exim has this limitation. BINARYMIME also requires the CHUNKING
> extension to avoid problems caused by trad SMTP's line-based dot-stuffing
> message delimiting. I would really like wider support for binary email,
> but it's much harder to do once you consider upgrading message stores and
> MUAs as well as MTAs...
>
> Tony.

'Binary email' AFAIAC is scp..... or attachments to anything else handy...

tar, zip, or bfe it if need be.

Header format is where the work is. So, too with TCP/IP, ATM, or even ARCnet.

TANSTAAFL

;-)

Bill