Re: [EAI] Add requirement for punycode conversions in downgrade

[John C Klensin <klensin at jck.com>]

--On Tuesday, 18 March, 2008 22:23 +0100 Harald Tveit Alvestrand
<harald at alvestrand.no> wrote:

> Ernie Dainow skrev:
>> 
>> If Downgrade fails when sending to a recipient of the form 
>> ascii at non-ascii , what is the recourse for the user? A very
>> few IDNA  literate users might figure out how to do a
>> punycode conversion and  use it as an Alternate Address. Most
>> users would have to revert to  using a traditional email
>> client. 
> Well, there are some possibilities for why we get that
> situation:
> 
> - User (or admin) has forgotten to set the Alternate Address
> (misconfiguration). Is it better for a mid-net relay to pass
> the message or to report to the sender that there's a
> misconfiguratoin?
> 
> - User (or admin) has decided that he doesn't care whether or
> not messages get to non-UTF8SMTP users. Is it better for a
> mid-net relay to pass the message or to report to the sender
> that his wishes have been "honored"?
> 
> - User (or admin) expected this message to go to only UTF8SMTP
> users. Is it better for a mid-net relay to pass the message or
> to report to the sender that his expectation was unrealistic?
> 
> Note: I don't know whether the answers are one or the other.
> But I can see arguments on both sides of the issue - "pass the
> message" is not necessarily always the right choice.

I think we are on the same page.  I don't know what the right
answer is (either), but "convert and pass" is not as obvious to
me as it apparently is to Ernie.

Two other observations:

	* I haven't seen an analysis of the potential "leakage"
	cases, and whether or not they are a problem, yet.
	
	* Unless we get IDNA200X through, and get to an end
	result with no input-side mapping, Ernie's comment "The
	user interface at the recipient can and probably should
	translate punycode domains back to the original UTF8" is
	basically not possible to satisfy.  The interface can
	translate back to some approximation to the "original"
	UTF8, but, since IDNA2003 ToASCII provides a many
	(perhaps one should say "many-many") to one mapping, the
	receiving MUA will not have sufficient information to
	reconstruct the original UTF8, only an IDNA-equivalent
	version of it.

--john


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www.ietf.org/mailman/listinfo/ima