[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 topics.

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 something else.

john


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".

Exactly right.

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.

Fully agree.

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
appear.

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
processing.

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