About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [enum-wg] ENUM-capable email client?

  • To: Florian Weimer <
    >,Carsten Schiefner <
    >
  • From: John C Klensin <
    >
  • Date: Mon, 17 Oct 2005 10:35:26 -0400


--On Monday, 17 October, 2005 15:07 +0200 Florian Weimer
fw@localhost 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@localhost.
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@localhost 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@localhost
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




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community