[Top] [All Lists]

Re: Minor is. It's not a pardigm change

2008-04-05 01:01:14

--On Wednesday, 02 April, 2008 00:17 -0400 "Robert A. Rosenberg"
<hal9001(_at_)panix(_dot_)com> wrote:

At 23:00 -0400 on 03/31/2008, John C Klensin wrote about Re:
Minor is. It's not a pardigm change:

Once that implicit MX record exists, there are fairly clear
rules  about which address to use for   To
be a little  more precise, while the rules are clear, they
pretty much leave it  up to the sending host and there is no
real difference between the  traditional choice between the
two IPv4 addresses and the newer  choice between the IPv4
addresses and the IPv6 one.   The Standard  also gives the
sender implementation some flexibility about how many  of
those addresses it is obligated to try.

I disagree with your methodology. If the rule is that incoming
MTAs (ie: Those MTAs that are supposed to be located via MXs)
which listen at an IPv6 IPN are REQUIRED to be designed by an
MX (ie: You are not treated as an incoming IPv6 MTA UNLESS you
are pointed to by an MX), any implicate MX that is built in
the absence of an EXPLICATE MX should contain ONLY the A
records for that FQDN. Any AAAA records for the FQDN are
ignored in building the implicate MX.

This is interesting, but I have no idea what you are talking
about.  MX records contain names, not address records in the
DATA.  That has been clear since the beginning and 2821
reinforces it.  Certainly it is possible to assign one DNS name
to the set of IPv4 interfaces on a host and another name to the
set of IPv6 interfaces, but, as soon as one does that, there
are, as far as the DNS is concerned, two separate hosts.

If I correctly understand what you are suggesting, it is that,
if I have  IN A #.#....
                     IN AAAA #:#:...

My SMTP client should somehow generate, not the implicit MX
called for by 2821bis (and 2821), which is  IN MX 0

but some sort of MX arrangement that points to the A RR only and
not to the AAAA RR.   There is just no way to do that, at least
without putting completely new language in 2821bis that
distinguishes between the interpretation rules for implicit and
explicit MX records (and getting hopelessly entangled with and
overriding RFC 3484).

So what are you suggesting?