[enum-wg] ENUM-capable email client?
John C Klensin john-ietf at jck.com
Mon Oct 17 19:51:55 CEST 2005
--On Monday, 17 October, 2005 19:23 +0200 Florian Weimer <fw at deneb.enyo.de> 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 at example.com could be a valid email address >> today, having nothing to do with ENUM. > > 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 22.214.171.124.0.9.8.7.126.96.36.199.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 at e164.arpa into 188.8.131.52.0.9.8.7.184.108.40.206.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 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. 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
[ enum-wg Archives ]