[enum-wg] ENUM-capable email client?
Florian Weimer fw at deneb.enyo.de
Tue Oct 18 16:32:53 CEST 2005
* 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 > 126.96.36.199.0.9.8.7.188.8.131.52.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.
[ enum-wg Archives ]