ietf-smtp
[Top] [All Lists]

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

2008-04-06 22:16:41

At 20:54 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor is. It's not a pardigm change:

 >> John C Klensin asked:
 >>
 So what are you suggesting?

Robert A. Rosenberg wrote:

 1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.

Translation:

EXPLICIT MX - it must have a MX record which exposes mail host A records.

I agree with your translation if by this you mean that IF there is a IPv6 MTA that is supposed to be supporting that FQDN, this support must be signified by listing the AAAA and A records of all the IPv6 and IPv4 MTAs for that FQDN. Listing means pointing via the MX RHS to FQDNs of IN groups that contain the relevant A and AAAA records.


 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 is not consistent with #1 - mandating a successful MX record.

WHAT? If a MX is found, this meets my rule as quoted above. If there is no MX, then the FQDN MX 0 FQDN that you pretend to have found should, by my rules, cause the FQDN IN that gets referenced to be treated as if it is composed ONLY of A records (ie: Any AAAA records that are found should have their existence ignored just like an IPv4-only Stack would ignore them AS DOCUMENTED for this condition in RFC 3484).



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

OK, it sounds to me that what you are advocating is that RESOLVERS learn
how to do an inherent "Implicit MX" default logic for all MX queries.

Is that a correct statement?

No. The MTA asks for the MX. It gets told that there is no MX so it asks for the FQDN IN group and gets a mixture of A and AAAA (or if you need to ask separately for A and AAAA records, just ask for A records). Any AAAA records that get returned are ignored and only the A records are used. It is my understanding that it is the job of the MTA to request the A records in the absence of a MX not the job of the resolver to return A and AAAA records to a MX request in the absence of an MX. Even if the resolver DOES take it upon itself to return A/AAAA records in the absence of an MX record, it is not that hard for the MTA to ignore any returned AAAA records that get returned in response to a MX request.

<Prev in Thread] Current Thread [Next in Thread>