
* John C. Klensin:
You would use +12345678901234@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@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.