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