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(_at_)domain <mailbox(_at_)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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by
2009-01-05.
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf