ENUM-capable email client?
All, there is a Firefox ENUM plug-in (currently for Win only) available at: http://www.falb.at/ that resolves enum:[E.164 number] to an URL in case such web service is specified in the respective ENUM zone to that very E.164 number. E.g., with this plug-in, a click on enum:+43780325228 would get you to Juergen Falb's homepage, too. My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address? Best regards, Carsten Schiefner
Carsten Schiefner wrote:
[...]
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
In the meantime I have been pointed at: http://www.enum.cn/Enum/EnumReg/member.php?language=English - has anyone already gained experience with these extensions? Two questions: 1) is it generic, i.e. does it work with all IE and Outlook installations, or does it require a localised-to-chinese version? Although I am not totally happy with either one of these programs, I do not have any need for a broken installion... 2) I stumbled over "The number should be registered ENUM number of www.enum.cn": does it only work with Chinese numbers or is it using the complete e164.arpa tree for resolution? Besides that: any other pointers are still welcome, of course! :-) Best, Carsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Carsten, if you have a look at http://www.aarnet.edu.au/services/enum/enum_use.html you find a small list of tools you can use with ENUM. Kewin Carsten Schiefner wrote:
Carsten Schiefner wrote:
[...]
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
In the meantime I have been pointed at:
http://www.enum.cn/Enum/EnumReg/member.php?language=English
- has anyone already gained experience with these extensions? Two questions:
1) is it generic, i.e. does it work with all IE and Outlook installations, or does it require a localised-to-chinese version? Although I am not totally happy with either one of these programs, I do not have any need for a broken installion...
2) I stumbled over "The number should be registered ENUM number of www.enum.cn": does it only work with Chinese numbers or is it using the complete e164.arpa tree for resolution?
Besides that: any other pointers are still welcome, of course! :-)
Best,
Carsten
- -- - ---------------------------------------------- Australian Academic and Research Network (AARNet) Kewin Stoeckigt Building 9, Banks Street Canberra ACT 2600 Australia Phone: +61 2 6222 3546 Fax: +61 2 6222 3535 Mobile:+61 4 2158 2563 Email: kewin.stoeckigt@aarnet.edu.au SIP: kewin.stoeckigt@aarnet.edu.au WWW: http://www.aarnet.edu.au/~kos/ - ----------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDR2tMbhxXquPpou8RAu8jAJ0SoZcPeKE9GaThfK0XR5NJbYgDgwCbBD/k 5+eOSuFcTLlOJWoj4cvz8p0= =c+hi -----END PGP SIGNATURE-----
Hi Kewin, Kewin Stoeckigt wrote:
Hi Carsten, if you have a look at http://www.aarnet.edu.au/services/enum/enum_use.html you find a small list of tools you can use with ENUM.
thanks for the link! :-) Best, Carsten
* Carsten Schiefner:
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
Shouldn't this be part of the MTA, and not the MUA? After all, it's some kind of mail routing.
--On Monday, 17 October, 2005 15:07 +0200 Florian Weimer <fw@deneb.enyo.de> wrote:
* Carsten Schiefner:
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
Shouldn't this be part of the MTA, and not the MUA? After all, it's some kind of mail routing.
The only way to make it part of the MTA would defeat what I consider the fundamental purpose of ENUM. I believe that purpose is not merely to establish a way to map between phone numbers and most of a a domain name (i.e., the reversing process established in RFC 1528 and 1530) but to provide a "single tree" so that the rightmost components of the domain name do not need to be specified by the user. At present, there is a firm SMTP requirement that any email address by expressed as local-part@fully-qualified-domain-name. Even if you could get community approval of the change, 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@example.com could be a valid email address today, having nothing to do with ENUM. While RFC 2821 has a prohibition on MTAs accepting a local part and making up a domain name, precisely that is permitted for submission servers (first-hop MTAs under some circumstances). So, for example, suppose that smtp.bogus.domain.name is a submission server that now has the convention that, if it receives RCPT TO:<some-unqualified-name> it is to change it to RCPT TO:<some-unqualified-name@bogus.domain.name> and "some-unqualified-name" might be all-digits or all-digits preceded by a plus-sign, it is going to have a very hard time figuring out which unqualified names should be mapped that way and which ones should be reversed and catenated to ".e164.arpa." This really is an MUA function, where there are any number of ways that those transformations might be determined. john
* 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@example.com could be a valid email address today, having nothing to do with ENUM.
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.) 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.
On Mon, Oct 17, 2005 at 07:23:09PM +0200, Florian Weimer wrote:
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.)
It should not. Last news about the necessary A RR for "." came from a parallel universe and draft-delany-nullmx-00.txt just misses the operational consequences. Using the "@e164.arpa" part to deviate from the standard mail routing algorithm won't fly. -Peter
* Peter Koch:
It should not. Last news about the necessary A RR for "." came from a parallel universe and draft-delany-nullmx-00.txt just misses the operational consequences. Using the "@e164.arpa" part to deviate from the standard mail routing algorithm won't fly.
What about reusing the TPC.INT approach? (AFAIK, RegTP forbids adding MX records under 9.4.e164.arpa, but this impossible to enforce, of course. 8-)
--On Monday, 17 October, 2005 19:23 +0200 Florian Weimer <fw@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@example.com could be a valid email address today, having nothing to do with ENUM.
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. * 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@e164.arpa 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@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
* 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.
--On Tuesday, 18 October, 2005 16:32 +0200 Florian Weimer <fw@deneb.enyo.de> wrote:
...
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).
Florian, We seem to be misunderstanding each other, and I don't why. In particular, I don't know what you mean by "weak on local-part-based routing" since any MTA, other than a final delivery one, that does _any_ routing on the content of the local part is in clear violation of the SMTP standard. I don't know if you think an MTA is weak because it follows the standard or weak because it violates it. As far as an empty data field in an MX record is concerned, which I now understand is what you are suggesting, there is, to put it mildly, no standard way to interpret one of those. SMTP considers them invalid as, I believe, do the DNS standards. There is no guarantee that an address that resolved to one would result in rejection or a bounce rather than in some very unpleasant failure behavior. john
* John C. Klensin:
We seem to be misunderstanding each other, and I don't why. In particular, I don't know what you mean by "weak on local-part-based routing" since any MTA, other than a final delivery one, that does _any_ routing on the content of the local part is in clear violation of the SMTP standard. I don't know if you think an MTA is weak because it follows the standard or weak because it violates it.
RFC 2476 (SMTP Submission) does in fact allow rewriting local-parts. 8-) But I can understand that there are conceptual problems if you do this potentially on each hop. But at the time of message injection -- why not? I can assure that this is the way ENUM-based client-side mail routing will be implemented on UNIX platforms. It belongs into the local MTA, not the MUA. However, I have some doubt whether it's a good idea to promote E.164-based addressing beyond VoIP. For example, if I obtained an ENUM delegation and started hosting a copyright-infringing web site on <http://4.0.5.0.7.0.8.1.1.7.9.4.e164.arpa/>, how would the copyright holder be able to track me down?
Florian Weimer wrote:
* Carsten Schiefner:
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
Shouldn't this be part of the MTA, and not the MUA? After all, it's some kind of mail routing.
IMO the ENUM lookup should be done in the client before sending the Email to the MTA. Because if there is no email address asscoiated with the E.164 phone number, the client can show the problem to the user immediately, wheras the the MTA would have to generate an error message. regards klaus
Klaus Darilion wrote:
Florian Weimer wrote:
* Carsten Schiefner:
My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address?
Shouldn't this be part of the MTA, and not the MUA? After all, it's some kind of mail routing.
IMO the ENUM lookup should be done in the client before sending the Email to the MTA. Because if there is no email address asscoiated with the E.164 phone number, the client can show the problem to the user immediately, wheras the the MTA would have to generate an error message.
oh - another point for the "User experience" section in an Enumservice definition... cheers alex
participants (7)
-
Alexander Mayrhofer -
Carsten Schiefner -
Florian Weimer -
John C Klensin -
Kewin Stoeckigt -
Klaus Darilion -
Peter Koch