Subaddressing (was: Re: A couple of comments on the open issues...)

--On Saturday, 15 February, 2003 09:29 -0800 "Paul Hoffman / 
IMC" <[email protected]> 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