ietf-smtp
[Top] [All Lists]

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

2008-04-05 22:37:56

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

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

1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.
2) Require that any IMPLICATE MX record that is built due to the absence of an EXPLICATE MX record follow the EXPLICATE MX RFC 3484 rules for an IPv4-ONLY stack (ie: Ignore all AAAA records found for foo.example.com IN A/AAAA).

This simple set of rules allows A-Fallback to continue to work by simply requiring that an IMPLICATE MX that is created is treated the Stack as if it were an IPv4-Only Stack even when it is actually a Dual Stack or an IPv6-Only stack.