Re: [enum-wg] ENUM-capable email client?

[John C Klensin <]

--On Monday, 17 October, 2005 19:23 +0200 Florian Weimer
fw@localhost wrote:

> * John C. Klensin:
> 
>> permitting, e.g., 
>>    +12345678901234
>> 
>> as an email address would require changing of every MTA in the
>> network before ENUM->email would work reliably.  Such
>> agreement is unlikely.  For example,
>> +12345678901234@localhost could be a valid email address
>> today, having nothing to do with ENUM.
> 
> You would use +12345678901234@localhost, I guess, where the
> @e164.arpa part could be supplied by the MUA.  (Of course,
> e164.arpa should have a "MX ." RR.)

There are two ways (at least that I can think of) to implement
that suggestion...

	* With one, the MTA would somehow look at that string
	and rewrite it into
	4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa.  If any
	intermediate did that, it would really push the limits
	on the principle that intermediate MTAs not try to
	interpret or rewrite local-parts. 
	
	* With the other, the mail would actually be delivered
	to the MTA for e164.arpa (that would be the effect of
	the wildcard MX I think you are suggesting).   That
	would work, but raises two issues.  First, it would
	create a single, or concentrated, point of failure,
	which is part of what ENUM was intended to avoid.
	Second, at least formally, the rewriting of
	+12345678901234@localhost into
	4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa and resending the
	mail is an MUA function, even if it is performed on
	behalf of the user by an MTA halfway out in the network.

In thinking about this, you should be aware of something else if
you are not: although +12345678901234@localhost is a perfectly
valid email address under the rules of RFC 2821 and 2822, a huge
number of web sites and web-based mail systems will treat it as
invalid.  If anything, the number seems to be on the rise
despite efforts to turn back the tide.  So, realistically,
unless the transformation is handled in the MUA (or you assume
that any all-digit local part is an E.164 address) strings
starting in "+" are going to fail regularly enough to create
their own set of problems.

> If you opt for a purely MUA-based approach, you can never-ever
> put E.164 addresses in the message header.  ENUM email
> addresses would remain second-class citizens, just like
> internationalized domain names implemented with IDNA.

As is the case with the work underway with internationalized
email addressing (see, e.g., the "IEE" BoF scheduled for
Vancouver and the documents listed in its agenda), we should go
as far as possible in supporting new ways of doing things as
long as we do not, in the process, break the existing
infrastructure.  If someone wants to provide, fund, and support
mail servers for e164.arpa that perform the remapping you
suggest, are robust and scalable enough to support the relevant
workload, and can work out sufficient trust arrangements with
the relevant communities, then so be it.  But expecting MTAs to
start rewriting addresses that have some particular set of
syntax characteristics strikes me and being well within the
range of breaking things that are legitimate uses today.

    john