[enum-wg] ENUM-capable email client?

* John C. Klensin:

>> You would use +12345678901234 at e164.arpa, 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. 

This is just another form of forwarding, with a DNS-based alias
database.  I don't see a real conceptual problem with this approach.
You can even keep the e164.arpa address across the network, although
this might cause hassles for MTAs which are traditionally weak on
local-part-based routing (I'm not sure if there are many of those
left, though).

> 	* 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).

No, the effect of "MX ." is that mail bounces immediately.

> In thinking about this, you should be aware of something else if
> you are not: although +12345678901234 at e164.arpa 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.

Sure, you can't get full interoperability with an address that
contains a "+" in the local-part, or a domain under the ARPA TLD.

But even fewer sites will accept a plain "+12345678901234".  If MUAs
create the impression that phone numbers behave like email addresses,
people will expect that they can be substituted for email addresses in
other places as well.  If the major MTA vendors adopt ENUM routing via
e164.arpa in their default configurations, we have at least some
chance that a lot of applications will do the right thing more or less
by accident.  That's why the local MTA on UNIX systems, the one behind
/usr/sbin/sendmail, will implement ENUM routing, and not each mail
client individually.  From that, it's just a small step to support
ENUM routing over Submission as well.

Another thing worth considering: client-side NAPTR processing
interferes badly with mobile hosts which are temporarily located on
networks where the assigned DNS resolver does not support NAPTR
records (and just returns SERVFAIL, for example).  I expect such
networks to be quite common for quite some time.

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

The introduction of the LOCAL TLD is well within that territory of
breakage, and it was considered acceptable by the IETF.  Yet another
special case wouldn't be *that* different.