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

At 21:09 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor is. 
It's not a pardigm change:
> Hector Santos wrote:
> > The different here from what I am reading is that there seems to be 
> > this notion that the DNS resolver is always independent from the 
> > SMTP and its results drive the SMTP client - i.e, the SMTP client 
> > is not in the picture.  I don't believe that concept can be 
> > presumed to be always true.
> Clarification because DNS results always drives an SMTP client
>
> What I meant is that a MX query returning NO RECORDS is what drives 
> the SMTP to consider using a Implicit MX concept.
> If the resolver always return a MX query result, then the SMTP 
> client will never have any control here.  I don't think using the 
> zero preference is a reliable indicator to represent a raw A record 
> for the domain.
I agree with your statements. For historical reasons we MUST allow 
use of the A records in the FQDN IN group (since no-one has had the 
guts to ramrod an RFC that says "Enough is Enough. MX has been in 
existence for 20 years and that is enough time to have gotten off 
your rumps and added MX records pointing at the A records that define 
your IPv4 MTAs. Thus as of this Flag-Day date the ability to access 
an IPv4 MTA via its A record instead of having a MX record point at 
that A record is forbidden and is no longer supported").
The fact we allow MX-less MTAs to be accessed via an A record is NOT 
a valid excuse to allow AAAA records to be used in this case. While 
that WAS an excuse to allow the A record to be used (ignoring the 
question of if this excuse is still valid), the existence of the MX 
record (and [all-most?] 100% support for the MX record in DNS code 
and 100% support for the MX record in the code with IPv6 support) 
that predates the existence of IPv6, means that it should be required 
to exist and point at the AAAA records that belong to IPv6 IPN 
monitoring MTAs. The use of AAAA records to locate an IPv6 MTA does 
NOT predate the existence of the MX and thus should be forbidden.
As to support of a IPv6 MTA (either via an IPv6-Only or Dual 
IPv4/IPv6 stack), we mandate that the IPv6 MTAs (and any IPv4 MTAs 
that share the IPv6 MTA's FQDN) be pointed to by a MX.
Thus the resolution logic is as follows.

1) Look for a MX. If found go to step 3. If not found set a NO-MX flag.
2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was found in step 1.
3) Process the IN A/AAAA records in order (within MX Priority order).
4) For each A/AAAA selected in step 3, check for the NO-MX flag and 
if found ignore the record if it is an AAAA and immediately go to 
step 7.
5) Since NO-MX is not on, we found a real MX so process the A/AAAA as 
at present. ie: If an A, check if we have IPv4 Stack support, if an 
AAAA check for IPv6 Stack support. Lack of support goes to step 7.
6) Attempt to connect to the A/AAAA designated IPN. If we get a 
connection then process based on whatever return code we get (which 
may mean going to the next IPN in the list [step 3] or giving up).
7) The current A/AAAA record is no good, If this is not the end of 
the A/AAAA list, go back to step 3 and process the next IPN in the 
list. Otherwise go into the "No Usable IPNs" error state and deal 
with it appropriately.
NOTE: This method keeps the status quo for the case where ALL the 
MTAs for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only 
says that MX-less FQDNs are serviced by those A records in the FQDN 
IN group and that any AAAA records found there are to be ignored.

!3a-) Happy.gif
Description: GIF image