Re: [idn]=?UTF-8?B?UkU6IFtpZG5dIFJlOiBBbiBpZG4gcHJvdG9jb2wgZm9yIGNvbnNp?==?UTF-8?B?ZGVyYXRpb24gaW4gbWFraW5nIHRoZSByZXEgdWlyZW1lbnRz?=

[ned.freed@innosoft.com]

> After all, at least I, and many here (who wish to be able to read
> messages in Swedish), have had to do upgrades to e-mail (client)
> software about twice a year (less often for the server software),
> just to get it to work better (i.e. overcome bugs).  New supplier,
> new bugs, new stair of bug reports and upgrades.

Upgrading software to fix a bug or two is one thing, having to upgrade
software so it works at all is quite another.

> It would mean that one need to keep track of fallback addresses for
> some time, and probably use only the fallback addresses initially,
> until the 'proper' addresses gradually start working.

Let's see. It has been almost 10 years since the MIME work started, and there
are still MTAs, user agents, and gateways that don't handle 8bit in message
bodies even though it is now legal, to say nothing of message headers and
envelopes, where it is still illegal.

Now, to be fair, one of the reasons why such agents still exist is because
we deliberately refrained from breaking them. We used a combination of
negotiation and encoding.

But on the flip side during the past 10 years the amount of infrastructure that
would have to be upgraded to address any new issue has grown by a truly
staggering amount.

What does this say about the prospects for another transition now, especially
one where you propose that no automatic fallback mechanisms be provided?

> Some email clients may help with that, and find a substitute target
> address in ASCII by asking the DNS for a main name (in ASCII) from
> the given UTF-8 (but non-ASCII) name if (for now hypothetical)
> ESMTP/UTF8HEADERS is not available. (But maybe I'm exposing my
> naïvité on how email works...)

I'm afraid you are doing exactly that.

> And again, I don't worry much about servers (MTAs) that would 'fall
> over and die' because of '8-bit' in headers.  Those would be too
> vulnarable to attack to be in continued use anyway.

The past week's DDOS attacks on various high profile sites using nothing but
tools and techniques we've been warned about repeatedly demonstrate that your
assumption that people won't use vulnerable and defensible systems is
completely without basis in fact. People will continue to run software that is
incredibly vulnerable up to and even well past the point where those
vulnerabilities are exploited. This has been demonstrated over and over and
over again.

However, as I have said repeatedly, this "fall over and die" stuff is nothing
but a strawman argument anyhow. Most MTAs won't fall over and die. But what
will happen is that the mail you send will be bounced. And once it bounces it
won't be deliverable back to the originator either. If you're lucky it will end
up in some postmaster mailbox somewhere, where it will likely just be deleted.
And if you're not lucky it will simply disappear.

Do you seriously think that having your messages vanish silently into a black
hole because you used a particular character in a domain name is acceptable? I
don't. The 8bitMIME extension had to be designed very very carefully to prevent
this from happening, and frankly, in hindsight, I don't think we went far
enough in imposing downgrading requirements at the time.

Folks, we are simply repeating the same arguments that were made almost 10
years ago. And if anything the problem since then has gotten larger and more
entrenched. (If you don't believe this, consider the difficulty of upgrading a
system where email handling is implemented on a chip. Such things already exist
and are beginning to deploy -- see www.connectone.com for an example. My first
thought on reading it was, "I wonder if they handle RFC 2047?")

> > A very significant percentage of the Internet E-mail plumbing
> ...
> > How do you propose to replace all of that?

> Not all at once obviously.  But ESMTP (with as yet only two extensions)
> has replaced SMTP.  Assuming that an ESMTP/UTF8HEADERS extension
> is drafted and approved, that extension could (and would, I hope)
> be implemented and gradually deployed.

An extension along the lines of 8bitMIME certainly could be developed. But
such an extension requires a fallback strategy, just as 8bitMIME does. And the
fallback mechanism has to be automatic; "send and pray" is unacceptable.
And this in turn has a direct and serious impact on the IDN proposal, since
different proposals will make such a fallback strategy either possible or
impossible. My assertion was and that a proposal that uses 8bit and doesn't
have a viable fallback strategy is unacceptable.

As an example of a possible fallback strategy, suppose we add a new fallback
record to the DNS that translates a UTF-8 name to an equivalent ASCII name. An
MTA that receives a UTF8HEADER message could then, if it had to, translate the
8bit domain names to a fallback names. This is not appreciably worse than
8bitMIME in terms of implementation complexity. But it absolutely does require
support in the IDN proposal to make it work. And the addition of a new record
type is likely to take a while to deploy. But eventually, should
UTF8HEADER-capable software come to dominate, the fallback records could be
dispensed with.

Now compare this with the 7bit proposals. In such cases user gratification is
immediate; you can register international domain names right off and have
them work and people can upgrade their display software (or not) any time
they want. But the underlying mechanisms are ugly now and stay that way
forever.

Again, I'm not advocating either 7bit or 8bit DNS entries. Personally, I'm
neutral on the subject. But what I'm hearing is "just use UTF-8", and as I
said before, that dog just won't hunt.

				Ned