[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Subaddressing (was: Re: A couple of comments on the open issues...)
--On Saturday, 15 February, 2003 09:29 -0800 "Paul Hoffman /
IMC" <phoffman@xxxxxxx> wrote:
[ This thread is about subaddressing ]
I adjusted the subject line in the hope that will be helpful.
In case it isn't clear, I think Paul and I are in complete
agreement about this. Just to be sure, let me try to restate
this as a design principle to see if he agrees...
Whether one uses an IDNA-like approach, or something of
the general character of 8BITADDRESSES (I suspect I'm
going fairly quickly come to hate that term), we don't
want to disrupt local-address opacity. Consequently,
anything that is to be done with subaddresses --or any
other special-purpose parsing of the local-part into
subdivisions for differential processing-- must be
done before encoding on the sending side and processed
post-decoding on the receiving side.
The only exception, or group of exceptions, arise if the
sender and receiver explicit agree, before the address
is sent, on interpreting that address in some specific
fashion. Such an agreement could be via an SMTP
extension or, at least in theory, via some out of band
negotiation or private agreement.
If we can actually agree on that, then a good many of the recent
discussions become irrelevant, and we can move on to other
Where we disagree, I think, is how much that rule can be bent
and whether it is necessary to do so. I am imagining
implementations in which the originating user enters an address
in a local CCS, or Unicode in some form, into an MUA and passes
the message off to the local MTA, which processes it into IMAA.
Variations on that model, without the i18n characters, are very
popular today, and we know roughly how well they work (let's say
the experience has not been uniformly good). The problem is
that the MTA implementers and admins, after long experience,
decide that they are smarter than the user or the MUA-writer
(they are often correct) and start fixing things up. I think
the IMAA approach encourages them to include trying to
understand, and fix, the local part, and that is what worries me
-- experience indicates that the more transparent that
originating MTA can be to what it receives, the less likely we
are to have problems.
If the user types (or pastes) the punycode string for the
local-part into the MUA, and the MTA just passes it on without
looking, I don't have a problem at all, but that really isn't
our objective, is it?
At the other end, the cases that scare me most are the ones that
show up as edge cases in Roy's analysis (Roy, I will respond in
more detail to that later -- I'm considering it rather than
ignoring it). For example, suppose I'm an ISP operating a
commercial mail server and I let my users choose their own
mailbox names. But suppose that server also supports some
control functions, and those control functions are introduced
(I'm going to pick an example that is obviously perverse, but
the more realistic ones are just more complicated to explain) by
a semi-random set of characters that could reasonably include
IESG--. Now, unless I'm careless or an idiot, I prevent users
from creating mailboxes that might conflict with those names.
But, as soon as I do that, the hypothesis that IMAA would permit
any user to create an i18n name without having to negotiate with
the ISP or mail supplier fails. Conversely, if I am careless or
an idiot (there is ample evidence that there are sysadmins out
there with those properties), users create mailboxes for which
messages silently disappear, or my control messages don't show
up, depending on who is unlucky.
There is a possibly-more-interesting case involving a
firewall-gateway that poses as the receiving mail server but
intercepts and parses control messages from the Internet (as
noted in RFC 2979, those critters skirt close to the line of
standards violations, but there are lots of them out there).
Are these high-risk cases? I don't know. But they are
plausible and, so far, we have had a firm rule that we don't put
the email infrastructure at risk while making improvements if
there is any other way. And it is a risk.
Now, by contrast, if the receiving server explicitly says "I'm
prepared to receive i18n addresses" then, whatever standard we
adopt, we can be assured that the server isn't going to muck it
up in some unpredictable way. I think prudence requires looking
at that option very carefully, especially since, as illustrated
above, the notion of users at opposite ends of the network using
IMAA to communicate using Unicode addresses without any of the
intervening MTA being involved may not always work.
And I think that analysis of that part of the issue applies
where the transport encoding is then UTF-8, or Punycode, or
At 8:12 PM -0500 2/14/03, John C Klensin wrote:
There are no standards at all for interpreting the local
part. The standard is "no one but the delivery MTA can try
to interpret the local part in any way".
Getting internationalization at the cost of reduced
functionality for anyone or anything that is now doing
something that conforms should be considered only if it is
the only way. It isn't.
The purpose of the discussion about making IMAA
subaddress-aware is to make is so that the delivery MTA can do
something based on the subaddresses. But IMAA doesn't need to
be subaddress-aware for that to happen. MTAs that do things
with subaddresses already have a processing step for how to
parse a full address and what to do after parsing. Those
processes could simply have a ToUnicode step added before the
processing step, at which point the subaddress delimiters
If we try to make IMAA subaddress-aware, we inherently
restrict the characters that can be used as delimiters for
subaddress. If we don't make IMAA subaddress-aware, there is
no restriction, and current systems work exactly the way they
do now if they add the ToUnicode step before subaddress
We can do a lot of damage and make a lot of restrictions
trying to be smart here. Let's instead go back to IETF first
principles and let the end systems do the thinking.
--Paul Hoffman, Director
--Internet Mail Consortium