Re: Last Call: draft-ietf-eai-downgrade (Downgrading mechanism for Email Address Internationalization) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi.

This comment is deliberately being submitted a couple of days
after the Last Call closes because it does not address any
technical issues with the document under consideration.   As
discussed below, I believe that the current document should be
published as Experimental.   However, I believe that the general
model of the specification raises issues that the community
should consider very broadly in the coming months.  These issues
do not come as a surprise to the WG and were identified there
many months ago.  The WG concluded that downgrading was
important, a decision I support at least to the extent of
publishing this document.

I strongly support the publication of this document, as written,
as Experimental. I believe that further fussing with small
details will, by introducing more delays after the core email
i18n documents have been published, probably cause more
problems than it might solve.

However, I encourage the community to monitor and evaluate the
use of this specification in the environment of the Internet's
actual, running, email systems, not just to accept
demonstrations among cooperating and coordinated parties as
evidence of a successful experiment.  The downgrade model adds
a huge amount of complexity to the EAI protocol collection and
there appears to be no less complex way to provide in-transit
downgrading.  I believe the community needs to evaluate the
advantages of in-transit downgrading for the casts in which it
will apply (there are many for which it will not) against the
cost of the complexity (including its cost as a deterrent to
EAI implementations) it introduces.  It appears to me that a
follow-on standards-track EAI specification should probably not
include this capability.

_Summary_ 

While I had some small role in the design of the downgrade
model and believe it is the best we can do, I have concluded
that it is a mistake and that it violates some fundamental
principles of protocol design generally and email in
particular.

Details, including some summary information that will be
familiar to anyone who has studied the specification and its
relationship to the other EAI documents, appear below.

_A Contextual Review of the Downgrading Idea_

Everyone should understand that downgrading introduces 

(1) New syntax for carrying alternate (all-ASCII) addresses in
    both SMTP and mail headers.  While the SMTP form is
	probably harmless (the information is carried in a
	parameter which the server must agree to accept), the
	header form --the form most likely to leak into other
	environments-- is likely to cause parsing errors and/or
	general confusion if seen by non-EAI-aware systems or
	users.

(2) A series of new headers in an attempt to preserve
    information.  Given the existence of systems on the
	Internet that will strip headers that they do not recognize
	in the interest of security, these headers may be discarded
	by some systems that are not upgraded to support them,
	losing precisely the information that they are intended to
	preserve. 	Whether it is likely that such systems will be
	upgraded without being make fully EAI-competent is an open
	question whose answer requires a good deal of speculation
	about implementer behavior.

(3) Far more implementation work --at least for an "eight-bit
    clean" environment-- to support those features than would
	be needed to convert existing systems to support the other
	EAI features.  More on this below.

I do not believe there is any controversy about those three
points.  The question is whether it is worth it.

Downgrading is also not automatically effective.  For it to
have any hope of working, the user originating the message (or
a user-side agent) must obtain and supply alternate (all-ASCII)
addresses for every non-ASCII address that appears in the
envelope and headers.  If there is a non-ASCII address without
an associated all-ASCII one, then the message cannot be
downgraded at all and must be rejected if it cannot be
forwarded along an EAI-conformant path.  As with 8BITMIME, a
conforming implementation may choose to reject a message if it
cannot be forwarded along a conforming path rather than
downgrading it.  One of the experimental questions is how many
implementations will select that less complex option.

After trying to analyze the use cases and weigh them against
the huge amount of complexity this adds to the email system
generally and to EAI in particular, I think the experiment
should specifically examine the question of whether that
complexity is worth it and, in particular, whether the
expectation of implementing may actually retard the deployment
of UTF-8 email addresses and structures.  Ultimately, an
"alternate address" is just that -- an "if this address doesn't
work, try that one" mechanism for messages in transit.  We have
never had that in Internet mail and even the early bright ideas
about automatic address correction (represented in the SMTP 251
and 551 "here is the user's real address" codes) have not
worked well and might be considered privacy problems today.
I'm aware of one mail system that did have automatic address
correction: it was not a success and the system has faded away
into obscurity.  In order to support automatic address
correction, we have added headers that may not get through
poor-quality relay implementations of SMTP (especially
including those associated with firewalls) and added
considerable complexity to post-delivery protocols and models
to try to restore the original form of the message.  At one
time or another in the past, we've had several systems that
have tried to figure out how to deliver messages in spite of
addresses that didn't quite match.  They haven't worked well
either except when used in connection with a global
user/address directory and sending MUAs that communicated
directly with that directory, features we certainly can't
arrange for Internet mail.

I'm also concerned about side-effects and abuse.  The alternate
address model associates two addresses with no guarantee that
they are actually related.  The risks associated with that may
not be larger than those associated with ordinary insecure
email, but, because the transformations are applied in-transit,
may make it even easier to trick users in ways that we don't
understand yet.  It also presents opportunities for spammers,
raises issues with digitally-signed messages (including some
that are similar to the recent discussion of how multiple
header "From:" field values interact with DKIM), etc.  We can
deal with most of those to at least some degree, but only with
more complexity in other places. 

By contrast, if we abandon an in-transit downgrading protocol,
EAI becomes an extremely simple implementation for the
transport path.  At least some eight-bit-clean implementations
merely need to add support for an additional SMTP option and
remove restrictions that require ASCII-only addresses.
Messages that cannot be delivered as addressed get rejected (at
SMTP time if possible), and rejection for an unsupported SMTP
option or an undeliverable address are among the easiest to do
at SMTP time.  That rejection gives the sender the clear
indication that the address path didn't work and that some
other address or path needs to be found.  Even if the messages
bounce, there are good odds of things working properly and the
sender being notified, especially in the very common case of a
direct connection between the Submission and Delivery MTAs.

Post-delivery processing, specifically IMAP and POP, still need
to worry about UTF8-capable clients with ASCII-only mail stores
and vice versa, but even their complexity level goes down.
Post-delivery protocols also have an advantage over anything
done in transit: the risk of information that they rearrange
being deleted is much lower and normally under the same
administrative control.

I also note that we've got a general design principle that
facilities introduced for transition should not cause major
clutter after the transition is over.  8BITMIME is like that:
with most of the infrastructure converted to handle it, we no
longer spend a lot of time worrying about which systems support
that form of downgrading and the downgraded forms are standard
and needed for other purposes.  Systems still have to assert
the capability, but that is not a big deal.  By contrast, if we
introduce the rather unpleasant-looking 

  Personal Name <mailbox@domain <mailbox@domain>>

syntax, it will be with us forever, will cause problems when
the addresses leak into systems that don't know how to parse
it, will confuse users who have become used to the format that
we've used for several decades, and so on.  Adding another set
of headers that can be interpreted accurately unless linked to
other headers isn't doing email robustness any favors either --
perhaps worth it if the marginal value it produced was high
enough, but I'm just not convinced of that any longer.

So, as we carry out the experiment of seeing how "downgrade"
works as an experimental protocol in a full Internet email
environment, I think we should

(i) Try to carefully evaluate whether it actually turns out to
    be useful in enough real, plausible, cases (not just
	tests) to be worth all of the complexity and trouble.

(ii) Think about whether there are other approaches that would
	add less complexity to the email system and be more
	reliable in what I predict will be the common case of
	having some UTF8-format addresses to a message with
	alternate addresses and some that don't have those
	alternates, the mailing list cases, etc.  One such approach
	might involve a protocol for directory services linked to
	a destination system, one that could give a sending MUA or
	Submission MTA alternate address information when messages
	containing the primary address were returned as
	undeliverable.   That would require significant sending MUA
	and/or Submission MTA work, but that work could be done by
	those who were motivated without requiring complexity in
	the broader Internet mail environment.

(iii) Think about whether we can appreciably decrease the
    complexity of a downgrade mechanism if we designed it for
	the envelope reverse path only, i.e., to be sure that we
	have a place to send error messages and other MTA-level
	notifications.  The reverse path is the really troubling
	case that requires some sort of transition strategy because
	undeliverable notifications cause mail to disappear.  But,
	if we can deal with that case at relatively low complexity,
	perhaps we should consider the tradeoffs between the
	complexity of the full downgrade mechanism and a strong
	recommendation that users include alternate addresses in
	signature lines for the cases in which "reply to
	originator" fails (some people do that already, for other
	reasons, so it isn't exactly an innovation.

Again, I think Downgrade should be published as Experimental,
both to demonstrate what is required if one is going to have
such a facility and to see if it actually works better and more
often than I anticipate.  But, at this point, I consider it a
very poor candidate for standardization and a risk if widely
deployed.

thanks,
     john


--On Monday, December 22, 2008 16:18 -0800 The IESG
<iesg-secretary@xxxxxxxx> wrote:

> The IESG has received a request from the Email Address 
> Internationalization WG (eai) to consider the following
> document:
> 
> - 'Downgrading mechanism for Email Address
> Internationalization '    <draft-ietf-eai-downgrade-10.txt> as
> an Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2009-01-05.
>...
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]