--On Wednesday, 02 April, 2008 00:17 -0400 "Robert A. Rosenberg"
<[EMAIL PROTECTED]> 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 foo.example.com.   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

   foo.example.com.  IN A #.#....
                     IN AAAA #:#:...

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

   foo.example.com.  IN MX 0 foo.example.com.

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?

    john


Reply via email to