[enum-wg] ENUM-capable email client?
John C Klensin john-ietf at jck.com
Tue Oct 18 19:29:20 CEST 2005
--On Tuesday, 18 October, 2005 16:32 +0200 Florian Weimer <fw at 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 >> 18.104.22.168.0.9.8.7.22.214.171.124.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
[ enum-wg Archives ]